@wowok/agent-mcp 3.3.6 → 3.3.8

package/dist/schemas/onchain_operations_guard.schema.json

@@ -3850,6 +3850,165 @@
                   ],
                   "additionalProperties": false,
                   "description": "Returns VecString. Lists ALL policy key names of the Repository (max 50). Use vec_length to bound per-key composite queries or vec_contains_string to assert a key exists."
+                },
+                {
+                  "type": "object",
+                  "properties": {
+                    "type": {
+                      "type": "string",
+                      "const": "query_order_named_operator_member"
+                    },
+                    "object": {
+                      "type": "object",
+                      "properties": {
+                        "identifier": {
+                          "type": "integer",
+                          "minimum": 0,
+                          "maximum": 255,
+                          "description": "Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails such as full refunds). SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."
+                        }
+                      },
+                      "required": [
+                        "identifier"
+                      ],
+                      "additionalProperties": false,
+                      "description": "Reference to the Order object in the Guard table (must be Address type)."
+                    }
+                  },
+                  "required": [
+                    "type",
+                    "object"
+                  ],
+                  "additionalProperties": false,
+                  "description": "Returns Bool. Whether the transaction signer is on the order's named-operator roster (DM-P1 rider-roster exclusive admission): reads the namedOperator roster of the order's Progress and checks tx-signer membership. Parameterless — the signer comes from the transaction context. Gated by protocol v138 (feature flag enable_order_named_operator_member); on a chain without the flag the guard evaluation aborts. Typical use: AND it into the forward-edge guard on courier handover edges (e.g. PickupOrder/DeliverOrder) so only roster members can advance — the on-chain namedOperator rail alone only AUTHORIZES, it never DENIES (R-19)."
+                },
+                {
+                  "type": "object",
+                  "properties": {
+                    "type": {
+                      "type": "string",
+                      "const": "query_repository_data_has"
+                    },
+                    "object": {
+                      "type": "object",
+                      "properties": {
+                        "identifier": {
+                          "type": "integer",
+                          "minimum": 0,
+                          "maximum": 255,
+                          "description": "Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails such as full refunds). SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."
+                        }
+                      },
+                      "required": [
+                        "identifier"
+                      ],
+                      "additionalProperties": false,
+                      "description": "Reference to the Repository object in the Guard table (must be Address type)."
+                    },
+                    "id": {
+                      "type": "object",
+                      "properties": {
+                        "identifier": {
+                          "type": "integer",
+                          "minimum": 0,
+                          "maximum": 255,
+                          "description": "Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails such as full refunds). SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."
+                        }
+                      },
+                      "required": [
+                        "identifier"
+                      ],
+                      "additionalProperties": false,
+                      "description": "Reference to the row's principal address (Address type table entry) — the row id the data was written under."
+                    },
+                    "key": {
+                      "type": "string",
+                      "minLength": 1,
+                      "description": "Row name — the policy key string of the data row to probe."
+                    }
+                  },
+                  "required": [
+                    "type",
+                    "object",
+                    "id",
+                    "key"
+                  ],
+                  "additionalProperties": false,
+                  "description": "Returns Bool. Whether the Repository holds a data row for (key, id) — single-row exact read by (key, id), the primitive for per-value mutual-consent attestation (e.g. a settlement keeper asserting the buyer acceptance row exists before executing a refund allocator). NOT protocol-gated (legacy query, works on every chain version)."
+                },
+                {
+                  "type": "object",
+                  "properties": {
+                    "type": {
+                      "type": "string",
+                      "const": "query_repository_data"
+                    },
+                    "object": {
+                      "type": "object",
+                      "properties": {
+                        "identifier": {
+                          "type": "integer",
+                          "minimum": 0,
+                          "maximum": 255,
+                          "description": "Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails such as full refunds). SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."
+                        }
+                      },
+                      "required": [
+                        "identifier"
+                      ],
+                      "additionalProperties": false,
+                      "description": "Reference to the Repository object in the Guard table (must be Address type)."
+                    },
+                    "id": {
+                      "type": "object",
+                      "properties": {
+                        "identifier": {
+                          "type": "integer",
+                          "minimum": 0,
+                          "maximum": 255,
+                          "description": "Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails such as full refunds). SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."
+                        }
+                      },
+                      "required": [
+                        "identifier"
+                      ],
+                      "additionalProperties": false,
+                      "description": "Reference to the row's principal address (Address type table entry) — the row id the data was written under."
+                    },
+                    "key": {
+                      "type": "string",
+                      "minLength": 1,
+                      "description": "Row name — the policy key string of the data row to read."
+                    },
+                    "conditions": {
+                      "description": "Optional equality conditions compared against the read row bytes; when non-empty the node emits ONE on-chain logic_equal over the read plus all conditions and returns Bool instead of VecU8.",
+                      "type": "array",
+                      "items": {
+                        "type": "object",
+                        "properties": {
+                          "identifier": {
+                            "type": "integer",
+                            "minimum": 0,
+                            "maximum": 255,
+                            "description": "Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails such as full refunds). SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."
+                          }
+                        },
+                        "required": [
+                          "identifier"
+                        ],
+                        "additionalProperties": false,
+                        "description": "Reference to a VecU8-type table entry whose value must equal the read row — a b_submission slot (the submitted acceptance value) is the typical leg."
+                      }
+                    }
+                  },
+                  "required": [
+                    "type",
+                    "object",
+                    "id",
+                    "key"
+                  ],
+                  "additionalProperties": false,
+                  "description": "Returns VecU8 (the row bytes [type_byte, ...bcs_payload]) — single-row exact read by (key, id), the primitive for per-value mutual-consent attestation. With conditions, returns Bool: the kernel-enforced 'stored value == submitted value' check (b_submission condition entries make the comparison read the passport submission slot) — this turns a self-attested policy write into kernel-verified mutual consent. NOT protocol-gated (legacy query). Absent row: empty blob under the v136 sentinel flag (never equals a non-empty acceptance value — fail-closed), guard abort on older chains."
                 }
               ],
               "$ref": "#/definitions/__schema0"
