Merge remote-tracking branch 'upstream/master' into batch-integ-considerations

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
 

XLS-0008-tickets/README.md

@@ -6,6 +6,7 @@
   created: 2020-03-01
   proposal-from: https://github.com/XRPLF/XRPL-Standards/discussions/23
   status: Withdrawn
+  withdrawal-reason: Superseded by XLS-13
   category: Amendment
 </pre>
 

XLS-0010-non-transferable-tokens/README.md

@@ -1,6 +1,7 @@
 <pre>
     xls: 10
     title: Non-Transferable Token (NTT) standard
+    description: A standard for non-transferable tokens on the XRP Ledger
     author: RichardAH (@RichardAH)
     proposal-from: https://github.com/XRPLF/XRPL-Standards/discussions/20
     created: 2020-04-05

XLS-0015-concise-tx-id/README.md

@@ -6,6 +6,7 @@
   created: 2021-03-09
   proposal-from: https://github.com/XRPLF/XRPL-Standards/discussions/34
   status: Withdrawn
+  withdrawal-reason: Superseded by XLS-37
   category: System
 </pre>
 

XLS-0016-nft-metadata/README.md

@@ -1,11 +1,12 @@
 <pre>
-    xls: 16
-    title: NFT Metadata
-    author: Hubert Getrouw (@HubertG97)
-    created: 2021-03-17
-    proposal-from: https://github.com/XRPLF/XRPL-Standards/discussions/37
-    status: Stagnant
-    category: Ecosystem
+  xls: 16
+  title: NFT Metadata
+  description: Standard for NFT metadata
+  author: Hubert Getrouw (@HubertG97)
+  created: 2021-03-17
+  proposal-from: https://github.com/XRPLF/XRPL-Standards/discussions/37
+  status: Stagnant
+  category: Ecosystem
 </pre>
 
 In addition to @WietseWind 's [XLS-14](https://github.com/XRPLF/XRPL-Standards/discussions/30) and @RichardAH 's proposal [XLS-15](../XLS-0015-concise-tx-id/README.md) here is a proposal to create a standard for the creation of metadata for the tokens created with a CTI in the currency code.

XLS-0017-xfl/README.md

@@ -1,7 +1,7 @@
 <pre>
     xls: 17
     title: XFL Developer-friendly representation of XRPL balances
-    descrption: Introduces developer-friendly representation of XRPL balances.
+    description: Introduces developer-friendly representation of XRPL balances.
     author: RichardAH (@RichardAH)
     proposal-from: https://github.com/XRPLF/XRPL-Standards/discussions/39
     created: 2021-03-19

XLS-0051-nftoken-escrow/README.md

@@ -1,11 +1,12 @@
 <pre>
   xls: 51
   title: NFToken Escrows
+  description: Extension to Escrow functionality to support escrowing NFTokens
   author: Mayukha Vadari (@mvadari)
-  created: 2023-11-17
   proposal-from: https://github.com/XRPLF/XRPL-Standards/discussions/146
   status: Stagnant
   category: Amendment
+  created: 2023-11-17
 </pre>
 
 # NFToken Escrows