@wowok/agent-mcp 3.1.2 → 3.1.4

package/dist/knowledge/baselines/rules/allocation.json

@@ -0,0 +1,492 @@
+{
+  "comment": "Allocation rule pack (R-A) — declarative form of the retired in-code Allocation risk rules. Facts are produced by the kernel extractor (allocation-risk.ts, bound to the allocation-ledger constants and the canonical recipient-constraint doctrine); rules only reference fact names. First-offender walks (empty sharing, rate/amount violations, weak guards) are sunk into the extractor. Levels/wording can be retuned per rule and rules can be disabled (enabled=false, trace left) via the judgment document — factory rules can never be deleted or invented here.",
+  "facts": {
+    "allocators_config_present": "An allocators_config block is present in the context.",
+    "allocators_count": "Number of allocators in allocators_config (undefined when the block is absent).",
+    "allocators_empty": "The allocators.allocators array is empty — funds would be permanently locked.",
+    "empty_sharing_allocator_index": "First allocator whose sharing array is empty (first-offender walk; undefined when none).",
+    "empty_sharing_allocator_guard": "Guard address of the first allocator with an empty sharing array.",
+    "rate_rule_index": "First allocator violating a Rate-sum rule (undefined when none).",
+    "rate_rule_guard": "Guard address of the Rate-sum offender.",
+    "rate_rule_sum": "Sum of Rate-mode sharing values (Number()) for the offender.",
+    "rate_rule_pure": "Pure Rate mode (no Surplus) with sum > 0 and sum != RATE_TOTAL_FULL.",
+    "rate_rule_exceed": "Rate + Surplus mode with rate sum > RATE_TOTAL_FULL.",
+    "rate_total_full": "KERNEL CONSTANT — full rate denominator (RATE_TOTAL_FULL = 10000).",
+    "amount_rule_branch": "First amount-rule violation branch for the first offending allocator: 'multiple_surplus' | 'below_threshold' | 'exceeds_max' (undefined when none).",
+    "amount_rule_index": "Allocator index of the amount-rule offender.",
+    "amount_rule_guard": "Guard address of the amount-rule offender.",
+    "amount_rule_surplus_count": "Number of Surplus sharing entries on the amount-rule offender.",
+    "amount_rule_amount_sum": "Sum of Amount-mode sharing values (Number()) for the offender.",
+    "amount_rule_threshold": "Number(allocators_config.threshold) for the offender (NaN when absent — comparisons stay false).",
+    "amount_rule_max": "Number(allocator.max) for the offender (only set on the exceeds_max branch).",
+    "signer_theft_detected": "Canonical RC-FIND-01 judgment (recipient-constraint.ts): a sharing.who=Signer recipient whose Guard does not bind the caller identity.",
+    "signer_theft_index": "Allocator index of the unbound-Signer theft offender.",
+    "signer_theft_guard": "Guard address of the theft offender.",
+    "signer_theft_guard_bound": "Whether the offender's Guard binds context(Signer)==authorized (always false when the rule fires).",
+    "guard_id_bad_identifier": "First GuardIdentifier recipient whose Passport table entry is known and not address-typed (undefined when none).",
+    "guard_id_bad_type": "Declared Passport table type of the offending identifier.",
+    "guard_id_bad_index": "Allocator index carrying the offending GuardIdentifier recipient.",
+    "duplicate_guards_present": "Two or more allocators reference the same Guard object address.",
+    "allocators_total": "Total allocator count (duplicate scan).",
+    "allocators_unique": "Unique Guard address count (duplicate scan).",
+    "duplicate_guards_csv_sp": "Duplicated Guard addresses joined with ', ' (description display form; repeats preserved like the old filter).",
+    "duplicate_guards_csv": "Duplicated Guard addresses joined with ',' (evidence display form).",
+    "for_object_anchor_known": "payment_info_for_object is declared in the context (Some or None — not unknown).",
+    "guard_identifier_recipient_present": "At least one allocator carries a sharing.who=GuardIdentifier recipient.",
+    "for_object_anchor_set": "payment_info.for_object is set (truthy anchor) — enforced on-chain at alloc().",
+    "for_object_anchor": "The declared for_object anchor address (only when known and set).",
+    "host_service_published": "The host Service is already published — order_allocators is immutable.",
+    "treasury_perm_mismatch": "An Entity recipient points to a Treasury whose Permission differs from the host Service Permission.",
+    "treasury_perm_entity": "Entity address of the permission-mismatch offender.",
+    "treasury_perm_treasury": "Treasury Permission address of the offender.",
+    "host_service_permission": "Host Service Permission address (undefined when the context carries none).",
+    "allocation_create_op": "The operation type is 'create' (the passive-object advisory only fires on create).",
+    "allocation_standalone": "trigger_source is 'standalone' (no Service/Arbitration access-control layer).",
+    "trigger_source_display": "Rendered trigger_source — 'unknown' when the context carries none.",
+    "standalone_weak_guards_count": "Standalone-mode allocator Guards lacking BOTH Signer binding and time-lock (0 when all are bound; undefined outside standalone mode).",
+    "standalone_weak_guards_csv_sp": "Weak Guard addresses joined with ', ' (description display form).",
+    "standalone_weak_guards_csv": "Weak Guard addresses joined with ',' (evidence display form).",
+    "has_fallback_allocator": "Whether an alternative Allocator exists (caller may retry with a different Guard if the first verification fails); undefined when the caller did not specify.",
+    "guard_conditions_mutually_exclusive": "Whether Guard conditions are mutually exclusive (multi-Allocator scenarios); undefined when the caller did not specify.",
+    "has_fallback_allocator_display": "Rendered has_fallback_allocator flag ('true'/'false') for evidence display.",
+    "mutually_exclusive_display": "Rendered guard_conditions_mutually_exclusive flag ('true'/'false') for evidence display.",
+    "pure_amount_index": "First allocator whose sharing is non-empty and pure Amount mode (undefined when none).",
+    "order_already_has_allocation": "The bound Order already carries an Allocation (1:1 constraint).",
+    "bound_order_display": "Rendered bound_order — 'unknown' when the context carries none (evidence form).",
+    "bound_order_paren_display": "Rendered bound_order — '(unknown)' when the context carries none (description form).",
+    "has_payment_info": "Whether payment_info is present for the alloc() call.",
+    "operation_type": "Raw operation type ('create' | 'receive' | 'alloc_by_guard' | 'query').",
+    "max_allocator_count": "KERNEL CONSTANT — allocators per Allocation cap (MAX_ALLOCATOR_COUNT).",
+    "always_true": "Extractor sentinel — unconditionally true; marks the always-on constant-sync reminder (R-A-5-03)."
+  },
+  "rules": [
+    {
+      "rule_id": "R-A-1-01",
+      "dimension": "structural",
+      "trigger": "allocators is empty or sharing arrays are empty",
+      "cases": [
+        {
+          "when": { "field": "allocators_empty", "op": "eq", "value": true },
+          "level": "critical",
+          "title": "Empty allocators — funds will be permanently locked",
+          "description": "Allocation has empty allocators.allocators. Service publish with empty order_allocators causes order funds to be permanently locked in the Allocation object.",
+          "scenario": "Service published without configuring any Allocator",
+          "mitigation": "Configure at least 1 Allocator. If no distribution is needed yet, use a single Allocator with Rate=10000 to the merchant address.",
+          "evidence": "allocators.length=0",
+          "stakeholders": ["owner", "service_provider", "system"],
+          "exposure": {
+            "loss_parties": [
+              { "role": "buyer", "basis": "Order funds escrowed into this Allocation can never be distributed or refunded — the buyer's payment is frozen indefinitely." },
+              { "role": "merchant", "basis": "Revenue shares can never be routed out of the Allocation — the merchant leg of every order is frozen too." }
+            ],
+            "gain_paths": []
+          }
+        },
+        {
+          "when": { "field": "empty_sharing_allocator_index", "op": "present" },
+          "level": "critical",
+          "title": "Allocator ${empty_sharing_allocator_index} has empty sharing — will never distribute",
+          "description": "Allocator at index ${empty_sharing_allocator_index} (guard=${empty_sharing_allocator_guard}) has empty sharing array. Even if its Guard passes verification, no funds will be distributed.",
+          "scenario": "Allocator with empty sharing vector",
+          "mitigation": "Add at least 1 sharing entry to Allocator ${empty_sharing_allocator_index}",
+          "evidence": "allocator[${empty_sharing_allocator_index}].sharing.length=0",
+          "stakeholders": ["owner", "recipient"],
+          "exposure": {
+            "loss_parties": [
+              { "role": "buyer", "basis": "The share routed to this Allocator can never be paid out or refunded — that portion of the order funds is frozen." },
+              { "role": "merchant", "basis": "Any merchant-side share assigned to this Allocator is frozen with it." }
+            ],
+            "gain_paths": []
+          }
+        }
+      ]
+    },
+    {
+      "rule_id": "R-A-1-02",
+      "dimension": "structural",
+      "trigger": "Pure Rate mode sum != 10000 or Rate+Surplus sum > 10000",
+      "cases": [
+        {
+          "when": { "field": "rate_rule_pure", "op": "eq", "value": true },
+          "level": "high",
+          "title": "Pure Rate mode sum ${rate_rule_sum} != ${rate_total_full}",
+          "description": "Allocator ${rate_rule_index} (guard=${rate_rule_guard}) uses pure Rate mode (no Surplus), but sum(rates)=${rate_rule_sum} ≠ ${rate_total_full}. Funds will be permanently locked (if sum<10000) or Move will abort with ERATE_NOT_10000 (if sum != 10000 exactly).",
+          "scenario": "Misconfigured rate proportions",
+          "mitigation": "Adjust sharing.sharing values so sum(rates)=${rate_total_full}, OR add 1 Surplus sharing to absorb the remainder.",
+          "evidence": "rateSum=${rate_rule_sum}, expected=${rate_total_full}",
+          "stakeholders": ["owner", "recipient"],
+          "exposure": {
+            "loss_parties": [
+              { "role": "buyer", "basis": "When the sum falls short of full, the unmatched remainder can never be distributed — that portion of the escrowed order funds is frozen." },
+              { "role": "merchant", "basis": "Any merchant-side share inside the unmatched remainder is frozen with it." }
+            ],
+            "gain_paths": []
+          }
+        },
+        {
+          "when": { "field": "rate_rule_exceed", "op": "eq", "value": true },
+          "level": "high",
+          "title": "Rate + Surplus sum ${rate_rule_sum} > ${rate_total_full}",
+          "description": "Allocator ${rate_rule_index} (guard=${rate_rule_guard}) uses Rate+Surplus mode, but sum(rates)=${rate_rule_sum} > ${rate_total_full}. Move will abort with ERATE_EXCEEDS_10000.",
+          "scenario": "Rate percentages exceed 100% before Surplus",
+          "mitigation": "Reduce sum(rates) to ≤ ${rate_total_full}.",
+          "evidence": "rateSum=${rate_rule_sum}, max=${rate_total_full}",
+          "stakeholders": ["owner"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-A-1-03",
+      "dimension": "structural",
+      "trigger": "Multiple Surplus sharing in one Allocator, or Amount sum violates threshold/max",
+      "cases": [
+        {
+          "when": { "field": "amount_rule_branch", "op": "eq", "value": "multiple_surplus" },
+          "level": "medium",
+          "title": "Allocator ${amount_rule_index} has ${amount_rule_surplus_count} Surplus sharing — at most 1 allowed",
+          "description": "Allocator ${amount_rule_index} (guard=${amount_rule_guard}) has ${amount_rule_surplus_count} Surplus sharing entries. Move will abort with EMULTIPLE_SURPLUS at alloc() time.",
+          "scenario": "Multiple Surplus entries in one Allocator",
+          "mitigation": "Keep at most 1 Surplus per Allocator. Use Rate mode for multi-party remainder distribution.",
+          "evidence": "surplusCount=${amount_rule_surplus_count}",
+          "stakeholders": ["owner"]
+        },
+        {
+          "when": { "field": "amount_rule_branch", "op": "eq", "value": "below_threshold" },
+          "level": "high",
+          "title": "Amount sum ${amount_rule_amount_sum} < threshold ${amount_rule_threshold}",
+          "description": "Allocator ${amount_rule_index} pure Amount mode fix=${amount_rule_amount_sum} < threshold=${amount_rule_threshold}. Move will abort with EAMOUNT_BELOW_THRESHOLD when the allocator is added.",
+          "scenario": "Amount sum insufficient to trigger alloc",
+          "mitigation": "Either lower threshold to <= fix, or increase Amount sharing values.",
+          "evidence": "fix=${amount_rule_amount_sum}, threshold=${amount_rule_threshold}",
+          "stakeholders": ["owner"]
+        },
+        {
+          "when": { "field": "amount_rule_branch", "op": "eq", "value": "exceeds_max" },
+          "level": "medium",
+          "title": "Amount sum ${amount_rule_amount_sum} > max ${amount_rule_max}",
+          "description": "Allocator ${amount_rule_index} Amount sum exceeds max. Move will abort with EAMOUNT_EXCEEDS_MAX.",
+          "scenario": "Amount sum exceeds max cap",
+          "mitigation": "Increase max or reduce Amount sharing values.",
+          "evidence": "fix=${amount_rule_amount_sum}, max=${amount_rule_max}",
+          "stakeholders": ["owner"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-A-2-01",
+      "dimension": "semantic",
+      "trigger": "sharing.who=Signer without Guard Signer binding — fund theft risk",
+      "cases": [
+        {
+          "when": { "field": "signer_theft_detected", "op": "eq", "value": true },
+          "level": "critical",
+          "title": "Signer recipient without caller constraint — fund theft",
+          "description": "Allocator ${signer_theft_index} (guard=${signer_theft_guard}) has sharing.who=Signer, but the Guard does not bind context(Signer)==authorized. Anyone who passes the Guard can steal 100% of funds. (Canonical finding RC-FIND-01, linked to guard-risk.ts R-C3-06.)",
+          "scenario": "Signer recipient without Guard Signer authentication",
+          "mitigation": "Bind the Signer (signer==order.owner or signer==fixed address), or change the recipient to an Entity / submitted object slot.",
+          "evidence": "guard=${signer_theft_guard}, guardSignerBound=${signer_theft_guard_bound}",
+          "stakeholders": ["owner", "recipient", "service_provider"],
+          "exposure": {
+            "loss_parties": [
+              { "role": "merchant", "basis": "The allocation pool pays whoever triggers it; the funder (merchant pool or buyer escrow routed through it) loses the delivered share permanently." },
+              { "role": "buyer", "basis": "When the pool carries the buyer's escrowed order funds, the theft drains the escrow leg." }
+            ],
+            "gain_paths": [
+              { "role": "neutral", "path": "Any caller satisfying the remaining guard conditions takes the pool share directly into their own wallet (Recipient::Signer, destination = caller).", "viability": "viable", "gate": "Direct-pay + no identity binding is the theft path itself; nothing else gates it." }
+            ]
+          }
+        }
+      ]
+    },
+    {
+      "rule_id": "R-A-2-02",
+      "dimension": "semantic",
+      "trigger": "sharing.who=GuardIdentifier but Passport table entry is not address type",
+      "cases": [
+        {
+          "when": { "field": "guard_id_bad_identifier", "op": "present" },
+          "level": "medium",
+          "title": "GuardIdentifier ${guard_id_bad_identifier} resolves to non-address type (${guard_id_bad_type})",
+          "description": "Allocator ${guard_id_bad_index} uses sharing.who=GuardIdentifier(${guard_id_bad_identifier}), but Passport table[${guard_id_bad_identifier}] is of type ${guard_id_bad_type}, not address. Move will abort with ERECIPIENT_IDENTIFIER_NOT_ADDRESS at alloc() time.",
+          "scenario": "Passport table entry type mismatch",
+          "mitigation": "Ensure Passport table[${guard_id_bad_identifier}] is address-typed, OR use sharing.who=Entity with a static address.",
+          "evidence": "identifier=${guard_id_bad_identifier}, type=${guard_id_bad_type}",
+          "stakeholders": ["recipient"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-A-2-03",
+      "dimension": "semantic",
+      "trigger": "Duplicate Guard addresses in allocators (alloc_by_guard address match only hits the first one)",
+      "cases": [
+        {
+          "when": { "field": "duplicate_guards_present", "op": "eq", "value": true },
+          "level": "medium",
+          "title": "Duplicate Guard addresses in allocators",
+          "description": "Multiple Allocators reference the same Guard object: ${duplicate_guards_csv_sp}. alloc_by_guard locates the Allocator by iterating guard addresses; duplicate addresses only match the first one, so subsequent duplicate Allocators are unreachable (dead code).",
+          "scenario": "Reusing same Guard object across multiple Allocators",
+          "mitigation": "Create independent Guard objects for each Allocator (they may share root/table but must differ in description).",
+          "evidence": "total=${allocators_total}, unique=${allocators_unique}, dupes=${duplicate_guards_csv}",
+          "stakeholders": ["owner", "allocator"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-A-2-04",
+      "dimension": "semantic",
+      "trigger": "GuardIdentifier recipients combined with payment_info.for_object anchor state (Some = enforced, None = absent)",
+      "cases": [
+        {
+          "when": { "all": [
+            { "field": "for_object_anchor_known", "op": "eq", "value": true },
+            { "field": "guard_identifier_recipient_present", "op": "eq", "value": true },
+            { "field": "for_object_anchor_set", "op": "eq", "value": true }
+          ] },
+          "level": "medium",
+          "title": "payment_info.for_object anchor is ENFORCED at allocation execution",
+          "description": "payment_info.for_object is set to ${for_object_anchor}. At allocation execution, every Recipient::GuardIdentifier submission must equal this address or the whole tx aborts with ERECIPIENT_NOT_FOR_OBJECT (15) — a wrong anchor or a guard whose passport submits a different address makes the allocation permanently fail (payment_info is immutable after create). Verify the anchor matches the intended recipient flow.",
+          "scenario": "Allocation created with a declared for_object binding and GuardIdentifier recipients",
+          "mitigation": "Before create: confirm for_object is the object the GuardIdentifier submissions will resolve to (the guard's passport must submit exactly this address for the recipient identifier). Entity/Signer sharing lines are unaffected by the anchor.",
+          "evidence": "for_object=${for_object_anchor}",
+          "stakeholders": ["owner", "recipient"]
+        },
+        {
+          "when": { "all": [
+            { "field": "for_object_anchor_known", "op": "eq", "value": true },
+            { "field": "guard_identifier_recipient_present", "op": "eq", "value": true },
+            { "field": "for_object_anchor_set", "op": "eq", "value": false }
+          ] },
+          "level": "medium",
+          "title": "payment_info.for_object = None — GuardIdentifier destination has no on-chain anchor",
+          "description": "payment_info.for_object is not set: alloc() enforces NO recipient binding for Recipient::GuardIdentifier lines. Whoever builds the passport chooses the payout address; nothing on-chain constrains it. This is legal by design (Allocation is a generic component, the anchor is opt-in), but it means recipient routing is trust-on-creator.",
+          "scenario": "Allocation created without a for_object anchor while using GuardIdentifier recipients",
+          "mitigation": "If enforced routing is desired, set payment_info.for_object to the intended recipient anchor at create (it becomes mechanism-enforced: mismatch aborts with code 15). If no anchor is intended, document that the recipient is the passport builder's choice and constrain it in the guard expression instead.",
+          "evidence": "for_object=None",
+          "stakeholders": ["owner", "recipient"],
+          "exposure": {
+            "loss_parties": [
+              { "role": "merchant", "basis": "With no anchor, the payout address of a GuardIdentifier line is whatever the passport submits — service revenue routed through this allocator can be redirected away from the intended recipient with nothing on-chain objecting." }
+            ],
+            "gain_paths": [
+              { "role": "collaborator", "path": "The passport builder names any address as the submitted recipient; alloc() pays it verbatim (no for_object check runs when the anchor is None).", "viability": "viable", "gate": "The anchor is opt-in and absent — the routing decision sits entirely with whoever builds the passport; treat the builder identity as the control point." }
+            ]
+          }
+        }
+      ]
+    },
+    {
+      "rule_id": "R-A-3-01",
+      "dimension": "authority",
+      "trigger": "Service already published — order_allocators is immutable",
+      "cases": [
+        {
+          "when": { "field": "host_service_published", "op": "truthy" },
+          "level": "high",
+          "title": "order_allocators immutable after Service publish",
+          "description": "Service is already published. order_allocators field is now immutable (safety-rules.ts:170-174). Any configuration error (wrong Guard, wrong sharing proportion, wrong Entity address) will affect ALL subsequent orders and cannot be fixed without creating a new Service.",
+          "scenario": "Attempting to modify order_allocators after Service publish",
+          "mitigation": "1) Verify the configuration is correct before publish. 2) Use deploy-scanner pre-publish validation. 3) If already published with errors, create a new Service to replace.",
+          "evidence": "host_service_published=${host_service_published}",
+          "stakeholders": ["owner", "service_provider"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-A-3-02",
+      "dimension": "authority",
+      "trigger": "Treasury Permission inconsistent with Service Permission",
+      "cases": [
+        {
+          "when": { "field": "treasury_perm_mismatch", "op": "eq", "value": true },
+          "level": "medium",
+          "title": "Treasury Permission inconsistent with Service Permission",
+          "description": "sharing.who=Entity points to Treasury ${treasury_perm_entity} whose Permission (${treasury_perm_treasury}) differs from Service Permission (${host_service_permission}). Two different permission organizations control fund flow, creating potential authority conflicts.",
+          "scenario": "Treasury owned by different party than Service",
+          "mitigation": "Create Treasury with the same Permission object as the Service, OR ensure both are owned by the same address.",
+          "evidence": "treasury=${treasury_perm_entity}, treasuryPerm=${treasury_perm_treasury}, servicePerm=${host_service_permission}",
+          "stakeholders": ["owner", "service_provider"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-A-3-03",
+      "dimension": "authority",
+      "trigger": "No ALLOCATION_* builtin permission index — Allocation has no independent access control",
+      "cases": [
+        {
+          "when": { "all": [
+            { "field": "allocation_create_op", "op": "eq", "value": true },
+            { "field": "allocation_standalone", "op": "eq", "value": true }
+          ] },
+          "level": "low",
+          "title": "Allocation has no builtin permission index (passive-object design)",
+          "description": "BuiltinPermissionIndex has no ALLOCATION_* entries. Allocation's access control is fully delegated to Guard + Passport. In standalone mode (trigger_source=standalone), there is no Service/Arbitration layer to enforce caller authorization — Guard MUST provide sufficient access control (see R-A-3-04). This is the 'passive object' design philosophy, not a defect, but standalone mode shifts full responsibility to the Guard configuration.",
+          "scenario": "Standalone Allocation creation (user-initiated, no Service context)",
+          "mitigation": "For standalone Allocation, ensure Guard binds Signer or enforces time-lock (see R-A-3-04). Document this design choice explicitly.",
+          "evidence": "BuiltinPermissionIndex has no ALLOCATION_* entries; trigger_source=${trigger_source_display}",
+          "stakeholders": ["system"]
+        },
+        {
+          "when": { "all": [
+            { "field": "allocation_create_op", "op": "eq", "value": true },
+            { "field": "allocation_standalone", "op": "eq", "value": false }
+          ] },
+          "level": "low",
+          "title": "Allocation has no builtin permission index (passive-object design)",
+          "description": "BuiltinPermissionIndex has no ALLOCATION_* entries. Allocation's access control is fully delegated to Service (SERVICE_ORDER_ALLOCATOR=313) or Arbitration (ARBITRATION_FEES_ALLOC=365). This is the 'passive object' design philosophy, not a defect. In embedded mode, the host Service/Arbitration provides an additional access-control layer on top of Guard + Passport.",
+          "scenario": "Embedded Allocation creation (via Service order_allocators or Arbitration fee allocation)",
+          "mitigation": "For embedded Allocation, ensure Service/Arbitration permission configuration is correct. Document this design choice explicitly.",
+          "evidence": "BuiltinPermissionIndex has no ALLOCATION_* entries; trigger_source=${trigger_source_display}",
+          "stakeholders": ["system"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-A-3-04",
+      "dimension": "authority",
+      "trigger": "Standalone Allocation (trigger_source=standalone) with Guard lacking both Signer binding and time-lock",
+      "cases": [
+        {
+          "when": { "field": "standalone_weak_guards_count", "op": "gte", "value": 1 },
+          "level": "high",
+          "title": "Standalone Allocation: ${standalone_weak_guards_count} Guard(s) lack Signer binding AND time-lock",
+          "description": "Standalone Allocation (trigger_source=standalone) has no Service-layer access control. The following Guard(s) lack both Signer binding (context(Signer)==authorized) and time-lock (context(Clock).timestamp>=unlock): ${standalone_weak_guards_csv_sp}. Anyone who passes these Guards can trigger alloc() and receive funds, with no additional authorization layer. This is the most severe standalone-mode risk.",
+          "scenario": "Standalone Allocation created with weak Guard (no Signer binding, no time-lock)",
+          "mitigation": "Option A (preferred): configure Guard to bind context(Signer)==authorized_address, so only the owner can trigger alloc(). Option B: configure Guard with time-lock (context(Clock).timestamp>=unlock_time) for vesting-style releases. Option C: switch to embedded mode (via Service) to leverage Service-layer access control. Until fixed, this Allocation should not receive funds.",
+          "evidence": "trigger_source=standalone, weakGuards=${standalone_weak_guards_csv}",
+          "stakeholders": ["owner", "recipient", "system"],
+          "exposure": {
+            "loss_parties": [
+              { "role": "merchant", "basis": "Standalone mode has no Service/Arbitration layer above the Guard — whoever passes the weak Guard triggers alloc() and routes the pool away from the intended recipients." },
+              { "role": "buyer", "basis": "If the pool was funded with escrowed buyer funds, a hijacked alloc() drains that escrow leg." }
+            ],
+            "gain_paths": [
+              { "role": "neutral", "path": "Any caller whose passport satisfies the weak Guard (no Signer binding, no time-lock) triggers alloc() and takes the distribution defined by the sharing lines.", "viability": "viable", "gate": "Neither caller identity nor time constrains the trigger — the Guard pass itself is the only gate." }
+            ]
+          }
+        }
+      ]
+    },
+    {
+      "rule_id": "R-A-4-01",
+      "dimension": "lifecycle",
+      "trigger": "caller-specified guard with no matching Allocator — silent return causes funds to be stuck",
+      "cases": [
+        {
+          "when": { "all": [
+            { "field": "allocators_config_present", "op": "eq", "value": true },
+            { "field": "allocators_count", "op": "gt", "value": 1 },
+            { "field": "has_fallback_allocator", "op": "falsy" }
+          ] },
+          "level": "critical",
+          "title": "caller-specified guard with no matching Allocator — silent return causes funds to be stuck",
+          "description": "Multi-Allocation configuration (${allocators_count} Allocators) without alternative Allocator. alloc() is driven by the caller explicitly specifying an Allocator via alloc_by_guard: if the guard address does not match any allocators[].guard, alloc() silently returns (no error, no distribution), funds remain stuck in Allocation.balance, and the caller gets no immediate signal. Linked to guard-risk.ts R-X1-05.",
+          "scenario": "Caller passes a guard address not present in allocators[] (e.g. wrong Guard object, or order state not matching any terminal node)",
+          "mitigation": "1) The caller should verify alloc_by_guard ∈ allocators[].guard address set before calling alloc(). 2) Provide an alternative Allocator and document the caller's retry strategy. 3) Caller should check balance==0 after alloc() to detect no-match.",
+          "evidence": "allocators=${allocators_count}, hasFallback=${has_fallback_allocator_display}",
+          "stakeholders": ["owner", "service_provider", "system"],
+          "exposure": {
+            "loss_parties": [
+              { "role": "buyer", "basis": "A no-match alloc_by_guard call silently distributes nothing — the escrowed order funds sit frozen in Allocation.balance with no error to surface the miss." },
+              { "role": "merchant", "basis": "The merchant share stays frozen with the pool until a caller retries with a matching guard address." }
+            ],
+            "gain_paths": []
+          }
+        }
+      ]
+    },
+    {
+      "rule_id": "R-A-4-02",
+      "dimension": "lifecycle",
+      "trigger": "Multi-Allocation without mutually exclusive Guard conditions (design clarity issue, not a correctness requirement)",
+      "cases": [
+        {
+          "when": { "all": [
+            { "field": "allocators_config_present", "op": "eq", "value": true },
+            { "field": "allocators_count", "op": "gt", "value": 1 },
+            { "field": "guard_conditions_mutually_exclusive", "op": "falsy" }
+          ] },
+          "level": "medium",
+          "title": "Multi-Allocation without mutually exclusive Guard conditions",
+          "description": "Multi-Allocation (${allocators_count} Allocators) without verified mutual exclusion. Under caller-specified guard semantics, the caller explicitly selects an Allocator via alloc_by_guard, so there is no correctness problem of \"the latter is unreachable\"; however, if two Guard conditions can both pass simultaneously and the caller has no explicit selection strategy, the caller may be confused or bind to an unexpected path.",
+          "scenario": "Two Guard conditions overlap (e.g. amount<1000 and amount<500), caller Passport satisfies both",
+          "mitigation": "It is recommended that Guard conditions be strictly mutually exclusive (e.g. amount<1000 vs amount>=1000) to avoid caller confusion; alternatively, document explicitly which path the caller should prefer.",
+          "evidence": "allocators=${allocators_count}, mutuallyExclusive=${mutually_exclusive_display}",
+          "stakeholders": ["owner"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-A-4-03",
+      "dimension": "lifecycle",
+      "trigger": "Pure Amount mode without Surplus — residual balance reentrancy",
+      "cases": [
+        {
+          "when": { "field": "pure_amount_index", "op": "present" },
+          "level": "low",
+          "title": "Pure Amount mode without Surplus — residual balance reentrancy",
+          "description": "Allocator ${pure_amount_index} uses pure Amount mode (no Rate, no Surplus). After alloc(), if fix < balance, residual funds remain in Allocation.balance and can be claimed by re-triggering alloc(). Linked to guard-risk.ts reentrancy low.",
+          "scenario": "Pure Amount mode leaves residual balance",
+          "mitigation": "1) Preferred: add a Surplus sharing to absorb remainder. 2) Or use Rate mode. 3) Or add anti-reentrancy Guard check: logic_not(query('order.allocation some', object=order)).",
+          "evidence": "allocator[${pure_amount_index}].mode=pure-amount",
+          "stakeholders": ["owner", "system"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-A-5-01",
+      "dimension": "cross_object",
+      "trigger": "Order already has an Allocation bound (1:1 constraint)",
+      "cases": [
+        {
+          "when": { "field": "order_already_has_allocation", "op": "truthy" },
+          "level": "high",
+          "title": "Order already has an Allocation — 1:1 constraint violation",
+          "description": "Order ${bound_order_paren_display} already has an Allocation bound. Move layer will abort with E_ALLOCATION_ALREADY_SPECIFIED when attempting to bind a second Allocation.",
+          "scenario": "Attempting to bind a second Allocation to the same Order",
+          "mitigation": "Use the existing Allocation, or unbind it first (if supported), or create a new Order.",
+          "evidence": "bound_order=${bound_order_display}, alreadyHasAllocation=${order_already_has_allocation}",
+          "stakeholders": ["owner", "service_provider"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-A-5-02",
+      "dimension": "cross_object",
+      "trigger": "payment_info missing for alloc() — ENO_PAYMENT_INFO",
+      "cases": [
+        {
+          "when": { "all": [
+            { "field": "has_payment_info", "op": "falsy" },
+            { "field": "operation_type", "op": "eq", "value": "alloc_by_guard" }
+          ] },
+          "level": "high",
+          "title": "payment_info missing — alloc() will abort with ENO_PAYMENT_INFO",
+          "description": "Allocation has no payment_info set. Move alloc() requires payment_info.is_some() at step 1 (pre_check). The entire alloc() transaction will revert, funds remain in Allocation.",
+          "scenario": "Triggering alloc() before setting payment_info",
+          "mitigation": "Ensure payment_info is set during Allocation creation (CallAllocation_Create requires payment_info field).",
+          "evidence": "has_payment_info=false",
+          "stakeholders": ["owner"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-A-5-03",
+      "dimension": "cross_object",
+      "trigger": "MAX_ALLOCATOR_COUNT not synced to onchain-constants.ts",
+      "cases": [
+        {
+          "when": { "field": "always_true", "op": "eq", "value": true },
+          "level": "low",
+          "title": "MAX_ALLOCATOR_COUNT not synced to onchain-constants.ts",
+          "description": "The Move layer defines MAX_ALLOCATOR_COUNT=${max_allocator_count}, but onchain-constants.ts does NOT export this constant. SDK allocation.ts:318 defines it locally, creating a double-definition risk. MCP knowledge imports the local definition.",
+          "scenario": "Constant sync drift between Move / SDK / MCP",
+          "mitigation": "1) Add MAX_ALLOCATOR_COUNT=100 to onchain-constants.ts. 2) Update SDK allocation.ts to import from onchain-constants.js. 3) Delete local definition.",
+          "evidence": "MAX_ALLOCATOR_COUNT=${max_allocator_count} (local), not in onchain-constants.ts",
+          "stakeholders": ["system"]
+        }
+      ]
+    }
+  ]
+}