@@ -7467,6 +7626,165 @@
           ],
           "additionalProperties": false,
           "description": "Returns VecString. Lists ALL policy key names of the Repository (max 50). Use vec_length to bound per-key composite queries or vec_contains_string to assert a key exists."
+        },
+        {
+          "type": "object",
+          "properties": {
+            "type": {
+              "type": "string",
+              "const": "query_order_named_operator_member"
+            },
+            "object": {
+              "type": "object",
+              "properties": {
+                "identifier": {
+                  "type": "integer",
+                  "minimum": 0,
+                  "maximum": 255,
+                  "description": "Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails such as full refunds). SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."
+                }
+              },
+              "required": [
+                "identifier"
+              ],
+              "additionalProperties": false,
+              "description": "Reference to the Order object in the Guard table (must be Address type)."
+            }
+          },
+          "required": [
+            "type",
+            "object"
+          ],
+          "additionalProperties": false,
+          "description": "Returns Bool. Whether the transaction signer is on the order's named-operator roster (DM-P1 rider-roster exclusive admission): reads the namedOperator roster of the order's Progress and checks tx-signer membership. Parameterless — the signer comes from the transaction context. Gated by protocol v138 (feature flag enable_order_named_operator_member); on a chain without the flag the guard evaluation aborts. Typical use: AND it into the forward-edge guard on courier handover edges (e.g. PickupOrder/DeliverOrder) so only roster members can advance — the on-chain namedOperator rail alone only AUTHORIZES, it never DENIES (R-19)."
+        },
+        {
+          "type": "object",
+          "properties": {
+            "type": {
+              "type": "string",
+              "const": "query_repository_data_has"
+            },
+            "object": {
+              "type": "object",
+              "properties": {
+                "identifier": {
+                  "type": "integer",
+                  "minimum": 0,
+                  "maximum": 255,
+                  "description": "Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails such as full refunds). SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."
+                }
+              },
+              "required": [
+                "identifier"
+              ],
+              "additionalProperties": false,
+              "description": "Reference to the Repository object in the Guard table (must be Address type)."
+            },
+            "id": {
+              "type": "object",
+              "properties": {
+                "identifier": {
+                  "type": "integer",
+                  "minimum": 0,
+                  "maximum": 255,
+                  "description": "Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails such as full refunds). SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."
+                }
+              },
+              "required": [
+                "identifier"
+              ],
+              "additionalProperties": false,
+              "description": "Reference to the row's principal address (Address type table entry) — the row id the data was written under."
+            },
+            "key": {
+              "type": "string",
+              "minLength": 1,
+              "description": "Row name — the policy key string of the data row to probe."
+            }
+          },
+          "required": [
+            "type",
+            "object",
+            "id",
+            "key"
+          ],
+          "additionalProperties": false,
+          "description": "Returns Bool. Whether the Repository holds a data row for (key, id) — single-row exact read by (key, id), the primitive for per-value mutual-consent attestation (e.g. a settlement keeper asserting the buyer acceptance row exists before executing a refund allocator). NOT protocol-gated (legacy query, works on every chain version)."
+        },
+        {
+          "type": "object",
+          "properties": {
+            "type": {
+              "type": "string",
+              "const": "query_repository_data"
+            },
+            "object": {
+              "type": "object",
+              "properties": {
+                "identifier": {
+                  "type": "integer",
+                  "minimum": 0,
+                  "maximum": 255,
+                  "description": "Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails such as full refunds). SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."
+                }
+              },
+              "required": [
+                "identifier"
+              ],
+              "additionalProperties": false,
+              "description": "Reference to the Repository object in the Guard table (must be Address type)."
+            },
+            "id": {
+              "type": "object",
+              "properties": {
+                "identifier": {
+                  "type": "integer",
+                  "minimum": 0,
+                  "maximum": 255,
+                  "description": "Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails such as full refunds). SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."
+                }
+              },
+              "required": [
+                "identifier"
+              ],
+              "additionalProperties": false,
+              "description": "Reference to the row's principal address (Address type table entry) — the row id the data was written under."
+            },
+            "key": {
+              "type": "string",
+              "minLength": 1,
+              "description": "Row name — the policy key string of the data row to read."
+            },
+            "conditions": {
+              "description": "Optional equality conditions compared against the read row bytes; when non-empty the node emits ONE on-chain logic_equal over the read plus all conditions and returns Bool instead of VecU8.",
+              "type": "array",
+              "items": {
+                "type": "object",
+                "properties": {
+                  "identifier": {
+                    "type": "integer",
+                    "minimum": 0,
+                    "maximum": 255,
+                    "description": "Identifier (0-255) for data lookup in Guard table. Slot consensus (enforced on-chain at guard table construction): 0-220 = user slots (free for business guards); 221-253 = PROTOCOL-RESERVED (rejected on-chain — reserved so future protocol features get fixed slots without colliding with published guards); 255 = ONCE replay-protection slot on Allocation (byte-keyed, the submitted bytes are the once-key — use for per-period keys like period-<N>); 254 = ONCE-FOR-OBJECT slot on Allocation (chain-derived key = bcs(the Allocation's payment_info.for_object); the submitted bytes are ignored and the submission only arms the slot — use for one-shot per-order rails such as full refunds). SLOT 0 SEMANTICS: slot 0 carries the transacted Order address by convention. As a submission slot it is legal on order/allocation/machine rails (the order exists when those verify), but FORBIDDEN on a Service buy_guard — the order does not exist when the buy-time passport is verified, so the mount is refused (service abort 43)."
+                  }
+                },
+                "required": [
+                  "identifier"
+                ],
+                "additionalProperties": false,
+                "description": "Reference to a VecU8-type table entry whose value must equal the read row — a b_submission slot (the submitted acceptance value) is the typical leg."
+              }
+            }
+          },
+          "required": [
+            "type",
+            "object",
+            "id",
+            "key"
+          ],
+          "additionalProperties": false,
+          "description": "Returns VecU8 (the row bytes [type_byte, ...bcs_payload]) — single-row exact read by (key, id), the primitive for per-value mutual-consent attestation. With conditions, returns Bool: the kernel-enforced 'stored value == submitted value' check (b_submission condition entries make the comparison read the passport submission slot) — this turns a self-attested policy write into kernel-verified mutual consent. NOT protocol-gated (legacy query). Absent row: empty blob under the v136 sentinel flag (never equals a non-empty acceptance value — fail-closed), guard abort on older chains."
         }
       ]
     }

