@wowok/agent-mcp 3.4.3 → 3.4.4

package/dist/knowledge/baselines/rules/personal.json.good

@@ -0,0 +1,139 @@
+{
+  "comment": "Personal rule pack (R-PERSONAL) — declarative form of the retired in-code Personal risk rules. Facts are produced by the kernel extractor (personal-risk.ts, bound to the inherited registrar record caps and the sensitive-content heuristic); rules only reference fact names. 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": {
+    "sensitive_hits_found": "True when the sensitive-content heuristic matched at least one information entry (phone / email / private key / mnemonic / secret-named).",
+    "sensitive_patterns_text": "Pre-rendered match list ('name=kind' entries joined by '; ') for the evidence text.",
+    "is_mark_destroy": "The caller is invoking the irreversible mark destroy operation.",
+    "has_referrer": "A referrer address is set (self-attested, unverified on-chain).",
+    "is_mark_transfer": "The caller is invoking the mark transfer operation (the source address loses the mark).",
+    "information_count": "Raw information record count, passed through for evidence text.",
+    "information_count_over_limit": "True when information_count is provided and meets or exceeds the inherited record-count cap.",
+    "expects_dedicated_move_struct": "The caller assumes a dedicated Personal Move struct exists (it does not — Personal composes Entity + Resource).",
+    "singleton_enforced": "True when the SDK enforces the one-record-per-account singleton invariant.",
+    "max_record_count_registrar": "KERNEL CONSTANT — record-count cap Personal inherits from the registrar entity layer.",
+    "max_record_length": "KERNEL CONSTANT — per-record length cap inherited from the registrar entity layer.",
+    "max_address_count": "KERNEL CONSTANT — address-list cap that applies via the entity layer.",
+    "max_tags_count": "KERNEL CONSTANT — tag cap that applies via the resource layer."
+  },
+  "rules": [
+    {
+      "rule_id": "R-PERSONAL-01",
+      "dimension": "semantic",
+      "trigger": "sensitive-content heuristic matched an information entry",
+      "cases": [
+        {
+          "when": { "field": "sensitive_hits_found", "op": "eq", "value": true },
+          "level": "high",
+          "title": "Sensitive information leakage — on-chain data is permanent",
+          "description": "information is stored via Entity.info_add as on-chain Records. The schema description warns 'NEVER: phone, address, private keys' but the Move layer does not validate content. Once a phone number, physical address, email, or private key is written on-chain, it is permanent and publicly readable — there is no delete (info_remove only removes the named entry from the user's record; the data remains in the transaction history).",
+          "scenario": "User adds information {name: 'phone', value: '+8613800000000'}; number is public forever",
+          "mitigation": "MCP schema description MUST warn. AI agents MUST re-confirm before adding any information entry. Business layer should run a sensitive-data regex (phone/email/private-key/mnemonic) and reject matches. Use the 'local' tool for private data.",
+          "evidence": "sensitive patterns: ${sensitive_patterns_text}",
+          "stakeholders": ["user"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-PERSONAL-02",
+      "dimension": "lifecycle",
+      "trigger": "mark destroy is being invoked",
+      "cases": [
+        {
+          "when": { "field": "is_mark_destroy", "op": "eq", "value": true },
+          "level": "medium",
+          "title": "mark destroy is irreversible — identity mark permanently lost",
+          "description": "The 'destroy' mark op permanently deletes the Resource object backing the user's identity mark. There is no archive, no event, and no rollback. After destroy, the user has no on-chain identity mark until they create a new one, and any external system keyed on the old Resource address breaks.",
+          "scenario": "User destroys their mark; downstream services keyed on the old Resource address fail",
+          "mitigation": "Require explicit confirmation before destroy. SDK should refuse destroy if any live consumer still references the mark. Provide a 'replace' alternative that swaps the underlying Resource without losing continuity.",
+          "evidence": "is_mark_destroy=true (irreversible)",
+          "stakeholders": ["user", "consumer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-PERSONAL-03",
+      "dimension": "semantic",
+      "trigger": "a referrer address is set",
+      "cases": [
+        {
+          "when": { "field": "has_referrer", "op": "eq", "value": true },
+          "level": "medium",
+          "title": "referrer chain can be abused to fabricate trust signals",
+          "description": "When registering, a user may specify any referrer address. There is no on-chain verification that the referrer actually invited the user. A sybil attacker can register many accounts chained to a reputable address, fabricating an association to borrow trust. The Registrar records referrer but does not validate consent.",
+          "scenario": "Attacker registers 100 accounts all citing a reputable merchant as referrer",
+          "mitigation": "Business layer should treat referrer as a self-attested hint, not a verified trust signal. Audit referrer chains off-chain; require the referrer to co-sign if used for trust scoring.",
+          "evidence": "has_referrer=true (self-attested, unverified)",
+          "stakeholders": ["user", "consumer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-PERSONAL-04",
+      "dimension": "structural",
+      "trigger": "information record count meets or exceeds the inherited cap",
+      "cases": [
+        {
+          "when": { "field": "information_count_over_limit", "op": "eq", "value": true },
+          "level": "low",
+          "title": "information inherits MAX_RECORD_COUNT_REGISTRAR=${max_record_count_registrar} — permissive",
+          "description": "Personal does not define its own record cap; it inherits Entity's MAX_RECORD_COUNT_REGISTRAR=${max_record_count_registrar} and MAX_RECORD_LENGTH=${max_record_length} per record. ${max_record_count_registrar} records per user is generous and can bloat on-chain storage if users add many entries. MAX_ADDRESS_COUNT=${max_address_count} and MAX_TAGS_COUNT=${max_tags_count} also apply via Entity/Resource.",
+          "scenario": "User adds 1000 information entries; Entity record storage is heavy and slow to read",
+          "mitigation": "Business layer should self-limit information count (e.g. ≤50). For bulk profile data, store off-chain and reference via a Repository or Proof.",
+          "evidence": "information_count=${information_count}, limit=${max_record_count_registrar}",
+          "stakeholders": ["user", "system"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-PERSONAL-05",
+      "dimension": "lifecycle",
+      "trigger": "mark transfer is being invoked",
+      "cases": [
+        {
+          "when": { "field": "is_mark_transfer", "op": "eq", "value": true },
+          "level": "medium",
+          "title": "mark transfer loses identity mark at the source address",
+          "description": "The 'transfer' mark op moves the Resource backing the identity mark to a new address. After transfer, the source address has no mark — any service that keyed identity on the source address loses the binding. There is no automatic forwarding stub left behind.",
+          "scenario": "User transfers mark to a new wallet; old-wallet-based logins all break",
+          "mitigation": "Surface a 'transfer will detach the mark from this address' warning. Consumers should track marks by Resource address, not by user address. Provide a migration window where both addresses are valid.",
+          "evidence": "is_mark_transfer=true (source loses mark)",
+          "stakeholders": ["user", "consumer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-PERSONAL-06",
+      "dimension": "cross_object",
+      "trigger": "caller assumes a dedicated Personal Move struct",
+      "cases": [
+        {
+          "when": { "field": "expects_dedicated_move_struct", "op": "eq", "value": true },
+          "level": "low",
+          "title": "Personal has no dedicated Move struct — depends entirely on Entity + Resource",
+          "description": "Personal is an SDK-layer construct: there is no dedicated Move module. The SDK composes Entity (information/description) and Resource (mark) on behalf of the user. Any breaking change in Entity or Resource directly affects Personal. The MCP layer cannot fix Personal bugs without touching Entity/Resource.",
+          "scenario": "Entity schema changes; Personal.information silently breaks",
+          "mitigation": "Track Entity and Resource changelogs as first-order dependencies of Personal. Add integration tests that exercise Personal flows whenever Entity/Resource change.",
+          "evidence": "expects_dedicated_move_struct=true (none exists)",
+          "stakeholders": ["system"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-PERSONAL-07",
+      "dimension": "lifecycle",
+      "trigger": "singleton invariant not enforced by the SDK",
+      "cases": [
+        {
+          "when": { "field": "singleton_enforced", "op": "falsy" },
+          "level": "medium",
+          "title": "Singleton assumption — if violated, multiple Personal instances conflict",
+          "description": "Personal assumes each account has exactly one Entity record (and one Resource mark). The Move layer enforces this via the registration operation's idempotency (returns the existing Resource for already-registered users). But if the SDK ever bypasses registration and creates duplicates (e.g. via the forced re-registration path), downstream code that assumes a singleton would see inconsistent state.",
+          "scenario": "SDK calls the forced re-registration path; user now has two Resource marks",
+          "mitigation": "SDK MUST enforce the singleton invariant: refuse to call the forced re-registration path unless the user explicitly opts in. Document that forced re-registration invalidates the old Resource address.",
+          "evidence": "singleton_enforced=false (needs SDK guard)",
+          "stakeholders": ["user", "consumer"]
+        }
+      ]
+    }
+  ]
+}

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

@@ -48,6 +48,9 @@
     "first_path_dependent_anchor": "First guard step id using a path-dependent time query (TIME-ANCHOR-01, E-10)",
     "path_sensitive": "The anchored node is reachable by more than one path, so the anchor can shift",
     "first_write_only_unenforced_field": "First write-only param set with no guard query covering it (WRITE-ONLY-01, A-1/A-10)",
+    "write_once_removable_count": "Configure steps that dissolve a write_once policy attestation — policies op:'set' dropping it, op:'remove'/'clear' touching it, or a same-name op:'add' without write_once (WRITE-ONCE-REMOVABLE, W8-5 / N-10)",
+    "first_write_once_removable": "First write_once-dissolving configure step, rendered as: step 'id': <violation>: policy names",
+    "write_once_removable_display": "Semicolon-joined list of ALL write_once-dissolving configure steps",
     "first_orphan_guard": "First guard step id never referenced by any host binding (HOST-GRAPH-01, B-2)",
     "first_repo_query_without_repository": "First guard step id querying repository.* while the plan creates no repository (HOST-GRAPH-01, B-2)",
     "first_edge_guard_missing_254": "First guard step id bound on a machine forward whose table declares no {identifier: 254, b_submission: true} row (TASKBIND-01, N-K20: progress::assert_task_binding aborts code 11)",
@@ -86,6 +89,8 @@
     "fund_arb_route_unfunded": "A post-settlement arbitration re-route exists AND the compensation pool is absent or deposits 0 — the ruling payout aborts 27 (E_COMPENSATION_NOT_MATCH), so the promised exit is dead by construction (FUND-ZERO-01)",
     "entry_no_open_exit": "The order-landing node (entry-edge target) exits only through CLOSING time windows (Clock <= anchor legs, no opening leg, no unguarded alternative) — once a window closes nothing can advance the order and the entry escrow is locked (ENTRY-ABANDON-01, gf26 GF2-30)",
     "entry_strand_node": "First stranded entry node name (ENTRY-ABANDON-01 judgment gate)",
+    "window_strand_nodes": "Comma-joined NON-ENTRY rest nodes whose EVERY exit is gated by a CLOSING time window (Clock <= anchor, no opening leg, no unguarded alternative) — once the window elapses the order cannot advance and the escrow held at that rest state has no firing rail (ENTRY-ABANDON-01 case ②, ctrx-mn-261108 O14/O15/O19: 1.10 WOW stranded after a claim_window's only exits closed)",
+    "window_strand_count": "How many non-entry rest nodes are window-stranded (ENTRY-ABANDON-01 case ② judgment gate)",
     "arb_promise_without_settle_rail": "A machine guard reads the arbitration ruling family while NO $ref-visible allocator row releases money on the ruling (none reads the family, none rides the ruling edge node-free, and the ruling edge's destination has no FUND-EXIT-01-style allocator coverage); guard_key-declared rails are plan-opaque and left to the freeze gate — the verdict moves state, never money (POST-ARB-SETTLE-01, gf26 GF2-31)",
     "arb_promise_node": "First node whose exit edge carries the arbitration-promise guard (POST-ARB-SETTLE-01 judgment gate)",
     "arb_key_plane_opaque": "The machine carries arbitration-promise guards while the allocator rail plane carries guard_key declarations — rails the $ref plane cannot verify, so the POST-ARB-SETTLE-01 verdict rule stays silent there by ruling; this shape is the freeze gate's red line: ARB-KEY-PLANE-01 fires high and preflightPlan refuses the publish until the keys resolve into structured guard steps (user ruling 2026-10-26)",
@@ -94,13 +99,64 @@
     "repo_gate_key_unbacked_count": "Composite where-query scans over a plan-local repository whose static key no declared policy uses (REPO-GATE-KEY-01, ZR-32)",
     "first_repo_gate_key_unbacked": "First unbacked gate key, rendered as 'key' in guard 'step-id'",
     "repo_gate_key_unbacked_display": "Comma-joined list of ALL unbacked gate keys",
+    "wip_query_totality_count": "Guard order.item.wip_hash comparisons whose static String operand is NOT a case-exact sale name in the plan's sales catalog — find_sale_item misses at delivery, the native Err wedges the order with a primitive error inside verify_guard (R-QUERY-TOTALITY, kl F-ORDER-02); service.sale.wip_hash is out of scope (WIP-listing namespace); present only when a sales catalog exists AND at least one unprovable comparison burns",
+    "first_wip_query_totality": "First unprovable comparison, rendered as guard 'step-id': <query> vs '<constant>'",
+    "wip_query_totality_display": "Semicolon-joined list of ALL unprovable wip-hash comparisons",
+    "wip_query_totality_sku_display": "Comma-joined case-exact sale names the plan's catalog declares — the only shippable comparison constants",
+    "late_remedy_edge_count": "Machine edges whose forward name ends with `_late` — the K3 D3 after-hours twins a plan ships (late_remedy_mode = 'keeper_reopen' mounts one per closing-window edge, or the plan declares twins by hand). Present whenever a late rail exists: shipping one is itself a disclosure (an intent to operate outside the declared window)",
+    "late_remedy_gate_missing": "TRUE when any `{forward}_late` edge is bound to guards NONE of which carry the 1008 keeper membership leg (permission.entity.perm) — an ANONYMOUS after-hours rail: no keeper identity behind the reopen key (R-LATE-REMEDY, K3 D3)",
+    "first_late_remedy_gate_missing": "First anonymous late edge, rendered as 'prev -> next (forward)'",
+    "late_remedy_gate_missing_display": "Semicolon-joined list of ALL anonymous late edges",
+    "repo_agg_submitted_count": "Guard sum-where aggregates whose repository operand resolves to a SUBMITTED table cell — the advancing caller fills the ledger identity at forward time and can point the aggregate anywhere (REPO-AGG-SUBMITTED-01, W6-03 / upynjab P0-1)",
+    "first_repo_agg_submitted": "First submitted aggregate slot, rendered as 'slot N of guard 'step-id''",
+    "repo_agg_submitted_display": "Comma-joined list of ALL submitted aggregate slots",
+    "alloc_overlap_payee_count": "Allocator row pairs whose accepted-node sets INTERSECT but which pay DIFFERENT recipient sets — a double-pay race on the shared order state (INV-ALLOC-OVERLAP-PAYEE, W6-06; node overlap itself is the sanctioned C-F01/decision-11 shape)",
+    "first_alloc_overlap_payee": "First conflicting pair, rendered as row#i(track,guard,pays …) vs row#j(…) share node(s) [x,y] with different payees",
+    "alloc_overlap_payee_display": "Semicolon-joined list of ALL conflicting pairs",
     "sales_step_present": "The plan materializes at least one sellable SKU (a service create with a non-empty sales list, or a configure step with method 'sales') — the order entry's existence predicate (PLAN-SALES-01)",
     "dead_sku_count": "Sales whose name exceeds the on-chain 64-byte BUY limit (the listing path accepts up to 256 bytes but the buy path caps buyer-sent item names at 64 and matches EXACTLY — a 65..256-byte name is publishable yet every order_new aborts E_NAME_LENGTH_EXCEEDED) — present only when at least one dead SKU is listed (SKU-NAME-64 advisory, F-RQ-01 / rqd3-tn-261030)",
     "first_dead_sku_name": "First over-limit sale name",
     "first_dead_sku_bytes": "That name's UTF-8 byte length",
     "guard_reach_contradiction_count": "Root-AND-chain legs carrying proof-level structural unreachability (ordering interval crossing; == to two different numeric constants or to opposite Bools; == X conjoined with a strict ordering past X; same-binding self-comparison with a strict direction) — the guard predicate is unsatisfiable by construction (GUARD-REACH-01, S3 plane)",
     "first_guard_reach_contradiction": "First contradiction, rendered as: guard 'step-id' (channel): OP X contradicts OP X — unsatisfiable",
-    "guard_reach_contradiction_display": "Semicolon-joined list of ALL proof-level unreachability contradictions in the plan's guard roots"
+    "guard_reach_contradiction_display": "Semicolon-joined list of ALL proof-level unreachability contradictions in the plan's guard roots",
+    "fractional_day_knob_count": "Fractional `*_days` knobs riding the PRESENTED plan's step params or resolved inputs — the publish-face semantic twin of the build face's PLAN-P0-18 blocker (TWIN-WINDOW-ZERO); absent when none",
+    "first_fractional_day_knob": "First fractional day knob, rendered as: step 'step-id': param.path = value — the U64 day slot truncates to N at BCS encode",
+    "fractional_day_knob_display": "Semicolon-joined list of ALL fractional day knobs on the presented plan",
+    "fractional_hour_knob_count": "Fractional `*_hours`/`*_minutes` leaves riding the PRESENTED plan's step params — the publish-face semantic twin of the build face's pdd F-09 hours blocker (TWIN-WINDOW-ZERO-HOURS); absent when none",
+    "first_fractional_hour_knob": "First fractional hours leaf, rendered as: step 'step-id': param.path = value — the U64 hour/minute slot truncates to N at BCS encode",
+    "fractional_hour_knob_display": "Semicolon-joined list of ALL fractional hours/minutes leaves on the presented plan's step params",
+    "guard_equality_drift_count": "Guards whose description promises hash/wip equality while the root carries NO logic_equal leg — existence-only enforcement, a forged hash clears it (GUARD-EQUALITY-DRIFT, ofnz8 F-49; shared predicate knowledge/guard-quality.ts, same function the template scanner runs)",
+    "first_guard_equality_drift": "First equality-drift guard, rendered as: guard 'step-id': description promises hash/wip equality but the root carries no logic_equal leg",
+    "guard_equality_drift_display": "Semicolon-joined list of ALL equality-drift guards",
+    "guard_threshold_literal_count": "Guards carrying a threshold-named U64 row whose value is the literal 1 — a 1-raw-unit floor is no floor (GUARD-THRESHOLD-LITERAL, ofnz8 F-70)",
+    "first_guard_threshold_literal": "First threshold-literal guard, rendered as: guard 'step-id': row 'name' = literal 1 (U64 threshold floor)",
+    "guard_threshold_literal_display": "Semicolon-joined list of ALL threshold-literal guards",
+    "guard_set_collapse_count": "Guards whose table repeats one String literal across >= 2 non-submission rows — the declared set collapsed to one member (GUARD-SET-COLLAPSE, ofnz8 F-51/F-52)",
+    "first_guard_set_collapse": "First set-collapse guard, rendered as: guard 'step-id': literal 'v' repeated across N rows (a, b)",
+    "guard_set_collapse_display": "Semicolon-joined list of ALL set-collapse guards",
+    "guard_input_trust_count": "Guards whose repository find/keys_where ids operand resolves to a caller-SUBMITTED (b_submission:true) table row — the candidate row set is self-attested (GUARD-INPUT-TRUST, ofnz8 P0-4(b))",
+    "first_guard_input_trust": "First input-trust guard, rendered as: guard 'step-id': find/keys ids operand resolves to caller-submitted row 'name' (identifier N)",
+    "guard_input_trust_display": "Semicolon-joined list of ALL input-trust guards",
+    "guard_abort_unsafe_count": "Guards referencing a verb whose native handler aborts (W_FIELD_NOT_FOUND) when the addressed record is absent — the guard engine evaluates every leaf before the boolean merge, so no structure shields the abort (GUARD-ABORT-SAFE-01, B-30)",
+    "first_guard_abort_unsafe": "First abort-unsafe guard, rendered as: guard 'step-id': query 'verb' aborts when the target record is absent",
+    "guard_abort_unsafe_display": "Semicolon-joined list of ALL abort-unsafe guards",
+    "first_guard_find_polarity": "First guard anchoring a history clock at find:\"first\" on a renewal/charge loop node — period 2+ reads the FIRST visit's timestamp (GUARD-FIND-POLARITY, ofnz8 F-61). Per-guard attribution (ofn-mn-261108 F-02): names the per-period CLAIMING guard when one exists, else the first bare anchor",
+    "guard_find_polarity_count": "Total find:\"first\" periodic-node anchors across the plan's guards",
+    "guard_find_polarity_per_period": "At least one such anchor's description claims PER-PERIOD semantics the find:\"first\" polarity cannot deliver — the critical face of the family",
+    "guard_find_polarity_display": "Semicolon-joined list of ALL periodic-anchor guards, each rendered with its own guard id, target node, and per-period verdict",
+    "refund_convergence_missing": "The plan ships a refund-track allocator row but NO machine edge into closed_refunded is gated by order.principal_refunded (chain-query 1579, the RefundStamp latch) — the refund loop has no provable close (R-REFUND-CONVERGENCE, K3 C3). CHAIN-TRUTH CORRECTION (upw-b7k2 R3, 2026-11-09): the O-F22 zombie-order shield (progress.move:600) aborts EVERY order-scoped advance/hold AFTER the principal is fully refunded, and the abort fires BEFORE guard evaluation (progress.move:634/672) — so this convergence edge can NEVER fire: full refund latches the guard's own precondition but the advance aborts first; partial refund leaves the latch false. The latch QUERY itself (1579) is the refund loop's real close proof; the edge is bookkeeping-dead pending the kernel whitelist proposal (see PG-ZOMBIE-01). Do not treat reaching closed_refunded as a live path",
+    "withdraw_no_case_bind_count": "WithdrawClaim machine edges whose bound guards read NO order.dispute.open leg (chain-query 1576) — a withdrawal with no case binding: replay farming (file->withdraw cycles need no new on-file dispute) and phantom/foreign cases satisfy nothing but also block nothing (R-WITHDRAW-NO-CASE-BIND, PT-26/ssng6)",
+    "first_withdraw_no_case_bind": "First such unbound withdraw edge, rendered as prev->next",
+    "withdraw_no_case_bind_display": "Semicolon-joined list of ALL unbound withdraw edges",
+    "settlement_triggers_display": "Semicolon-joined per-settlement-rail caller-identity faces: each rail's bound guard identity legs (order.owner==signer / order.agent has signer / order.service binding / permission role), or the kernel edge-rail default when the guard carries no caller face — the 'who can trigger settlement' disclosure (K3 C4)",
+    "settlement_buyer_only_count": "Settlement rails whose ONLY caller face is the order-holder leg (order.owner/order.agent) with no service-binding or permission-role face — the buyer triggers the merchant's settlement (role-reversal advisory, SETTLEMENT-TRIGGER-SCOPE)",
+    "dispute_freeze_rail_count": "Machine edges OTHER than withdraw edges whose bound guards read order.dispute.open (chain-query 1576) — dispute-freeze money rails gated on the open-dispute state (R-DISPUTE-EXIT-REACHABILITY, ss10 F-SS10-01)",
+    "dispute_freeze_rail_display": "Semicolon-joined list of ALL dispute-freeze rail edges, rendered as prev->next",
+    "dispute_exit_live_withdraw_count": "Withdraw-class edges whose guards read order.dispute.open (case-bound) but carry NO order.claimed_by disposition precondition — taking the edge leaves the case live forever (dispute vector is push-only, claimed_by has no clearer), freezing every dispute-freeze rail (ss10 F-SS10-01)",
+    "dispute_exit_live_withdraw_display": "Semicolon-joined list of ALL live-withdraw edges, rendered as prev->next",
+    "dispute_exit_dead_topology": "Flag: freeze rails + live withdraw edges coexist AND the machine exposes NO conclude/compensate-class forward — NOTHING can stamp claimed_by, the frozen rails are unreachable, escrow locks with no recovery path (high)",
+    "dispute_exit_indirect_stamp": "Flag: freeze rails + live withdraw edges coexist AND a conclude/compensate-class forward exists — recovery only via a FULL fresh arbitration cycle filed after the withdraw (medium disclosure)"
   },
   "rules": [
     {
@@ -262,6 +318,14 @@
           "description": "Every forward leaving '${entry_strand_node}' — the node orders land on at entry — is gated by a closing time window (Clock <= anchor) with no opening leg and no unguarded alternative. Once the window passes the guard aborts forever: the order can never advance, and the escrow collected at entry is locked with no abandon/refund path. This is the GF2-30 live loss shape (7.65 WOW); shipping it bakes the lockup in permanently.",
           "mitigation": "Add a self-healing exit from '${entry_strand_node}' gated on an OPENING window (logic_as_u256_greater_or_equal[Clock, anchor] — the abandon/refund edge that fires when the claim window elapses) targeting a fund-bearing node, so the escrow always keeps an after-window path; or leave one exit unguarded / gated on an any-time condition.",
           "stakeholders": ["merchant", "customer"]
+        },
+        {
+          "when": { "field": "window_strand_nodes", "op": "truthy" },
+          "level": "high",
+          "title": "Rest state(s) '${window_strand_nodes}' exit only through closing windows — the escrow strands once they elapse",
+          "description": "Every forward leaving '${window_strand_nodes}' is gated by a closing time window (Clock <= anchor) with no opening leg and no unguarded alternative. Those nodes are not entry nodes, but the escrow is still HELD while the order rests there — and a machine has no rail that can fire at an arbitrary node: once the last window closes nothing advances the order and no allocator row covers that state, so the money sits until the protocol changes. This is the live ctrx-mn-261108 C shape (O14/O15/O19, 1.10 WOW): a claim_window whose FileDispute/WithdrawClaim exits both aborted after the window, while the fund rails only covered completed / closed_cancel / return_closed / claim_withdrawn. Filing is deliberately unrestricted in time (arbitration.move order-anchored filing-window gate removed 2026-11-08), so a late filing can pin an otherwise settleable order — the fix must exist in the MACHINE, not in a filing clock.",
+          "mitigation": "Give every such rest state at least one exit that stays walkable after its windows close — an OPENING-window fallback (Clock >= anchor), an unguarded advance, or a node-free/any-time guard — and route it to a node covered by a fund rail (or make the cover rail accept this node explicitly). A state where money rests with no after-window exit is a publish-time defect, not an operator duty.",
+          "stakeholders": ["merchant", "customer"]
         }
       ]
     },
@@ -440,6 +504,21 @@
         }
       ]
     },
+    {
+      "rule_id": "WRITE-ONCE-REMOVABLE",
+      "dimension": "field_capability",
+      "trigger": "A plan declares a write_once policy (a non-repudiable on-chain attestation) and a later configure step dissolves it: policies op:'set' that omits the policy, op:'remove'/'clear' that touches it, or a same-name op:'add' without write_once:true (W8-5, N-10).",
+      "cases": [
+        {
+          "when": { "field": "first_write_once_removable", "op": "present" },
+          "level": "high",
+          "title": "Write-once attestation dissolved: ${first_write_once_removable}",
+          "description": "Row-level deletion under a write_once policy is chain-refused since P155-14③ (repository data_remove aborts E_POLICY_WRITE_ONCE_CONFLICT under enable_repo_write_once_remove_guard, the v140 rider flag) — but the write_once BIT lives in a mutable PolicyRule. ${first_write_once_removable} replaces, removes, or downgrades the POLICY itself, so whoever holds the policy-management permission (index 102) can rewrite the attestation and, via re-add, delete the very rows it promised to keep. op:'set' REPLACES THE WHOLE policy list, and once the Permission is locked a dropped policy cannot be restored.",
+          "mitigation": "Maintain repository policies with op:'add' appends only; never ship a configure step whose op:'set'/'remove'/'clear' — or a same-name op:'add' lacking write_once:true — touches a write_once policy declared earlier in the plan.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
     {
       "rule_id": "TASKBIND-01",
       "dimension": "fund_flow",
@@ -598,6 +677,51 @@
         }
       ]
     },
+    {
+      "rule_id": "R-QUERY-TOTALITY",
+      "dimension": "composition",
+      "trigger": "A guard compares the per-item listing query (order.item.wip_hash) against a STATIC String constant that is NOT a case-exact sale name in the plan's sales catalog (kl F-ORDER-02: the delivery guard burned 'Adult Ticket' while the order bought '2-Day Ticket'). At delivery the native resolves the constant with find_sale_item; a miss returns None -> Err, the error bubbles through passport::verify_guard as a MovePrimitiveRuntimeError, and the order WEDGES on its current node — no completion, no refund, no structured abort code. Guards freeze at creation, so this is the last point the mismatch can be caught; repository-key totality is REPO-GATE-KEY-01's face, this rule owns the query-arg totality face. service.sale.wip_hash resolves against the WIP LISTING namespace (not the sales catalog) and stays out of scope.",
+      "cases": [
+        {
+          "when": { "field": "wip_query_totality_count", "op": "gt", "value": 0 },
+          "level": "critical",
+          "title": "wip-hash comparison constant '${first_wip_query_totality}' is not a sale name — the order will wedge at delivery",
+          "description": "Unprovable comparisons: ${wip_query_totality_display}. The plan's sales catalog: ${wip_query_totality_sku_display}. A wip-hash guard comparison burns its String operand at guard creation; find_sale_item over a non-SKU name returns None and the native's Err surfaces as a primitive error inside verify_guard — the delivery forward cannot advance and the order cannot refund (kl F-ORDER-02, wedged until a kernel upgrade). Only constants that ARE sale names are provably total.",
+          "mitigation": "Fix the burned constant to a case-exact sale name from the catalog (${wip_query_totality_sku_display}) BEFORE the guard is created — or re-point the comparison leg at a dynamic operand (the submitted SKU name / the order's own field) if the gate must accept any bought SKU. Guards are immutable once created: never publish first and patch later.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "REPO-AGG-SUBMITTED-01",
+      "dimension": "composition",
+      "trigger": "A guard's sum-where aggregate (query_repository_data_sum_where*) reads its ledger through a SUBMITTED table cell (b_submission:true). The cell is filled by whoever ADVANCES the guarded forward — so the ledger IDENTITY is a per-forward caller choice. An honest keeper submitting the wrong repository (e.g. the review ledger instead of the campaign ledger) reads sum=0 and permanently flips the decision — the release polarity aborts code 7 while the refund polarity passes on the same state; a hostile submission aims the gate at a forged ledger. Guards are IMMUTABLE once created, so nothing can repair a mis-pointed aggregate after publish (W6-03, upynjab P0-1). The catalog's threshold twins are pinned since the W6-03 fix (b_submission:false + a resolved value); this rule closes the same class for INLINE and hand-built guards at the machine-publish face.",
+      "cases": [
+        {
+          "when": { "field": "repo_agg_submitted_count", "op": "gt", "value": 0 },
+          "level": "high",
+          "title": "Aggregate gate '${first_repo_agg_submitted}' lets the advancing caller swap the ledger",
+          "description": "Submitted aggregate slots: ${repo_agg_submitted_display}. A sum-where aggregate is a CAMPAIGN-WIDE CONSTANT decision basis — the ledger it sums must never be chosen per-forward. With a submitted cell, the same on-chain state can read as goal-met (release) or goal-missed (refund) depending on which repository the caller submits — a decision flip that is UNREPAIRABLE after the guard is created (guards freeze at creation; the escrow only settles one way).",
+          "mitigation": "Pin the aggregate's object cell at guard creation: b_submission:false with a resolved value — the plan's own ledger ({$ref}/{$late} object, or a '$'-seeded name like ${repository_name}) or an explicit external address if the ledger is genuinely foreign. After fixing, re-verify with analyze_guard_semantics compare_with after creation.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "INV-ALLOC-OVERLAP-PAYEE",
+      "dimension": "composition",
+      "trigger": "Two allocator rows whose accepted-node sets INTERSECT pay DIFFERENT recipient sets. Scope discipline: node-set overlap across rails is itself the SANCTIONED shape (C-F01 ruling 2026-11-04 rejected the node-disjoint proposal; recover∈settle terminal sharing is the decision-11 doctrine — recover is an order-terminal liquidation). The money hazard is narrower: when the SAME order state can drive two rails with different payees, whichever forward advances first chooses where the escrow goes, and the losing rail still holds a live claim — a race that materializes only at runtime, i.e. AFTER the guards are immutable (W6-06, §0.26 user ruling ③). ADVISORY, not a blocker, by the catalog-clean rule (K3 discipline 8): the supply-chain composition family EMITS exactly this shape by design (a second settlement rail beside the shop's own; the emission note documents the firing-order discipline — advance the composition gate only after the fulfilment fact is true), so blocking it would refuse a supported feature; the audit DISCLOSES the race and the discipline instead. Rows with an unresolved guard design or an unresolvable payee vector are out of scope here (pending_allocator_guard_count and the S4 third-party-leg rule own those faces).",
+      "cases": [
+        {
+          "when": { "field": "alloc_overlap_payee_count", "op": "gt", "value": 0 },
+          "level": "medium",
+          "title": "Intersecting allocator rails '${first_alloc_overlap_payee}' — firing order decides the payee",
+          "description": "Conflicting pairs: ${alloc_overlap_payee_display}. Two rails fire on the same order state but pay different recipients — settlement order becomes a race: the first advancing forward drains the escrow to ITS payee while the other rail's claim stays live. Unrepairable after publish (guards and allocator configuration are immutable). NOTE: if one rail is a supply-chain composition rail, this is the documented shape — the discipline is FIRING ORDER (advance the fulfilment gate before the shop's own settlement; the emission notes carry it), and this advisory is your pre-publish reminder that the discipline is now load-bearing.",
+          "mitigation": "Either converge the payees (identical GuardIdentifier slots — payment_info binds slot N to one address, so slot equality is address equality — or the same Entity addresses), narrow one rail's accepted-node set so the shared state drives exactly one rail, partition the rails by rate (each row declares its share instead of competing for the whole), or — for the sanctioned supply-chain shape — adopt and document the firing-order discipline operationally. After fixing, re-verify with analyze_guard_semantics compare_with after creation.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
     {
       "rule_id": "REPO-WRITE-ONCE-01",
       "dimension": "composition",
@@ -840,6 +964,224 @@
           "stakeholders": ["customer", "merchant"]
         }
       ]
+    },
+    {
+      "rule_id": "TWIN-WINDOW-ZERO",
+      "dimension": "composition",
+      "trigger": "A FRACTIONAL `*_days` knob rides the PRESENTED plan (step params or resolved inputs). This is the publish-face semantic twin of the build face's PLAN-P0-18 blocker: the day knob lands in a guard-table U64 slot as a DAY COUNT, which BCS truncates (0.002 → 0), and a `<=` closing window fed by that slot computes anchor + 0 and welds shut the instant its anchor entry lands — Guards are immutable, so the rail is closed forever (the tbp taobao-presale mainnet run compiled a 0.002-day test window into exactly this shape). The compiler refuses the fractional input at generation; this twin re-fires the same predicate on the plan AS PRESENTED at the publish gate, so a hand-edited or drifted plan cannot carry the hazard past preflightPlan. campaign_duration_days is exempt — the compile converts it to an ABSOLUTE epoch-ms deadline in TS, so a fraction IS representable there (no U64 day slot involved).",
+      "cases": [
+        {
+          "when": { "field": "first_fractional_day_knob", "op": "present" },
+          "level": "critical",
+          "title": "Fractional day count on the presented plan — the window welds shut on-chain",
+          "description": "${first_fractional_day_knob}. The leg multiplies the slot by the 86400000 ms_per_day row ON-CHAIN, so the fraction the knob declares is unrepresentable: the closing window reads anchor + 0 and never reopens. ${fractional_day_knob_display}.",
+          "mitigation": "Answer whole days, or the PARALLEL `*_ms` knob (e.g. review_window_ms: 600000 = a 10-minute window) — the compiler then emits the ms-denominated slot pair (duration_ms beside a day-factor of 1). Rebuild the plan from the template instead of hand-editing: a hand-patched fractional day bypassed the generation-time input gate, and this publish-face twin is the gate that caught it.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "TWIN-WINDOW-ZERO-HOURS",
+      "dimension": "composition",
+      "trigger": "A FRACTIONAL `*_hours`/`*_minutes` leaf rides the PRESENTED plan's step params. This is the publish-face semantic twin of the build face's pdd F-09 hours blocker (mtw-mainnet 2026-11-04): an hours knob whose binding rows carry NO scale lands RAW in a U64 slot that speaks the param's own unit (lower_hours / upper_hours / free_cancel_hours — the travel fee ladder's cancellation-tier seams), and BCS truncates the fraction to 0, so the band collapses to `tier + 0` and two cancellation tiers melt into one — Guards are immutable, so the ladder is wrong forever. The compiler refuses the fractional answer at generation unless EVERY binding row for that param carries a scale (a duration_ms TS-side conversion, where a fraction IS representable); this twin re-fires the predicate on the plan's step params AS PRESENTED at the publish gate. plan.inputs is not an hours verdict site: a scaled fractional answer legally rides it.",
+      "cases": [
+        {
+          "when": { "field": "first_fractional_hour_knob", "op": "present" },
+          "level": "critical",
+          "title": "Fractional hours count on the presented plan — the band truncates to zero on-chain",
+          "description": "${first_fractional_hour_knob}. A fractional hour/minute is unrepresentable in a U64 unit slot: the band or window the slot bounds collapses to 0 at BCS encode (the mtw-mainnet run fed 0.5 hours to the travel fee ladder and the tier seam compiled to tier + 0). ${fractional_hour_knob_display}.",
+          "mitigation": "Answer a whole number, or resolve the guard via guard_resolutions with an inline ms-denominated table (duration_ms) where the fraction is representable. Rebuild the plan from the template instead of hand-editing: this publish-face twin exists to catch plans that bypassed the generation-time input gate.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "GUARD-EQUALITY-DRIFT",
+      "dimension": "composition",
+      "trigger": "A guard's description promises the delivered content MATCHES the committed hash/wip while its root carries NO logic_equal leg (ofnz8-mn-261105 F-49: the compiled guard enforced EXISTENCE of a hash-shaped row only, and content_hash=\"fake-hash-does-not-match-committed-wip\" cleared it on 4/4 orders — escrow released). Judged by the SAME shared predicate the template scanner runs (knowledge/guard-quality.ts equalityFaceCheck) over every guard create step — inline guard_resolutions included, since compile materializes them into create steps BEFORE this audit runs. The ≤16-char proximity window and the \"same writer\" phrase strip keep naming contracts and writer-authorization prose from false-firing.",
+      "cases": [
+        {
+          "when": { "field": "first_guard_equality_drift", "op": "present" },
+          "level": "critical",
+          "title": "Guard description promises hash/wip equality with no equality leg: ${first_guard_equality_drift}",
+          "description": "${guard_equality_drift_count} guard(s) claim content-matching while the root enforces existence only. Guards freeze at creation, so the drift is unrepairable after publish: any forged hash-shaped row passes, which is exactly the mainnet failure this rule encodes.",
+          "mitigation": "Mount the equality leg before publish: resolve the guard (guard_resolutions) to tpl_repository_row_equals_order_field (default source order.item.wip_hash) or add an inline logic_equal over the row's hash vs the order's committed wip — or rewrite the description to state the weaker existence check the tree actually enforces. Never keep a matching promise over an existence-only guard.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "GUARD-THRESHOLD-LITERAL",
+      "dimension": "fund_flow",
+      "trigger": "A guard table row whose name is a bare threshold identifier (min_/minimum_/threshold_/floor_/at_least_ prefix, no whitespace) carries value_type U64 with the literal value 1 (ofnz8 F-70: 1 MIST qualified for the rebate — any 1-unit order satisfies the \"threshold\", so the payout rate over qualifying volume is unbounded). Prose-annotated rows (query-range documentation) and submission rows are exempt — same predicate as the template scanner (knowledge/guard-quality.ts thresholdLiteralCheck).",
+      "cases": [
+        {
+          "when": { "field": "first_guard_threshold_literal", "op": "present" },
+          "level": "high",
+          "title": "Threshold row ships as the literal 1 raw unit: ${first_guard_threshold_literal}",
+          "description": "${guard_threshold_literal_count} threshold row(s) are bare 1-raw-unit literals. The floor filters nothing (1 smallest unit qualifies), the fixed reward over 1-unit orders makes the payout rate unbounded, and a bare literal is invisible to the operator's config plane — no knob exists to tune it.",
+          "mitigation": "Derive the threshold from a declared fee param (value_from / FEE_PARAM_BINDINGS row) with a sane default, or state the intended floor in raw units as a named param the merchant can tune. Resolve via guard_resolutions with an inline table before publish — guards freeze at creation.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "GUARD-SET-COLLAPSE",
+      "dimension": "composition",
+      "trigger": "A guard table repeats ONE String literal across >= 2 distinct non-submission row names (ofnz8 F-51/F-52: the terminal \"set\" was \"expired\" four times and \"reviewed\" twice) — either dead OR legs or placeholder rows that mislead every later editor into assuming a diversity that does not exist on chain. Non-`${…}` non-numeric strings only; same predicate as the template scanner (knowledge/guard-quality.ts setCollapseCheck).",
+      "cases": [
+        {
+          "when": { "field": "first_guard_set_collapse", "op": "present" },
+          "level": "medium",
+          "title": "Declared set collapsed to one literal: ${first_guard_set_collapse}",
+          "description": "${guard_set_collapse_count} guard(s) carry a repeated literal across distinct row names. If the design intended a SET of qualifying values, the extra members are dead OR legs; if it intended one value, the duplicated rows are placeholders — either way the table lies to the next editor, and guards freeze at publish.",
+          "mitigation": "Collapse to the single row that carries the real value, or differentiate the members — each row should either earn its name with a distinct literal or be deleted. Fix via guard_resolutions (inline table) before publish.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "GUARD-INPUT-TRUST",
+      "dimension": "fund_flow",
+      "trigger": "A guard's repository find_where/keys_where ids operand resolves to a caller-SUBMITTED table row ({identifier:N, b_submission:true}) — the candidate row set the query judges is self-attested (ofnz8 P0-4(b)): an attacker submits only their own row, the scan returns exactly that row, and every membership/equality leg built on it passes. Identifier resolution follows the kernel convention (composition/audit.ts acceptedProgressNodes). Same predicate as the template face (knowledge/guard-quality.ts submissionRowIdTrustCheck).",
+      "cases": [
+        {
+          "when": { "field": "first_guard_input_trust", "op": "present" },
+          "level": "high",
+          "title": "Candidate row set is caller-submitted: ${first_guard_input_trust}",
+          "description": "${guard_input_trust_count} guard(s) read their candidate rows from a submission row. Whoever executes the guard chooses what the scan sees, so the gate's authority collapses to self-attestation — the caller-reported candidate set is the very thing the guard was supposed to verify.",
+          "mitigation": "Anchor the candidate set at a FIXED point: an Order-anchored non-submission row (identifier 0 / id_from the host order) or context(Signer), so the caller cannot choose what the scan sees. If the ids list must be dynamic, pin it with a vec_contains_address order-pin (ddmc2 F-10) so padding the list satisfies nothing.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "GUARD-ABORT-SAFE-01",
+      "dimension": "fund_flow",
+      "trigger": "A guard queries a verb whose native handler ABORTS (W_FIELD_NOT_FOUND) when the addressed record does not exist, and the guard engine does not short-circuit — all leaves evaluate before the boolean merge (passport.rs TYPE_LOGIC_AND/OR), so no logic_and(presence leg, aborting verb) shape protects the guard. Verified 13 verbs against the native handlers: entityLinker votes 1802-1808, resource name/tags 1852-1855, entity_order role/time 2252/2255 (B-30, UNEXPRESSIBLE §6.3; N-11). Same predicate as the template face (knowledge/guard-quality.ts abortSafeVerbCheck).",
+      "cases": [
+        {
+          "when": { "field": "first_guard_abort_unsafe", "op": "present" },
+          "level": "critical",
+          "title": "Guard queries an abort-on-absent verb: ${first_guard_abort_unsafe}",
+          "description": "${guard_abort_unsafe_count} guard leg(s) read verbs that return W_FIELD_NOT_FOUND instead of a zero/false value when the target record is missing (reputation votes, resource name/tags, entity-order role/time). The engine evaluates every leaf before merging, so the first absent target aborts the entire guard evaluation and every order path the guard gates fails at runtime. Guards freeze at creation — the defect is unrepairable after publish.",
+          "mitigation": "Read the safe sibling verb instead: entityLinker.entity has (1801), resource.object has (1851), entity_order.entity has (2250) / count (2251) / is_owner (2253) / is_agent (2254) all return false/0 on absence. PT-12 (protocol train) will widen the aborting natives to typed zero values — until it lands on-chain, these verbs are unusable inside guards.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "GUARD-FIND-POLARITY",
+      "dimension": "fund_flow",
+      "trigger": "A guard anchors a history clock at find:\"first\" on a node lying on a renewal/charge loop of the plan's machine graph — the node re-enters per billed period, so period 2+ reads the FIRST visit's timestamp and the measured window is already closed (or already open) at birth (ofnz8 F-61). Loop tiers rebuilt with the shared findLoopCycles + classifyLoopCycle over the machine edges; remedy-loop nodes are exempt (one-shot acceptance deadlines). Severity follows the contract the description states: a per-period claim over the stale anchor is critical; a bare anchor is a low disclosure (most likely the intended once-per-life gate).",
+      "cases": [
+        {
+          "when": { "field": "guard_find_polarity_per_period", "op": "truthy" },
+          "level": "critical",
+          "title": "find:\"first\" anchor on a periodic node while the description claims per-period semantics: ${first_guard_find_polarity}",
+          "description": "${guard_find_polarity_count} periodic anchor(s) in the plan; this one promises per-period behavior the find:\"first\" polarity cannot deliver — from period 2 the window reads the FIRST visit's clock, so every later period's window is already expired (or already open) at birth. Guards freeze at publish; the polarity cannot be repaired on a live shop.",
+          "mitigation": "Anchor the leg with find:\"last\" (the schema's stated polarity for re-entrant anchors), or re-point the where at a node each period enters exactly once — or rewrite the description to state the once-per-life semantics the anchor actually enforces.",
+          "stakeholders": ["merchant", "customer"]
+        },
+        {
+          "when": { "field": "first_guard_find_polarity", "op": "present" },
+          "level": "low",
+          "title": "find:\"first\" anchors a periodic node — confirm the once-per-life intent: ${first_guard_find_polarity}",
+          "description": "The description does NOT claim per-period semantics, so this is most likely the intended once-per-life polarity (e.g. a one-time bounty claimable N days after the FIRST review). Disclosed, not blocked — confirm the intent before publish, because the anchor freezes with the guard.",
+          "mitigation": "No action needed if the once-per-life reading is intended; otherwise anchor with find:\"last\" before publish.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-REFUND-CONVERGENCE",
+      "dimension": "fund_flow",
+      "trigger": "A plan ships a refund-track allocator row (refund_row_count > 0) but the machine projection carries NO convergence close: no edge INTO a `closed_refunded` node whose bound guard queries order.principal_refunded (chain-query 1579 — the RefundStamp latch, order.move:395-430, set once by the chain when the refund principal is paid back in FULL and never forgeable). The compile kernel injects the terminal + shared `refund_latch_convergence` guard (emitRefundConvergence, K3 C3); hand-built plans must declare the equivalent shape (K3 C3, 2026-11-08).",
+      "cases": [
+        {
+          "when": { "all": [ { "field": "refund_row_count", "op": "gt", "value": 0 }, { "field": "refund_convergence_missing", "op": "truthy" } ] },
+          "level": "critical",
+          "title": "Refund track has no latch-gated close: no closed_refunded convergence edge",
+          "description": "The plan moves money on the refund track (${refund_row_count} refund row(s)) but the machine graph has no edge into closed_refunded gated by order.principal_refunded (1579). Without the latch-gated close, nothing in the topology PROVES the refund loop ended — a partial-refund or disputed order reads structurally identical to a closed one on every downstream face (buyer diligence, market scan, dispute evidence), and the refund state stays a private convention of this one template.",
+          "mitigation": "Compile through the kernel (emitRefundConvergence injects the terminal + the shared refund_latch_convergence guard: order.principal_refunded == true on the 254 task-binding slot, edges riding the merchant permission rail), or declare the equivalent node + 1579-gated edges by hand BEFORE publish — allocator rows and forwards freeze permanently at publish (IMMUT-002).",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-LATE-REMEDY",
+      "dimension": "fund_flow",
+      "trigger": "A plan ships a `{forward}_late` machine edge (late_remedy_edge_count > 0 — the K3 D3 after-hours twin of a closing-window edge, mounted by the kernel when fee_params.late_remedy_mode = 'keeper_reopen' or declared by hand) but NO guard bound to the edge carries the 1008 keeper membership leg (permission.entity.perm has, index-bound). The late rail is then ANONYMOUS: whoever can submit a permission can operate outside the declared window with no keeper attribution (K3 D3, 2026-11-08).",
+      "cases": [
+        {
+          "when": { "all": [ { "field": "late_remedy_edge_count", "op": "gt", "value": 0 }, { "field": "late_remedy_gate_missing", "op": "truthy" } ] },
+          "level": "critical",
+          "title": "Late-remedy edge has no keeper leg: anonymous after-hours rail (${first_late_remedy_gate_missing})",
+          "description": "The machine ships `{forward}_late` edge(s) (${late_remedy_gate_missing_display}) whose guards carry no 1008 keeper membership leg. The strict window edge keeps its weld, but its late twin is then driveable by ANY permission submitter, not just the keeper role — an undeclared after-hours bypass of a frozen business deadline. The kernel mounts the twin with tpl_late_remedy_keeper_forward (node pin + dynamic permission + 1008 keeper slot, edge permission_index 1002) and discloses it on the machine step's notes.",
+          "mitigation": "Compile through the kernel (late_remedy_mode = 'keeper_reopen' mounts attributed twins), or rebind the late edge to a guard carrying the 1008 keeper leg (tpl_late_remedy_keeper_forward shape) BEFORE publish — machine topology freezes permanently at publish (IMMUT-002). If no after-hours rail is intended, drop the _late edge entirely and let the strict window stay absolute.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "SETTLEMENT-TRIGGER-SCOPE",
+      "dimension": "fund_flow",
+      "trigger": "Disclosure face (K3 C4, 2026-11-08): the plan ships settlement-track allocator rows and the settlement_triggers_display fact names who can fire each rail. The buyer-only shape (the ONLY caller face is order.owner/order.agent — the buyer triggers the merchant's settlement) keeps the legacy role-reversal WARN as an advisory; service-binding and permission-role faces are legal and never warned.",
+      "cases": [
+        {
+          "when": { "field": "settlement_buyer_only_count", "op": "gt", "value": 0 },
+          "level": "medium",
+          "title": "Buyer-triggered settlement (role-reversal disclosure): ${settlement_buyer_only_count} rail(s) fire only on the buyer's identity",
+          "description": "${settlement_triggers_display}. Every settlement rail above carries ONLY the order-holder caller face (order.owner/order.agent == signer) — the BUYER's signature is what releases the merchant's money. This is the disclosed role reversal: legal by design (e.g. buyer-claimed completion), but the buyer can time or withhold the merchant's payout and the merchant cannot settle unilaterally. Rails whose face is a service binding or a permission role are NOT listed here — those are merchant-side by construction.",
+          "mitigation": "If unilateral merchant settlement is intended, widen the rail's caller face: a permission-index role leg (permission.owner/admin == signer, riding the merchant rail 1000/1001) or an order.service binding leg — the C4-legal identity set. Keep the buyer-only face only where buyer-controlled release is the contract.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-WITHDRAW-NO-CASE-BIND",
+      "dimension": "fund_flow",
+      "trigger": "A plan ships a machine edge with the WithdrawClaim forward whose bound guards read NO order.dispute.open leg (chain-query 1576, order.dispute.open — mirrors order::has_open_dispute). The compile kernel mounts the bind leg on every catalog withdraw edge (guard-fill andDisputeBindLeg, PT-26 2026-11-08); this twin judges hand-built plans and inline guard_resolutions overrides, which own their root outright.",
+      "cases": [
+        {
+          "when": { "field": "withdraw_no_case_bind_count", "op": "gt", "value": 0 },
+          "level": "medium",
+          "title": "WithdrawClaim edge with no case binding: ${withdraw_no_case_bind_count} withdraw edge(s) read no open-dispute leg",
+          "description": "${withdraw_no_case_bind_display}. A withdrawal whose guard carries only the identity leg (order-holder set, no dispute-state read) admits with NO case on file: the same buyer can farm file->withdraw cycles for free (each cycle re-anchors keeper clocks and perturbs the public state face), and a case on a DIFFERENT order neither helps nor blocks — the withdraw reads no arbitration object at all. The kernel mounts the case-binding leg (query 1576 must read TRUE on THIS order) automatically on catalog templates; a hand-built plan shipping without it keeps the ssng6 residuals live.",
+          "mitigation": "AND a tpl_order_has_open_dispute leg onto the withdraw edge's guard (the kernel does this for every catalog WithdrawClaim edge; the hand-built equivalent is the bare positive query order.dispute.open on the order's submission slot). Protocol gate (v139): 1576 is flag-gated (enable_order_dispute_state) — on an older binary the leg reads false and the withdraw edge goes dark (degrade polarity is INVERTED vs the settlement freeze leg, which degrades open); check upgrade_check (DEPLOY-K1).",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-DISPUTE-EXIT-REACHABILITY",
+      "dimension": "fund_flow",
+      "trigger": "Cross-EDGE state reachability (ss10 F-SS10-01, 2026-11-09): the plan ships BOTH a dispute-freeze money rail (a guard reading order.dispute.open on a NON-withdraw edge) AND a withdraw edge whose guards read order.dispute.open (case-bound) but carry NO order.claimed_by disposition precondition. Each shape is correct alone; the composition locks escrow: order::dispute() is push-only and claimed_by has no clearer, so a file->withdraw cycle leaves has_open_dispute TRUE forever and every freeze rail is unreachable from the withdrawn state.",
+      "cases": [
+        {
+          "when": { "field": "dispute_exit_dead_topology", "op": "gte", "value": 1 },
+          "level": "high",
+          "title": "Dispute-exit dead topology: ${dispute_exit_live_withdraw_count} withdraw edge(s) strand ${dispute_freeze_rail_count} dispute-frozen rail(s) with NO recovery path",
+          "description": "Freeze rail(s): ${dispute_freeze_rail_display}. Live withdraw edge(s): ${dispute_exit_live_withdraw_display}. Chain truth (order.move): dispute() only pushes (no removal verb), claimed_by is stamped ONLY by compensate()/conclude(), and has_open_dispute() = dispute non-empty && claimed_by none. A buyer who files a dispute and takes the withdraw edge leaves the case live forever; this machine exposes NO conclude/compensate forward, so NOTHING can ever turn has_open_dispute false — the frozen rails (refunds gated on NOT dispute.open) are unreachable and the escrow locks (ss10 mainnet: 0.20 WOW permanently locked exactly here).",
+          "mitigation": "Wire a disposition path: a conclude/compensate-class forward reachable from the withdrawn node (the arb case_conclude rail stamps claimed_by), or add a claimed_by disposition precondition leg to the withdraw edge so withdrawal is only possible AFTER the case was stamped. Root cure is protocol-train PT-26 Plan C (order::withdraw_dispute clearing verb) — register, do not hand-patch.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "R-DISPUTE-EXIT-INDIRECT-STAMP",
+      "dimension": "fund_flow",
+      "trigger": "Same coexistence as R-DISPUTE-EXIT-REACHABILITY, but the machine DOES expose a conclude/compensate-class forward — recovery exists only through a FULL re-arbitration cycle filed AFTER the withdraw (no dispute removal verb means the withdrawn case keeps has_open_dispute TRUE until some case stamps claimed_by).",
+      "cases": [
+        {
+          "when": { "field": "dispute_exit_indirect_stamp", "op": "gte", "value": 1 },
+          "level": "medium",
+          "title": "Dispute exit is indirect: ${dispute_exit_live_withdraw_count} withdraw edge(s) leave the case live; recovery only via a fresh arbitration cycle",
+          "description": "Freeze rail(s): ${dispute_freeze_rail_display}. Live withdraw edge(s): ${dispute_exit_live_withdraw_display}. After a file->withdraw cycle the withdrawn case stays open forever (push-only dispute vector, no clearing verb); the conclude/compensate forward on this machine can stamp claimed_by only when a NEW dispute is filed and driven to a stamped ruling. Disclose in the service terms: a withdrawn dispute freezes every dispute-gated refund until a fresh case reaches compensate/conclude — buyers perceive 'I withdrew, why is my refund blocked'. Root cure stays protocol-train PT-26 Plan C (order::withdraw_dispute).",
+          "mitigation": "Disclose the two-step recovery in build_note/quote terms, or add the claimed_by disposition precondition leg to the withdraw edge so withdrawal requires a stamped (resolved) case up front.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
     }
   ]
 }