Merge branch 'master' into xls-56-cleanup

Author: mvadari

.github/scripts/assign_xls_number.py

@@ -63,7 +63,7 @@ def find_draft_xls_files(changed_files: list[str]) -> list[str]:
     Returns:
         List of draft XLS directory names (e.g., ["XLS-draft-my-feature"])
     """
-    draft_pattern = re.compile(r"^(XLS-draft-[^/]+)/README\.md$")
+    draft_pattern = re.compile(r"^((XLS|xls)-draft[^/]+)/README\.md$")
     drafts = []
 
     for file_path in changed_files:

.github/workflows/assign-xls-number.yml

@@ -1,36 +1,49 @@
 name: Assign XLS Number
 
 on:
-  pull_request:
-    types: [opened, synchronize, reopened]
+  pull_request_target:
+    types: [opened, synchronize, reopened, ready_for_review]
 
 jobs:
   assign-xls-number:
     runs-on: ubuntu-latest
     name: Assign XLS Number to Draft
     permissions:
       pull-requests: write
+      issues: write
       contents: read
 
     steps:
       - name: Checkout repository
         uses: actions/checkout@v6
         with:
           fetch-depth: 0
+          ref: ${{ github.event.pull_request.head.sha }}
+
+      - name: Checkout script from base branch
+        uses: actions/checkout@v6
+        with:
+          ref: ${{ github.event.pull_request.base.ref }}
+          sparse-checkout: |
+            .github/scripts/assign_xls_number.py
+          sparse-checkout-cone-mode: false
+          path: base-repo
 
       - name: Get added files
         id: added-files
         uses: tj-actions/changed-files@v47
         with:
           files: |
-            XLS-draft-*/README.md
+            XLS-draft*/README.md
+            xls-draft*/README.md
           # Only look at added files, not modified ones
           include_all_old_new_renamed_files: false
 
       - name: Check for draft XLS files
         id: check-drafts
         run: |
           ADDED_FILES="${{ steps.added-files.outputs.added_files }}"
+          echo $ADDED_FILES
           if [ -z "$ADDED_FILES" ]; then
             echo "No XLS draft files added in this PR"
             echo "has_drafts=false" >> $GITHUB_OUTPUT
@@ -50,7 +63,8 @@ jobs:
         if: steps.check-drafts.outputs.has_drafts == 'true'
         id: assign-number
         run: |
-          python .github/scripts/assign_xls_number.py ${{ steps.check-drafts.outputs.draft_files }}
+          echo ${{ steps.check-drafts.outputs.draft_files }}
+          python base-repo/.github/scripts/assign_xls_number.py ${{ steps.check-drafts.outputs.draft_files }}
 
       - name: Check for existing assignment comment
         if: steps.check-drafts.outputs.has_drafts == 'true'

XLS-0001-xls-process/README.md

@@ -305,17 +305,20 @@ Submitting a transaction typically requires paying a transaction fee. A typical
 
 ###### 4.4.3.3.4. Failure Conditions
 
-This section describes the conditions under which the transaction will fail. This must be an exhaustive, descriptive list. Each condition should ideally map to a specific error code. The list should be indexed for easy reference.
+This section describes all conditions under which the transaction will fail. Each condition must map to a specific error code. The list must be exhaustive, descriptive, and indexed for easy reference.
 
-When using the same transaction to create and update an object, the expected behavior is identified by the presence or absence of the object identifier (e.g., `tx.ExampleID`).
+Failure conditions are grouped into two categories:
+
+- Data validation failures: Return a `tem` code
+- Protocol-level failures: Return `tec` codes. With rare exceptions they may return a `ter`, `tef`, or `tel` code. If another error code must be returned, justification must be provided.
 
 In case of a transaction failure, an XRP Ledger server returns an error code indicating the outcome. These codes are crucial for clients to understand why a transaction was not successful. Please refer to the [documentation](https://xrpl.org/docs/references/protocol/transactions/transaction-results) for existing error codes. When defining failure conditions for a new transaction type in an XLS, reuse existing codes whenever an existing code accurately describes the failure condition. This helps maintain consistency and avoids unnecessary proliferation of codes.
 
 If the new transaction logic introduces novel failure reasons not adequately covered by existing generic codes, a new error code (usually a `tec` code) should be proposed. This new code must be clearly defined and justified and would eventually be added to [rippled](https://github.com/XRPLF/rippled/blob/develop/include/xrpl/protocol/TER.h) if the XLS is adopted. XLS authors will primarily define error codes for their specific transaction logic failures.
 
 ###### 4.4.3.3.5. State Changes
 
-This section describes the changes made to the ledger state if the transaction executes successfully. It should omit default state changes common to all transactions (e.g., fee processing, sequence number increment, setting `PreviousTxnID`/`PreviousTxnLgrSeq` on modified objects). Indexed for clarity. A successfully applied transaction must return a `tesSUCCESS` code.
+This section describes the changes made to the ledger state if the transaction executes successfully. It should omit default state changes common to all transactions (e.g., fee processing, sequence number increment, setting `PreviousTxnID`/`PreviousTxnLgrSeq` on modified objects). The list must be exhaustive, descriptive, and indexed for easy reference. When using the same transaction to create and update an object, the expected behavior is identified by the presence or absence of the object identifier (e.g., `tx.ExampleID`). A successfully applied transaction must return a `tesSUCCESS` code.
 
 ###### 4.4.3.3.6. Metadata Fields
 

templates/AMENDMENT_TEMPLATE.md

@@ -222,11 +222,23 @@ _[If Custom]: This transaction requires `[X]` drops because `[reason]`._
 
 ### 3.4. Failure Conditions
 
-_[List all conditions that cause the transaction to fail, with corresponding error codes]_
+_[An indexed list of all conditions that cause the transaction to fail, with corresponding error codes. Group failure conditions into two categories: data verification, invalid field values, protocol-level logic.]_
 
-- `[Description of failure condition]` (`[ERROR_CODE]`)
-- `[Description of failure condition]` (`[ERROR_CODE]`)
-- `[Description of failure condition]` (`[ERROR_CODE]`)
+#### 3.4.1. Data Verification
+
+[All Data Verification failures return a `tem` level error.]
+
+1. `[Description of failure condition]` (`[ERROR_CODE]`)
+2. `[Description of failure condition]` (`[ERROR_CODE]`)
+3. `[Description of failure condition]` (`[ERROR_CODE]`)
+
+#### 3.4.2. Protocol-Level Failures
+
+_[Protocol-level failures return `tec` codes. With rare exceptions they may return a `ter`, `tef`, or `tel` code.]_
+
+1. `[Description of failure condition]` (`[ERROR_CODE]`)
+2. `[Description of failure condition]` (`[ERROR_CODE]`)
+3. `[Description of failure condition]` (`[ERROR_CODE]`)
 
 _[For new error codes, provide justification for why existing codes are insufficient]_
 
@@ -297,9 +309,11 @@ _[If your specification introduces new APIs or modifies existing ones, document
 
 ### 5.3. Failure Conditions
 
-- `[Description of failure condition]` (`[ERROR_CODE]`)
-- `[Description of failure condition]` (`[ERROR_CODE]`)
-- `[Description of failure condition]` (`[ERROR_CODE]`)
+_[An indexed list of RPC error codes.]_
+
+1. `[Description of failure condition]` (`[ERROR_CODE]`)
+2. `[Description of failure condition]` (`[ERROR_CODE]`)
+3. `[Description of failure condition]` (`[ERROR_CODE]`)
 
 ### 5.4. Example Request