package/dist/schemas/onchain_operations_order.schema.json

@@ -175,7 +175,7 @@
           "additionalProperties": false
         },
         "acknowledge_dual_payout": {
-          "description": "Explicit opt-in for a KNOWN double payout on the compensation-claim direction: when this order's escrow is already FULLY released (allocation balance 0 of a positive order amount) and this call claims the arbitration compensation on top, the call is REFUSED unless this flag is true. The escrow track and the compensation track are independent by design — the chain will not stop the second payout, so the operator must state the netting decision deliberately. Leave unset for claims on orders whose escrow is intact or partially released.",
+          "description": "Explicit opt-in for a KNOWN double payout on the compensation-claim direction (keeper posture 拍板⑧ dm-mtw-261027): when this order's escrow is already FULLY released (allocation balance 0 of a positive order amount) and this call claims the arbitration compensation on top, the call is REFUSED unless this flag is true. The escrow track and the compensation track are independent by design — the chain will not stop the second payout, so the operator must state the netting decision deliberately. Leave unset for claims on orders whose escrow is intact or partially released. AUTOMATION RULE: this flag is the HUMAN operator's netting decision — an automated keeper that receives dual_payout_unconfirmed must STOP retrying and escalate (never set the flag itself). D-1 (ksr 5R-08): the flag is additionally honored ONLY when the executing store carries a human-recorded preauthorization (config_operation store_dual_payout_set {account, confirm:true}, then store_dual_payout_get shows preauthorized=true); without it the gate answers dual_payout_preauthorization_required — record the standing decision first, then re-send.",
           "type": "boolean"
         },
         "arb_case_conclude": {

package/dist/schemas/onchain_operations_reward.schema.json

@@ -225,7 +225,7 @@
           ]
         },
         "guard_add": {
-          "description": "Add Guard to Reward object. IDIOMS (F08 — these differ from Service allocation, follow THIS shape here): recipient is ONE OF {GuardIdentifier: <u8>} | {Entity: {name_or_address: 'mark'}} | {Signer: 'signer'} (string const INSIDE the key, NOT a bare string) — BUT on the REWARD claim rail the recipient MUST equal the transaction sender (chain assert, abort 14), so {Signer: 'signer'} is the canonical form and {Entity} also passes (SDK replaces it with the claimant's account at claim time); a {GuardIdentifier} recipient resolves to the submitted Order and is STRUCTURALLY UNPAYABLE (every claim aborts 14) — the tool gate rejects it (crs-mn-261015 F-12). amount is {type: 'Fixed', value: '0.1WOW'} — value accepts a display string with token symbol ('0.1WOW') or a smallest-unit integer ('100000000'), NOT the plain balance string used by allocation `sharing`. FULL EXAMPLE: [{guard: '0xabc...', recipient: {Signer: 'signer'}, amount: {type: 'Fixed', value: '0.1WOW'}}].",
+          "description": "Add Guard to Reward object. IDIOMS (F08 — these differ from Service allocation, follow THIS shape here): recipient is ONE OF {GuardIdentifier: <u8>} | {Entity: {name_or_address: 'mark'}} | {Signer: 'signer'} (string const INSIDE the key, NOT a bare string) — BUT on the REWARD claim rail the recipient MUST equal the transaction sender (chain assert, abort 14), so {Signer: 'signer'} is the canonical form and {Entity} also passes (SDK replaces it with the claimant's account at claim time); a {GuardIdentifier} recipient resolves to the submitted Order and is STRUCTURALLY UNPAYABLE (every claim aborts 14) — the tool gate rejects it (crs-mn-261015 F-12). amount is {type: 'Fixed', value: '0.1WOW'} — value accepts a display string with token symbol ('0.1WOW') or a smallest-unit integer ('100000000'), NOT the plain balance string used by allocation `sharing`. FULL EXAMPLE: [{guard: '0xabc...', recipient: {Signer: 'signer'}, amount: {type: 'Fixed', value: '0.1WOW'}}]. OPTIONAL EVIDENCE BINDING (ksk9d2-tn-261026 F-01): an entry may carry evidence {repo, key, predicate} — a claim-time attestation pin that counts ONLY repository rows tied to THIS claim's own store_from value (the submitted order), so borrowed/foreign rows never satisfy the bounty; it requires store_from_id on the same guard (a missing pin aborts 16 at build time) and a claim whose order has no matching attestation row aborts 15.",
           "type": "array",
           "items": {
             "type": "object",
@@ -363,6 +363,40 @@
                     "type": "null"
                   }
                 ]
+              },
+              "evidence": {
+                "description": "ksk9d2-tn-261026 F-01 claim-time attestation pin (reward::evidence_bind). REQUIRES store_from_id on the SAME guard — the binding reads THE pinned store_from row, so the chain aborts 16 (E_EVIDENCE_NEEDS_STORE_FROM) at build time without it. At claim the chain counts repository rows under (repo, key) matching the predicate for the claim's OWN store_from value (the submitted order) via the native evidence_count and aborts 15 (E_EVIDENCE_NOT_OWNED) when none — a borrowed foreign row can never pay.",
+                "type": "object",
+                "properties": {
+                  "repo": {
+                    "type": "string",
+                    "description": "Repository object ID or name holding the attestation rows."
+                  },
+                  "key": {
+                    "type": "array",
+                    "items": {
+                      "type": "integer",
+                      "minimum": 0,
+                      "maximum": 255
+                    },
+                    "description": "Repository data key bytes (the policy name the rows live under, e.g. UTF-8 bytes of 'rating')."
+                  },
+                  "predicate": {
+                    "type": "array",
+                    "items": {
+                      "type": "integer",
+                      "minimum": 0,
+                      "maximum": 255
+                    },
+                    "description": "BCS-encoded RepositoryDataPredicateWire bytes — the same predicate blob the repository read channel uses."
+                  }
+                },
+                "required": [
+                  "repo",
+                  "key",
+                  "predicate"
+                ],
+                "additionalProperties": false
               }
             },
             "required": [

package/dist/schemas/onchain_operations_service.schema.json

@@ -176,7 +176,7 @@
                   ]
                 },
                 "discount": {
-                  "description": "Discount object ID or name",
+                  "description": "Discount object ID or name. ⚠️ COUPON OWNERSHIP RULE (KB-02, disclose BEFORE checkout): a coupon held by another address cannot be applied to your order — only the coupon's current holder can redeem it, and the buy is signed by the buyer, so have the owner transfer the coupon to the buyer first (call service discount_send), then attach it here. Attaching the coupon BURNS it (every coupon is single-use), and any later refund settles the POST-coupon amount only (the escrowed discounted total) — the coupon's face value is never restored.",
                   "type": "string"
                 },
                 "payment_remark": {
@@ -670,7 +670,7 @@
           ]
         },
         "restock": {
-          "description": "Refund restocking (permission 305 SERVICE_SALES). op:'flag' opts ONE live product into restock-on-refund; op:'order' puts the units a REFUNDED order purchased back on shelf. The order path is all-or-nothing: every purchased line must be flagged and still live before any unit moves (otherwise the chain aborts 46/32), so half a restock is impossible. The order path is once-per-order (replay aborts 49) and bound to THIS service (foreign order aborts 26). Do NOT fake a restock with stock_add when the order carries several lines — use op:'order' so quantities come from the order itself.",
+          "description": "Refund restocking (permission 305 SERVICE_SALES). op:'flag' opts ONE live product into restock-on-refund; op:'order' puts the units a REFUNDED order purchased back on shelf. The order path is all-or-nothing: every purchased line must be flagged and still live before any unit moves (otherwise the chain aborts 46/32), so half a restock is impossible. The order path is once-per-order (replay aborts 49) and bound to THIS service (foreign order aborts 26). Do NOT fake a restock with stock_add when the order carries several lines — use op:'order' so quantities come from the order itself. DISCLOSURE: restock reopens sales — if the machine (or its template) has no refund-terminal gate, orders inside their refund window may lose refund eligibility or create fund-accounting ambiguity once restocked units are resold; confirm the machine's refund rail remains reachable after restocking.",
           "oneOf": [
             {
               "type": "object",
@@ -941,7 +941,7 @@
           ]
         },
         "discount": {
-          "description": "Issue discount.",
+          "description": "Issue discount (mint coupons bound to this Service). ⚠️ ISSUANCE PRESCRIPTION (KB-02): issuing = MINT then TRANSFER. This field mints the coupon objects under THIS account — its `recipient` field delivers them directly when you know the recipients; for pre-minted campaign coupons held for later handout, the handout itself is discount_send (mint first, transfer to the recipient at distribution time). COUPON SEMANTICS to disclose: HOLDING IS THE CREDENTIAL — the coupon belongs to whoever HOLDS it, only the holder's own signature can spend it, and sharing the coupon's object ID confers nothing; ONE COUPON, ONE BURN — every coupon is single-use and is destroyed on first spend; REFUNDS SETTLE THE POST-COUPON AMOUNT — refund rails pay back the escrowed discounted total only, a cancelled order never restores the coupon's face value. A coupon held by another address cannot be applied to a buyer's order — the owner must discount_send it to the buyer first.",
           "type": "object",
           "properties": {
             "name": {
@@ -986,7 +986,7 @@
               "type": "number"
             },
             "allow_zero_total": {
-              "description": "DISCLOSURE-ONLY FLAG — it has NO on-chain effect (F-BS-74: the on-chain Discount struct has no such field; a coupon minted with it is byte-identical to one without, and zero-total BUYS are refused by the chain's zero-total gate regardless — order_new_zero_total_dead_order client-side, abort 42 on-chain). Setting true only downgrades the MCP issuance BLOCK for a coupon that zeroes the cheapest SKU into a warning. There is NO free-product escape hatch today: price a deliberate free tier at 1 smallest unit (or deliver it outside the sales rails). Omit (default) for normal discounts.",
+              "description": "NO EFFECT — DO NOT SET (BSX-F07: the former escape hatch is removed). This flag has no on-chain field (the on-chain Discount struct never carried it; a coupon minted with it is byte-identical to one without), and it NO LONGER downgrades the MCP issuance block for a coupon that zeroes the cheapest SKU — the block is unconditional: a zeroing coupon can only dead-end at the buyer's checkout (order_new_zero_total_dead_order client-side, abort 42 on-chain). For a deliberate free tier: price the SKU at 1 smallest unit (never 0 — a zero-priced sale is permanently unbuyable) or deliver it outside the sales rails (e.g. a Demand with Signature fulfillment). Omit this field.",
               "type": "boolean"
             },
             "time_ms_end": {
@@ -1056,7 +1056,7 @@
           }
         },
         "discount_send": {
-          "description": "Transfer ALREADY-MINTED coupons you own to another address, instead of destroying them (discount_destroy) or minting new ones (discount). This is a pure ownership handover: the on-chain entry points are public funs with NO Service permission requirement — the only preconditions are that the sender owns each coupon and each was minted transferable:true. Typical use: hand out pre-minted campaign coupons, or move coupons between your own accounts.",
+          "description": "Transfer ALREADY-MINTED coupons you own to another address, instead of destroying them (discount_destroy) or minting new ones (discount). This is a pure ownership handover: the on-chain entry points are public funs with NO Service permission requirement — the only preconditions are that the sender owns each coupon and each was minted transferable:true. Typical use: hand out pre-minted campaign coupons, or move coupons between your own accounts. KB-02 COUPON SEMANTICS: this transfer is the second half of coupon ISSUANCE (mint via `discount`, then transfer here at distribution time). HOLDING IS THE CREDENTIAL: the coupon belongs to whoever HOLDS it — only the holder's own signature can spend it, and sharing the object ID confers nothing. ONE COUPON, ONE BURN: each coupon stays single-use and is destroyed on first spend — transfer does not reset that. REFUNDS SETTLE THE POST-COUPON AMOUNT: refund rails pay the escrowed discounted total only, never the coupon's face value. Until you transfer a gifted coupon, the recipient CANNOT use it on their own orders — a coupon held by another address cannot be applied to their buy.",
           "type": "object",
           "properties": {
             "discounts": {
@@ -1467,7 +1467,7 @@
           "additionalProperties": false
         },
         "buy_guard": {
-          "description": "Buy guard object ID or name.",
+          "description": "Buy guard object ID or name (null CLEARS the mount). RUNTIME SWITCH (permission 307 SERVICE_BUY_GUARD — the guard OBJECT is immutable but its MOUNT on the Service is mutable at any time). ROUND-ROTATION DUTY (拍板② dm-mtw-261027): for daily/group rounds whose cutoff is an absolute timestamp, the precise batch boundary is THIS mount, not the time guard — at the cutoff instant the keeper cron SETS the buy_guard (new entrants refused at BUY time) and CLEARs/re-arms it when the next round opens; the on-chain Clock >= cutoff comparison stays the settlement/advance authority. Disclose the publisher's time source the cron fires on. Full Machine reuse across rounds (advance gate re-reading a repository cutoff row) is filed for a protocol window.",
           "anyOf": [
             {
               "type": "string",