@wowok/agent-mcp 3.4.3 → 3.4.4

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

@@ -0,0 +1,1187 @@
+{
+  "comment": "Plan-domain rules (L1 composition kernel). Facts are produced by composition/audit.ts planFacts() from a Plan AST. Each rule names a verified failure class (TRAILHAVEN wiki/test/10, booking-85981 + amz-7f3a2c91 audits, upwc-cat-261017 CAT-A1): zero allocator rows passing silently, an unsellable sales-less catalog, prose guard logic, dual-rail double-pay, path-dependent settlement windows, write-only enforcement, dropped guard/repository hosts, missing task-binding slot declarations and GuardIdentifier slot mismatches that strand escrow permanently.",
+  "facts": {
+    "composition_primitives_emitted": "Sorted comma-joined list of the composition primitives the plan actually emits (P1 repository rendezvous / P2 foreign-order slot / P3 sub-Service commitment or retained_submission / P4 more than one allocator row / P5 Formula sharing / P6 Reward pool) - chain-semantics/composition-truth.ts",
+    "composition_cross_order_guard_count": "Guard steps that read order.* on a slot other than host slot 0 (the P2 cross-order shape)",
+    "first_cross_order_guard": "First guard step id reading a foreign order slot",
+    "cross_order_slots_display": "Foreign order slot identifiers read by that guard",
+    "first_cross_order_guard_unpaired": "First cross-order guard with NO pairing key: neither a repository.data rendezvous leg nor a declared {identifier: 255, b_submission: true} once row (COMPOSE-PAIR-01)",
+    "cross_order_unpaired_count": "How many cross-order guards lack a pairing key",
+    "first_cross_order_guard_unpinned": "First cross-order guard that does not read order.service on the foreign slot against a constant Address row (COMPOSE-PROVIDER-PIN-01)",
+    "first_cross_order_guard_no_owner_cross": "First cross-order guard that does not read order.owner on BOTH the host slot and the foreign slot (COMPOSE-OWNER-CROSS-01). Not emitted on the merchant_procured axis, where the buyer never owns the sub order, so the equality cannot hold",
+    "cross_order_owner_tie_not_expressible": "A cross-order guard exists on the merchant_procured axis, where order.owner cannot tie the two orders (the merchant owns the sub order, the buyer owns the host order) - the expressible ties are the provider pin and a byte-keyed pairing slot",
+    "third_party_fulfilment_present": "The plan gates on a foreign order or declares a procuring fulfillment_axis, so a third party performs part of the service",
+    "third_party_payout_leg_present": "At least one payout path reachable by a third party exists: an Entity/Signer sharing leg or a Reward pool",
+    "third_party_leg_count": "Sharing legs whose recipient is Entity or Signer (the only legs not bound by payment_info.for_object)",
+    "reward_pool_present": "The plan creates a Reward object (P6, the only permissionless third-party payout channel)",
+    "third_party_fulfilment_without_payout": "A third party fulfils but no payout path was pre-set before publish (COMPOSE-LIABILITY-01, S4, RD-C4)",
+    "fulfillment_axis": "Fulfillment axis: self | internal_staff | merchant_procured | user_procured (replaces the conflated logistics_mode). Taken from the declared axis, else derived from the declared composition variant, which fixes its axis 1:1.",
+    "composition_variant": "Declared commercial variant V1 | V2 | V3 | V4",
+    "composition_variant_known": "The declared variant is one of V1-V4",
+    "composition_variant_missing_primitives": "Primitives the declared variant requires but the plan does not emit (COMPOSE-VARIANT-01)",
+    "composition_variant_missing_count": "How many required primitives are missing",
+    "composition_dual_refund_unblockable": "V3 declared: two escrow pools answer to the SAME buyer and the chain cannot block the second refund (COMPOSE-DUALREFUND-01, S2/S3, RD-C3)",
+    "composition_disclosure_count": "Number of disclosures the declared variant owes the buyer before purchase",
+    "first_pii_public_face": "First build-time public face (service/contact/proof/repository/demand description or location, sales copy, repository data constant) whose text matches a language-neutral PII shape (PRIV-PUBLICFACE-01, S5)",
+    "first_pii_public_face_step": "Step id writing that face",
+    "first_pii_kind": "PII shape matched: email | street_number | phone | national_id",
+    "first_raw_tracking_value_step": "Configure step writing a RAW carrier tracking number as a repository data value (PRIV-TRACKING-RAW-01)",
+    "first_raw_tracking_value": "The raw tracking value found",
+    "per_order_proof_binding_step": "Proof bound to the ORDER (or a required_info bind referencing a proof), which publicly associates the order with the contact record (PRIV-PROOF-PERORDER-01)",
+    "has_service": "Plan creates a service object",
+    "has_machine": "Plan creates a machine object",
+    "has_repository": "Plan creates a repository object",
+    "allocator_row_count": "Total allocator rows across service create param and order_allocators configure steps",
+    "refund_row_count": "Allocator rows on the refund track",
+    "terminal_count": "Fund-bearing machine terminal nodes (never a non-entry prev_node); v32 optional pure-side-action leaves are exempt — order completion never routes through them and they never gate money (upw F-06, 6939_upwork-261016)",
+    "terminal_nodes_display": "Comma-joined fund-bearing terminal node names",
+    "first_uncovered_terminal": "First fund-bearing terminal node no allocator guard accepts — either by pinning the terminal directly (alloc runs as a standalone call on the resting order) or via a node-free allocator guard riding the entry forward (a dual-host settlement key: its edge leg evaluates BEFORE the node move, so a progress.current pin on it would be a NODE-MATCH-01 deadlock and only the node-free shape fires on both hosts) (FUND-EXIT-01; optional leaves exempt)",
+    "first_uncovered_final_node": "First final/cancelled semantic-role node no allocator guard accepts — a money sink by business meaning even when graph topology gives it an outgoing edge (W5-12, ks7 F-02/A-02: return_rejected exited topologically but stranded the escrow) (FUND-EXIT-02)",
+    "first_cancelled_review_bridge": "First review/reward-class advance (forward or target node name matches review|reward) mounted ON a cancelled-role terminal — the refund-then-claim arbitrage bridge: the order took the full refund AND can still reach the bounty (W5-03, pdd F-03 / ddmc4 B-26 D8: withdraw + full refund + 5★ bounty in one session) (STATE-REFUNDED-REWARD-01)",
+    "first_roster_null_perm_edge": "First money-edge forward declaring a NON-EMPTY namedOperator roster with NO permissionIndex — permissionNeeded reads false, the Permission assert is skipped entirely and the roster stays pure decoration (it authorizes members, never denies non-members), so ANYONE can push the fund/terminal forward (W5-14, ddmc4 B-24 verified progress.move:266-310: an outsider fired ReturnReceived/CompensateBadItem) (EDGE-ROSTER-NULL-PERM-01)",
+    "coarse_perm_bucket_index": "First permission index shared by >= 2 money edges of DIFFERENT rail classes (settle / recover|award / refund|return / arb) — one bucket grants one entity every heterogeneous fund action at once (W5-14, ddmc4 B-25: 9 heterogeneous fund edges on bucket 1002 let the arbiter execute the merchant's rails) (PERM-COARSE-BUCKET-01)",
+    "coarse_perm_bucket_classes": "Comma-joined rail classes sharing that bucket",
+    "first_pinned_away_exit_node": "First non-terminal machine node whose EVERY outgoing edge is guard-pinned to OTHER nodes — exhaust every exit guard and no edge can fire while the order rests here, so a never-ruling arb case strands the escrow at a mid-flow node (W5-02, ddmc4 B-29: dismissed fails closed on a None indemnity and withdraw/reset leave both ruling roots silent; NODE-MATCH-01 reports each dead edge, this is the node-level rollup; a node with NO edge at all is a terminal — its coverage stays FUND-EXIT-01/02, entry stranding stays ENTRY-ABANDON-01) (FUND-EXIT-COMPLETENESS-01)",
+    "direction_blind_pay_edge_count": "Fund-track pay rows (refund / settle / recover) whose guard carries NO beneficiary-anchoring leg: no progress node pin, no machine-edge binding, no dispute freeze leg (query 1576), and no order identity leg (order.owner / order.agent has / order.service)",
+    "first_direction_blind_pay_edge": "First such direction-blind pay row — the payee is fixed by the row shape alone, indifferent to order state and identity, so the residual principal sweeps merchant-ward even when the buyer WON the award (ktt4 RT-01) and an outsider can drive the rail (W5-01 b: h1w9 F-01/F-04/F-09, ddmc4 B-26/B-27, pdd F-01/F-05, tbpr7 F-V3-01/16, ks7 F-21) (FUND-DIRECTION-BLIND-01)",
+    "first_refund_guard_missing_claimed_by": "First refund-track guard step id whose queries never read order.claimed_by (DUAL-RAIL-01, A-3)",
+    "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)",
+    "first_alloc_slot_missing": "First allocator {GuardIdentifier:N} leg whose bound guard table lacks slot N as a declared Address submission row (TASKBIND-02, N-K21: alloc abort with funds stranded)",
+    "pending_allocator_guard_count": "Unresolved guard designs bound to allocator rows (compile-time judgment surface; >0 downgrades FUND-EXIT-01 from critical to medium)",
+    "first_pending_fund_guard": "First unresolved guard design bound to an allocator row or machine edge (UNRESOLVED-GUARD-01) — publishing now ships that path UNGUARDED",
+    "pending_fund_guard_count": "Total unresolved guard designs bound to fund paths (allocator rows or machine edges)",
+    "pending_fund_guard_keys_display": "Comma-joined keys of ALL unresolved fund-path guard designs",
+    "first_pending_buy_guard": "First unresolved guard design bound to the service buy path (UNRESOLVED-GUARD-01 warning tier)",
+    "pending_buy_guard_count": "Total unresolved guard designs bound to the service buy path",
+    "pending_buy_guard_keys_display": "Comma-joined keys of ALL unresolved buy-path guard designs",
+    "has_return_rail": "The machine declares a return rail node (name matches /return/i) — the structural refund promise (PROMISE-ARB, L-01')",
+    "return_rail_node": "First return-rail node name",
+    "has_arbitration_binding": "The plan wires an arbitration venue into the Service (configure method 'arbitrations' with a non-empty object list, or the service create carries non-empty arbitrations)",
+    "prose_window_promise_count": "Window-context duration declarations found in the service/sales prose (PROMISE-TIME judgment gate — absent when the prose carries none)",
+    "first_prose_time_mismatch": "First prose window promise that no guard duration constant in the plan backs (PROMISE-TIME critical, upwk-mn-261017 F-55)",
+    "prose_time_mismatch_count": "Total prose window promises with no matching enforced guard duration",
+    "prose_time_mismatch_display": "Semicolon-joined list of ALL mismatched prose window promises",
+    "enforced_window_ms_display": "Comma-joined enforced window durations parsed from the plan's guard tables (plausible ms U64 constants)",
+    "first_unanchored_window_promise": "First restart/renew-style window promise, which needs an entry-anchored (1280 next_node) window guard to be true (PROMISE-TIME medium tier, F-55)",
+    "unanchored_window_promise_count": "Total restart/renew-style window promises in the prose",
+    "fund_topup_present": "The plan carries a compensation_fund_add step",
+    "fund_topup_amount": "Sum of parseable (integer smallest-unit) top-up balances; absent when unparseable",
+    "fund_ceiling_breach": "The top-up is below the award ceiling (MAX_INDEMNITY_MULTIPLE x highest SKU price) — judged ONLY when both sides parse (PLAN-K2)",
+    "fund_concurrent_orders_coverable": "How many simultaneous ceiling-sized claims the fund can pay: floor(fund / (3x highest SKU)). The buy gate only covers 3x ONE order — concurrent claims beyond this count abort (E_COMPENSATION_NOT_MATCH) until a manual top-up (PLAN-K2, b6-11)",
+    "fund_ceiling_basis": "Human-readable basis used for the ceiling judgment",
+    "fund_ceiling_unverifiable": "A fund top-up exists but the ceiling could not be judged here (price or amount unparseable) — the publish-patch KL-K2 rule re-checks at the 3x largest-order basis (PLAN-K2 fallback, stated explicitly)",
+    "reward_bounty_amount": "Largest per-claim bounty across the plan's reward guard_add mounts (Fixed amounts, smallest units) — absent when the plan mounts no bounty (T-02, bsn7-tn-261026)",
+    "reward_funding_amount": "Sum of parseable reward-pool funding (coin_add steps on reward targets, smallest units)",
+    "reward_max_claims": "How many full-bounty claims the current funding can pay: floor(funding / bounty)",
+    "lowest_sku_price": "Cheapest POSITIVE SKU price on the plan's sales catalog (same two legal sites the PLAN-K2 ceiling parser reads; a 0-price SKU is dead stock, F-BS-76)",
+    "reward_scale_breach": "The bounty exceeds half the cheapest SKU price — every claimed order pays out more than the sale earns, a bounty-farm target (T-02; judged ONLY when both sides parse)",
+    "reward_scale_ratio_display": "Human-readable bounty-to-cheapest-SKU ratio",
+    "reward_scale_unverifiable": "A bounty mount exists but the catalog has no parseable price — the scale judgment is deferred, stated explicitly (T-02 fallback, never silence)",
+    "first_arb_exit_node": "First settled/refund-class node with an outgoing edge whose guard queries the arbitration promise family (arb.indemnity / arb.order / arb.status / order.dispute) — a post-settlement arbitration re-route (FUND-ZERO-01 judgment gate)",
+    "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)",
+    "arb_key_plane_node": "First node whose exit edge carries the arbitration-promise guard (ARB-KEY-PLANE-01 judgment gate)",
+    "repo_policy_keys_display": "Comma-joined policy names declared by the plan's repository create steps (present only when at least one policy exists — the REPO-GATE-KEY-01 judgment gate)",
+    "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",
+    "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": [
+    {
+      "rule_id": "PLAN-SALES-01",
+      "dimension": "composition",
+      "trigger": "A service plan materializes zero sellable SKUs. The compile kernel emits the service_sales configure step ONLY when inputs.sales is non-empty, so a plan that reaches publish without one ships a Service frozen with sales: [] and EVERY order_new aborts on the empty catalog (upwc-cat-261017 CAT-A1: the published shop was unsellable until SKUs were hand-added, and hand-added steps bypass the plan audit entirely).",
+      "cases": [
+        {
+          "when": { "all": [ { "field": "has_service", "op": "truthy" }, { "field": "sales_step_present", "op": "falsy" } ] },
+          "level": "high",
+          "title": "Service plan carries no sellable SKU (sales stays empty)",
+          "description": "The plan creates a Service but no step adds a sales entry, so the published object freezes with sales: []. Every order_new aborts on the empty catalog — the shop cannot take a single order, and patching the catalog by hand after publish bypasses this audit (the hand-built replica class that silently drops steps).",
+          "mitigation": "Pass a non-empty inputs.sales catalog so the compile kernel emits the service_sales configure step, keeping the catalog inside the audited plan before publish.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "SKU-NAME-64",
+      "dimension": "composition",
+      "trigger": "A plan lists a sale whose name exceeds the on-chain 64-byte BUY limit. Listing accepts up to 256 bytes (common::LONG_NAME, service.move:158) but the buy path caps buyer-sent item names at 64 (common::NAME_ALLOW_EMPTY, service.move:311) and resolves items by EXACT name (service.move:520-563) — a 65..256-byte name is publishable yet EVERY order_new aborts E_NAME_LENGTH_EXCEEDED before anything runs. Advisory only (protocol-train ruling: the 256-byte listing stays legal; renaming is impossible — a new name is a NEW SKU), so this fires info and never blocks publish (F-RQ-01, rqd3-tn-261030: 3 of 4 merchants published shops whose SKUs could never be bought).",
+      "cases": [
+        {
+          "when": { "all": [ { "field": "dead_sku_count", "op": "gt", "value": 0 } ] },
+          "level": "info",
+          "title": "SKU '${first_dead_sku_name}' (${first_dead_sku_bytes} bytes) can be listed but never bought",
+          "description": "${dead_sku_count} sale name(s) exceed the 64-byte buy limit while the listing path accepted them (first: '${first_dead_sku_name}' at ${first_dead_sku_bytes} bytes). The buy path re-quotes every basket line's name and aborts E_NAME_LENGTH_EXCEEDED, so this SKU is PERMANENTLY unbuyable — buyers see a catalog they can never order from.",
+          "mitigation": "Add a purchasable twin SKU whose name is within 64 bytes (UTF-8) BEFORE publish; renaming the dead SKU is not possible after listing (exact-name matching makes a new name a new SKU). Non-blocking advisory: the listing itself is protocol-legal.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "PLAN-ALLOC-01",
+      "dimension": "fund_flow",
+      "trigger": "Service plan materializes zero allocator rows — the TRAILHAVEN failure: migration_apply emitted plan_allocation: [] with no critical, and the shop could neither settle nor refund.",
+      "cases": [
+        {
+          "when": { "all": [ { "field": "has_service", "op": "truthy" }, { "field": "allocator_row_count", "op": "eq", "value": 0 } ] },
+          "level": "critical",
+          "title": "Service plan has no allocator rows",
+          "description": "The plan creates a service but materializes zero allocator rows. On chain, publish aborts with E_NO_ALLOCATOR; worse, a plan that reaches materialization without rows means the shop cannot settle or refund anything.",
+          "mitigation": "Add at least one settlement-track allocator row (guard + recipient + mode). If the business has a refund path, add a refund-track row too.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "FUND-EXIT-01",
+      "dimension": "fund_flow",
+      "trigger": "A business-terminal machine node is accepted by no allocator guard — funds that reach it are stranded forever (Machine/Service freeze at publish, A-2). Two tiers: with zero pending guard designs the money has NO declared exit (critical); with pending designs the exit is DECLARED but unverifiable until the judgment layer resolves them (medium).",
+      "cases": [
+        {
+          "when": { "all": [ { "field": "terminal_count", "op": "gt", "value": 0 }, { "field": "first_uncovered_terminal", "op": "present" }, { "field": "pending_allocator_guard_count", "op": "eq", "value": 0 } ] },
+          "level": "critical",
+          "title": "Terminal node '${first_uncovered_terminal}' has no fund exit",
+          "description": "Terminal nodes (${terminal_nodes_display}) are where orders rest forever. '${first_uncovered_terminal}' is accepted by no allocator guard and no pending guard design exists that could cover it, so escrowed funds reaching it can never leave. This must be proven impossible BEFORE publish — the graph and allocators freeze permanently.",
+          "mitigation": "Add an allocator whose guard accepts the terminal node (progress.current == '${first_uncovered_terminal}'), or add an outgoing edge so the node is no longer terminal.",
+          "stakeholders": ["merchant", "customer"]
+        },
+        {
+          "when": { "all": [ { "field": "terminal_count", "op": "gt", "value": 0 }, { "field": "first_uncovered_terminal", "op": "present" }, { "field": "pending_allocator_guard_count", "op": "gt", "value": 0 } ] },
+          "level": "medium",
+          "title": "Terminal node '${first_uncovered_terminal}' fund exit is declared but unverified",
+          "description": "Terminal nodes (${terminal_nodes_display}) are where orders rest forever. '${first_uncovered_terminal}' is accepted by no RESOLVED allocator guard; pending guard designs exist that may cover it, but until they are resolved into structured guards the coverage cannot be verified.",
+          "mitigation": "Resolve the pending guard designs (judgment layer / guardResolutions) so the allocator guard verifiably accepts '${first_uncovered_terminal}' before publish.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "FUND-EXIT-02",
+      "dimension": "fund_flow",
+      "cases": [
+        {
+          "when": { "all": [ { "field": "first_uncovered_final_node", "op": "present" } ] },
+          "level": "critical",
+          "title": "Final/cancelled node '${first_uncovered_final_node}' has no allocator fund exit",
+          "description": "'${first_uncovered_final_node}' carries a final/cancelled semantic role — by business meaning the order's money journey STOPS here, even if a graph edge leaves the node. No allocator guard accepts it, so escrow reaching this state strands permanently (W5-12, ks7 F-02: return_rejected had a topological exit yet neither settle nor recover could move the funds). Graph-sink checks miss this shape; the semantic role does not.",
+          "mitigation": "Add an allocator row whose guard accepts '${first_uncovered_final_node}' (progress.current pin or node-free entry-forward shape), or give the node a genuine settlement/refund exit. For rejected terminals, keep a dispute or settle_after_grace rail.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "STATE-REFUNDED-REWARD-01",
+      "dimension": "fund_flow",
+      "cases": [
+        {
+          "when": { "all": [ { "field": "first_cancelled_review_bridge", "op": "present" } ] },
+          "level": "critical",
+          "title": "Review/reward advance mounted on cancelled terminal '${first_cancelled_review_bridge}' — refund-then-claim arbitrage",
+          "description": "A review/reward-class advance departs a cancelled-role terminal (${first_cancelled_review_bridge}): the order can take the FULL refund and still walk to the bounty — 'refund + 5★ claim' double collection (W5-03, pdd F-03 T3/T7: full refund then review bounty; ddmc4 B-26 D8: withdraw + full refund + top-rating bounty in one session; tbpr7 F-V3-03: rebate window inside the return window). The claim guard's node set carries no cancelled node, so this bridge is the ONLY route a refunded order has back to the reward — and the machine shell happily mounts it because nothing forbade it until now.",
+          "mitigation": "Remove the review/reward-class edge from the cancelled terminal. Mutual exclusion is structural: the bounty's claim set carries final-role nodes ONLY and the claim window opens after the after-sales window closes (tbs7 F-04) — a cancelled order must stay outside that set. (A chain-level 'was ever refunded' boolean does not exist — protocol train.)",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "FUND-EXIT-COMPLETENESS-01",
+      "dimension": "fund_flow",
+      "cases": [
+        {
+          "when": { "all": [ { "field": "first_pinned_away_exit_node", "op": "present" } ] },
+          "level": "critical",
+          "title": "Every exit of '${first_pinned_away_exit_node}' is guard-pinned to other nodes — the order strands here",
+          "description": "While the order rests at '${first_pinned_away_exit_node}', none of its outgoing edges can fire: every edge guard pins progress.current to a DIFFERENT node (NODE-MATCH-01 already reports each such edge; this is the node-level rollup — exhaust every exit guard, find no live exit). The order and its escrow are unreachable-by-construction from here on (W5-02, ddmc4 B-29 D6: the never-ruling arb case — tpl_forward_arb_ruling_won needs a positive award and dismissed fails closed on a None indemnity, so withdraw/reset leave BOTH ruling roots silent and an arb waypoint gated only by rulings is this same deadlock expressed through guard pins; ETSY-T1 catalog deadEndLock is the catalog-level twin). Exit coverage is evaluated ONLY on fund-exit grounds (R2-01 lesson): node-level rollup, no whole-graph topology walk. A node with NO outgoing edge at all is a terminal — its coverage is FUND-EXIT-01/02's face, not this gate.",
+          "mitigation": "Re-pin the guards so at least one edge accepts the node the order actually rests on, or add an unpinned escape edge. For an arb waypoint the canonical shape is the buyer's void escape: { prev: <waypoint>, forward: 'WithdrawClaim', operator: 'order_payer', guard_key: 'withdraw_claim_<leg>' } with a pattern.identity_check_order_holder guard — no ruling means arb.claimed_by is none, the order stays put, and the FULL escrow returns through the untouched node-gated refund track (decision 11 two-rail independence). A ForceSettleExpired clock edge (buyer-directed) is the acceptable fallback; never gate the only live exit on a ruling that can fail closed. A live exit means: an edge whose guards are empty, or whose guard's acceptedNodes includes this node.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "FUND-DIRECTION-BLIND-01",
+      "dimension": "fund_flow",
+      "cases": [
+        {
+          "when": { "all": [ { "field": "first_direction_blind_pay_edge", "op": "present" } ] },
+          "level": "critical",
+          "title": "Pay row '${first_direction_blind_pay_edge}' — the beneficiary is a constant, not a state function",
+          "description": "A fund-track pay row is bound to a guard that anchors NOTHING: no progress node pin, no machine-edge binding, no dispute freeze leg (query 1576 order.dispute.open), and no order identity leg (order.owner / order.agent has / order.service). The payee is fixed by the row shape alone, so the pay direction is blind to who won and where the order rests — the claimed_by direction-blind family (W5-01, five of five reports): the residual principal sweeps merchant-ward even when the buyer WON the award (ktt4 RT-01: 300M award from the compensation pool, then the 600M escrow principal swept to the merchant), and an outsider can drive the rail (h1w9: an unrelated address fired the merchant's recover three times and closed the case; ddmc4 D10: the buyer executed the merchant's sweep). Machine/Service/Allocation freeze at publish — a wrong pay direction is unfixable after publish.",
+          "mitigation": "Anchor the rail's guard to a beneficiary-tying leg: the terminal-node gate (progress.current in the rail's node set — decision 11 node-gated, NEVER order.claimed_by) plus the order.service binding (1563 == this service) and, on the identity face, order.owner (1562) / order.agent has (1567). The canonical recover rail is guard-catalog tpl_allocator_node_gate_recover: terminal-node-gated + order.service + dispute freeze (logic_not[1576]). If merchant-exit is the intended disposition, state it (the canonical 'merchant-side sweep' row note) so the scan records the conscious choice; a buyer-win principal return needs a separate buyer-ward row (recipient slot 0 — the Order address; owner.receive credits the buyer).",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "FUND-ZERO-01",
+      "dimension": "fund_flow",
+      "trigger": "The machine routes a post-settlement arbitration re-route (an arbitration-promise guard — arb.indemnity / arb.order / arb.status / order.dispute — on an edge leaving a settled/refund-class node) while the compensation pool is never funded. service::compensation_claim pays the ruling from the service compensation fund and an underfunded pool aborts the payout with code 27 (E_COMPENSATION_NOT_MATCH, claim left unconsumed); the escrow behind a settled/refunded node is structurally drained, so with a zero or absent fund the promised exit is dead by construction (gf26-tn-261026 GF2-02: a 0-fund shop published and the buyer's only remedy had no money behind it).",
+      "cases": [
+        {
+          "when": { "all": [ { "field": "fund_arb_route_unfunded", "op": "truthy" }, { "field": "fund_topup_present", "op": "falsy" } ] },
+          "level": "critical",
+          "title": "Post-settlement arbitration re-route from '${first_arb_exit_node}' with NO compensation fund",
+          "description": "The plan gates an exit edge leaving '${first_arb_exit_node}' on an arbitration ruling. That ruling pays through service::compensation_claim, which draws ONLY from service.compensation_fund — this plan never creates one (no compensation_fund_add step). The escrow is already drained at that node, so the buyer's remedy has zero money behind it: the payout aborts with code 27 even when the ruling is valid.",
+          "mitigation": "Add a configure step with method 'compensation_fund_add' and a balance >= the largest single-order exposure (the award ceiling is 3x the order amount, arb.move MAX_INDEMNITY_MULTIPLE), or rebuild without the post-settlement arbitration edge so the remedy does not depend on the fund.",
+          "stakeholders": ["merchant", "customer"]
+        },
+        {
+          "when": { "all": [ { "field": "fund_arb_route_unfunded", "op": "truthy" }, { "field": "fund_topup_present", "op": "truthy" }, { "field": "fund_topup_amount", "op": "eq", "value": 0 } ] },
+          "level": "critical",
+          "title": "Post-settlement arbitration re-route from '${first_arb_exit_node}' with a ZERO compensation fund",
+          "description": "The plan gates an exit edge leaving '${first_arb_exit_node}' on an arbitration ruling, and its compensation_fund_add step deposits 0 — the fund exists but pays nothing. compensation_claim aborts with code 27 (E_COMPENSATION_NOT_MATCH) on any payout attempt, so the promised exit is still dead by construction.",
+          "mitigation": "Raise the compensation_fund_add balance to a real amount (>= the largest single-order exposure; the chain award ceiling is 3x the order amount), or remove the arbitration-gated exit edge.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "ENTRY-ABANDON-01",
+      "dimension": "fund_flow",
+      "trigger": "The order-landing node — the target of the machine entry edge (prev_node \"\") — exits only through CLOSING time-window guards (logic_as_u256_lesser_or_equal[Clock, anchor], no opening leg, no unguarded alternative): once a window closes every forward aborts, nothing can advance the order, and the escrow taken at entry is locked by construction (gf26-tn-261026 GF2-30: a 7.65 WOW pledge entered by a second transaction with no abandon-refund edge; machines and guard tables freeze at publish, so the missing recovery edge cannot be added later). Dead-end entries (zero exits) belong to the dead-end scanner, not this rule.",
+      "cases": [
+        {
+          "when": { "field": "entry_no_open_exit", "op": "truthy" },
+          "level": "high",
+          "title": "Entry node '${entry_strand_node}' has no exit that opens after its window",
+          "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"]
+        }
+      ]
+    },
+    {
+      "rule_id": "POST-ARB-SETTLE-01",
+      "dimension": "fund_flow",
+      "trigger": "A machine guard reads the arbitration ruling family (arb.indemnity / arb.order / arb.status / order.dispute) while no allocator row releases money on that ruling — none reads the family, none rides the ruling edge node-free, and the ruling edge's destination node is covered by no allocator in the FUND-EXIT-01 dual-shape semantics (pinned by an allocator guard, or node-free-covered by an unconstrained allocator guard mounted on one of its inbound edges — the canonical shape where the ruling re-routes the order into a node the plain refund allocator drains). Judged only on the $ref plane: plans whose allocator rows declare guards by key (guard_key — the template/migration emission) carry a rail plane invisible here and are left to the materialization freeze gate. arb.move rulings only write case state; the payout must exist as a plan rail, so with none the verdict changes state and the escrow never moves (gf26-tn-261026 GF2-31: a ruling that writes status but never releases the money).",
+      "cases": [
+        {
+          "when": { "field": "arb_promise_without_settle_rail", "op": "truthy" },
+          "level": "critical",
+          "title": "Arbitration promise at '${arb_promise_node}' with no ruling-gated settlement leg",
+          "description": "A guard on the forward out of '${arb_promise_node}' reads the arbitration ruling family, promising a ruling-driven outcome — but no allocator row releases money on that ruling: none reads the family, none rides the ruling edge, and the ruling edge's destination node has no allocator coverage (no pin, no node-free refund mount). When the verdict lands the machine changes state and the escrow stays put; the ruling moves nothing. Allocators freeze at publish, so the missing settlement leg cannot be added afterwards.",
+          "mitigation": "Add an allocator row that releases money on the ruling: either a guard reading the arbitration family (arb.order == the order, arb.indemnity some == true) with a payout sharing leg, or route the ruling edge into a node already drained by the refund/settlement rail (an allocator guard pins it, or a node-free allocator guard rides one of its inbound edges). Do not keep a state-only promise.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "ARB-KEY-PLANE-01",
+      "dimension": "fund_flow",
+      "trigger": "The machine carries arbitration-promise guards (arb.indemnity / arb.order / arb.status / order.dispute) while the allocator rail plane carries guard_key declarations (the template/migration emission shape) — rails the $ref plane cannot verify, so a settle leg hiding in a keyed row is invisible here. The POST-ARB-SETTLE-01 verdict stays silent on this shape by ruling (2026-10-26); this rule is the publish-door red line instead: the materialization freeze gate refuses the publish until the keys resolve into structured guard steps whose settle-rail coverage is plan-verifiable.",
+      "cases": [
+        {
+          "when": { "field": "arb_key_plane_opaque", "op": "truthy" },
+          "level": "high",
+          "title": "Arbitration promise at '${arb_key_plane_node}' rides an opaque guard_key rail plane",
+          "description": "A guard on the forward out of '${arb_key_plane_node}' reads the arbitration ruling family, promising a ruling-driven outcome — but this plan's allocator rails are (at least partly) declared by key (guard_key), so the $ref plane cannot verify that any rail releases money on the ruling: a settle leg hiding in a keyed row is invisible to the audit. The state-only verdict risk of POST-ARB-SETTLE-01 cannot be ruled out here, and a failed settle rail would strand the escrow with the verdict unable to move money — with no way to add the settlement leg after publish. This is a publish-door red line — the freeze gate refuses this shape.",
+          "mitigation": "Resolve each guard_key rail into structured guard steps (guardResolutions with kind 'template' or 'inline') before publish, so the settle-rail coverage becomes plan-visible and POST-ARB-SETTLE-01 can judge it; or re-route the ruling edge into a node drained by a $ref-visible allocator row.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "UNRESOLVED-GUARD-01",
+      "dimension": "composition",
+      "trigger": "A guard design requirement (pattern.* spec) is bound to a fund path or buy path but was never resolved into a structured guard — publishing now ships that path UNGUARDED.",
+      "cases": [
+        {
+          "when": { "field": "first_pending_fund_guard", "op": "present" },
+          "level": "critical",
+          "title": "${pending_fund_guard_count} unresolved guard design(s) bound to fund paths, of ${pending_guard_total} pending in total (first: '${first_pending_fund_guard}')",
+          "description": "All unresolved fund-path guard keys: ${pending_fund_guard_keys_display}. Every allocator row or machine edge referencing one of these guard_keys will carry NO guard at publish: the settlement/refund/forward it was designed to gate executes unconditionally. This is a publish-freeze blocker — the freeze gate refuses to go live with fund-path guards pending.",
+          "mitigation": "Resolve EACH listed guard design into a structured guard (guardResolutions with kind 'template' or 'inline'), or remove the binding. Machine-host guards must declare the order-identifier slot {identifier: 254, b_submission: true, value_type: 'Address'} in their table (TASKBIND-01).",
+          "stakeholders": ["merchant", "customer"]
+        },
+        {
+          "when": { "field": "first_pending_buy_guard", "op": "present" },
+          "level": "medium",
+          "title": "${pending_buy_guard_count} unresolved buy-guard design(s), of ${pending_guard_total} pending in total (first: '${first_pending_buy_guard}')",
+          "description": "All unresolved buy-path guard keys: ${pending_buy_guard_keys_display}. The service buy path was designed to screen purchasers, but the guard was never resolved; the service publishes without a buy_guard, so anyone can order.",
+          "mitigation": "Resolve EACH listed buy-guard design into a structured guard, or accept an unscreened buy path deliberately.",
+          "stakeholders": ["merchant"]
+        }
+      ]
+    },
+    {
+      "rule_id": "PROMISE-ARB",
+      "dimension": "fund_flow",
+      "trigger": "The machine declares a return rail — that IS the refund promise — but the plan binds no Arbitration into the Service. After settlement the in-escrow refund track is dead topology, so the only on-chain remedy for a post-settlement return is an independent Arbitration ruling paid from the compensation fund (etsy-ln L-01: a live shop promised returns with no venue bound).",
+      "cases": [
+        {
+          "when": { "all": [ { "field": "has_return_rail", "op": "truthy" }, { "field": "has_arbitration_binding", "op": "falsy" } ] },
+          "level": "critical",
+          "title": "Return-promising shop wires no Arbitration venue",
+          "description": "The machine's return rail ('${return_rail_node}') is a promise the chain cannot keep alone: once the settlement allocator drains the escrow, a post-settlement return can only be paid by an independent Arbitration ruling against the compensation fund. This plan binds no venue, so the promise is DECLARED but UNENFORCEABLE — the declared-but-not-enforced class. Blocking: the machine and guard freeze at publish; do not hand-build the wiring outside the plan (hand-built replicas silently drop the arbitration/fund steps).",
+          "mitigation": "Keep the arbitration create + service arbitration-binding steps in the plan (standard emission for arbitration_mode third_party). A shop that deliberately settles every dispute off-chain must remove the return rail instead of the venue — an unbacked promise is the one configuration the protocol cannot repair post-publish.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "PROMISE-TIME",
+      "dimension": "time_anchor",
+      "trigger": "The listing prose (service description / sales item text) promises a review/acceptance/cancel/refund/return/claim WINDOW that no guard-table duration in the plan enforces (upwk-mn-261017 F-55: the WIP listing promised window durations no guard carried). Both sides freeze at publish — guards are immutable and the prose ships as-is — so a mismatched promise is the declared-but-not-enforced class and is unrepairable post-publish. Shipping/delivery SLAs are deliberately OUT of scope: they are off-chain fulfillment promises no time guard is expected to enforce.",
+      "cases": [
+        {
+          "when": { "field": "first_prose_time_mismatch", "op": "present" },
+          "level": "critical",
+          "title": "Listing promises '${first_prose_time_mismatch}' but no guard enforces it",
+          "description": "Window promises found in the listing prose: ${prose_window_promise_count}; mismatched: ${prose_time_mismatch_display}. Windows the plan's guards actually enforce: ${enforced_window_ms_display}. The unenforced promise is a buyer-side remedy that dies on contact with the chain: the buyer relies on it, no guard carries it, and both the guard tables and the machine freeze at publish. Blocking.",
+          "mitigation": "Align the two sides BEFORE publish: reword the listing to match an enforced window, or add/retime a window guard (pattern.deadline_window for act-until windows, pattern.time_lock_progress for act-after windows) so a guard constant carries exactly the promised duration (fee-param-derived, e.g. review_window_days / escrow_release_days).",
+          "stakeholders": ["merchant", "customer"]
+        },
+        {
+          "when": { "field": "first_unanchored_window_promise", "op": "present" },
+          "level": "medium",
+          "title": "Window-restart promise ('${first_unanchored_window_promise}') needs an entry-anchored guard",
+          "description": "${unanchored_window_promise_count} restart/renew-style window promise(s) in the prose. A window can only restart when its guard anchors on the progress.history.time (id 1280) ENTRY timestamp of the re-open event (next_node form) — a fresh entry appends and the window re-measures. A one-shot anchor (order.time, or the current_time that is rewritten at every migration) never restarts, so the promise would be false the first time the triggering event repeats. Disclosure: confirm the anchor form before publish.",
+          "mitigation": "Anchor the window guard on progress.history.time (id 1280, next_node='<the restarting event>', find=last) so each re-entry resets the window, or reword the prose. See the time_anchors table of the archetype in use for the canonical anchor wording.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "PLAN-K2",
+      "dimension": "fund_flow",
+      "trigger": "Compensation-fund sizing guidance (KL-K2 family, re-scoped by b6-11, demoted to warning by sign-off 5 — dm-mtw-261027): an award is hard-capped at 3x the order amount at ruling time, so a fund below a planned case's ceiling turns a WON award into an unpayable one (the claim aborts and is NOT consumed). Per-order coverage is WARNED at buy time (each order is checked against 3x ITS OWN amount; the order still proceeds); the plan layer advises sizing on the typical single order instead of the priciest SKU — no cross-SKU subsidy.",
+      "cases": [
+        {
+          "when": { "field": "fund_ceiling_breach", "op": "truthy" },
+          "level": "medium",
+          "title": "Compensation fund tops up below the award ceiling (${fund_ceiling_basis})",
+          "description": "The plan tops the fund up to ${fund_topup_amount} (smallest units), but a ruling at the ceiling would abort the buyer's claim (E_COMPENSATION_NOT_MATCH) and the abort does NOT consume the claim — the buyer holds an unpayable win until a manual top-up, and the shop holds the reputational damage. Disclosure, not a blocker: under-covered ORDERS proceed with a buy-time warning (the per-order gate was demoted to a warning by sign-off 5 — dm-mtw-261027), so a buyer CAN enter a knowingly under-covered order — quote-time disclosure (max_coverable_order) is the buyer's protection. Concurrency headroom: this pool can pay ${fund_concurrent_orders_coverable} simultaneous ceiling-sized claim(s) — concurrent claims beyond that abort until a manual top-up.",
+          "mitigation": "Raise the compensation_fund input toward the ceiling (${fund_ceiling_basis}). Sizing is per-order now: 3x the typical single order keeps any single ruling payable; above that only buys tolerance for CONCURRENT claims against the one per-Service pool.",
+          "stakeholders": ["merchant", "customer"]
+        },
+        {
+          "when": { "field": "fund_ceiling_unverifiable", "op": "truthy" },
+          "level": "medium",
+          "title": "Compensation-fund adequacy cannot be judged from the plan",
+          "description": "The plan carries a fund top-up, but the catalog price or the top-up amount is not machine-parseable here (display forms need token decimals the plan layer does not have), so the plan-level judgment is DEFERRED, not skipped: the publish audit re-states the coverage as a disclosure warning, and the buy-time per-order gate enforces 3x each actual order.",
+          "mitigation": "Provide numeric smallest-unit sales prices and a numeric fund amount so the plan layer can advise on the ceiling before materialization; the buy-time gate judges every real order regardless.",
+          "stakeholders": ["merchant"]
+        }
+      ]
+    },
+    {
+      "rule_id": "PLAN-REWARD-SCALE-01",
+      "dimension": "economics",
+      "trigger": "Review-bounty scale (T-02, bsn7-tn-261026): a per-claim bounty larger than the margin of the order that earns it makes the reputation rail a bounty-farm target — buyers (or sybil accounts) manufacture cheap orders, claim the bounty, and drain the pool; the shop pays out more per claim than the sale earns. The former template default (1000000000) was 50x a 0.02-WOW SKU and passed every audit silently. Compile now DERIVES the bounty (2% of the cheapest positive SKU, floored at 1 smallest unit); this rule judges explicit overrides and custom plans. Disclosure, not a blocker: a deliberate loss-leader bounty is a legal promotion.",
+      "cases": [
+        {
+          "when": { "field": "reward_scale_breach", "op": "truthy" },
+          "level": "medium",
+          "title": "Review bounty is ${reward_scale_ratio_display} — each claimed order pays out more than the sale earns",
+          "description": "The plan mounts a per-claim bounty of ${reward_bounty_amount} (smallest units) against a cheapest SKU of ${lowest_sku_price}: every claim consumes more pool than the order brought in, and the funded pool pays ~${reward_max_claims} such claim(s) before running dry. That is the exact bounty-farm shape (T-02): cheap orders in, bounty out, pool drained.",
+          "mitigation": "Lower the reward_claim_amount input, or raise the cheapest SKU price — the compile default (2% of the cheapest positive SKU) is the sanctioned starting point; keep explicit overrides under half the cheapest SKU price unless the over-size is a deliberate, disclosed promotion.",
+          "stakeholders": ["merchant"]
+        },
+        {
+          "when": { "field": "reward_scale_unverifiable", "op": "truthy" },
+          "level": "medium",
+          "title": "Review-bounty scale cannot be judged from the plan",
+          "description": "The plan mounts a per-claim bounty of ${reward_bounty_amount}, but the sales catalog carries no parseable price here (display forms need token decimals the plan layer does not have), so the bounty-to-price ratio is DEFERRED, not skipped — stated explicitly rather than passed silently (the audit-silent gap T-02 closes).",
+          "mitigation": "Provide numeric smallest-unit sales prices so the plan layer can judge the ratio; the quote face discloses the live bounty-to-cheapest-SKU ratio at basket time regardless.",
+          "stakeholders": ["merchant"]
+        }
+      ]
+    },
+    {
+      "rule_id": "TIME-ANCHOR-01",
+      "dimension": "time_anchor",
+      "trigger": "A window guard anchors on a path-dependent time query (progress.current_time refreshes on every node entry) while the gated node is reachable by more than one path — detour nodes shift the settlement base (E-10: a buyer leaving a review postponed merchant settlement by the review window).",
+      "cases": [
+        {
+          "when": { "all": [ { "field": "first_path_dependent_anchor", "op": "present" }, { "field": "path_sensitive", "op": "truthy" } ] },
+          "level": "high",
+          "title": "Window guard '${first_path_dependent_anchor}' anchors on a path-dependent time",
+          "description": "progress.current_time is the time of ENTERING the current node, not of any business event. The gated node has multiple inbound paths, so an optional detour (e.g. a review node) silently extends the window. This is an exploitable merchant-side funds-lockup.",
+          "mitigation": "Anchor the window on order.time (path-independent), or restructure the machine so the anchored node has exactly one inbound path.",
+          "stakeholders": ["merchant", "customer"]
+        },
+        {
+          "when": { "field": "first_path_dependent_anchor", "op": "present" },
+          "level": "medium",
+          "title": "Window guard '${first_path_dependent_anchor}' uses a path-dependent time anchor",
+          "description": "The anchor is currently unambiguous (single-path), but any later template edit adding a bypass node silently shifts the window base.",
+          "mitigation": "Prefer order.time for settlement/refund windows.",
+          "stakeholders": ["merchant"]
+        }
+      ]
+    },
+    {
+      "rule_id": "WRITE-ONLY-01",
+      "dimension": "field_capability",
+      "trigger": "Plan sets a write-only field (only the native Guard engine ever reads it) with no guard query covering it — the enforcement the merchant believes in does not exist (A-1: customer_required was collected but never enforced on the buy path).",
+      "cases": [
+        {
+          "when": { "field": "first_write_only_unenforced_field", "op": "present" },
+          "level": "critical",
+          "title": "Field '${first_write_only_unenforced_field}' is set but never enforced",
+          "description": "Write-only fields are read ONLY by guard queries. Setting '${first_write_only_unenforced_field}' without a covering guard query creates the illusion of enforcement: the buy path will not check it.",
+          "mitigation": "Add a guard whose table queries the field (see chain-semantics WRITE_ONLY_QUERY_PREFIXES), bound to the enforcing forward or buy path — or remove the field.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "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",
+      "trigger": "A guard bound on a machine forward declares no {identifier: 254, b_submission: true} row — progress::assert_task_binding aborts code 11 on every guarded forward of an order-driven Progress, and Guard tables are frozen at creation (N-K20, booking-85981 + amz-7f3a2c91).",
+      "cases": [
+        {
+          "when": { "field": "first_edge_guard_missing_254", "op": "present" },
+          "level": "critical",
+          "title": "Forward guard '${first_edge_guard_missing_254}' lacks the protocol task-binding slot (254)",
+          "description": "Every guarded forward of a machine running on an order Progress requires the passport to carry a slot-254 (task binding) submission; the guard table declares none, so the forward aborts with code 11 on first traversal. Guard tables and machines freeze at publish — shipping now strands the path permanently, and no builder can patch the table afterwards.",
+          "mitigation": "Declare {identifier: 254, b_submission: true, value_type: 'Address'} in guard '${first_edge_guard_missing_254}' (protocol slot 254; the order address is written by order creation). The compile kernel auto-injects this row when the guard is edge-bound — a finding here means the guard is bound in a way the kernel could not see.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "TASKBIND-02",
+      "dimension": "fund_flow",
+      "trigger": "An allocator {GuardIdentifier:N} leg names a slot the guard table never declares as a b_submission Address — allocation aborts before paying (N-K21, amz-7f3a2c91). A properly DECLARED slot is fine: on an order-anchored allocation the submission equals payment_info.for_object (the paying Order), which is the deliberate two-step refund shape (the CoinWrapper lands on the Order and order::owner_receive extracts it to order.owner).",
+      "cases": [
+        {
+          "when": { "field": "first_alloc_slot_missing", "op": "present" },
+          "level": "critical",
+          "title": "Allocator leg ${first_alloc_slot_missing} is undeclared",
+          "description": "The allocator row pays a recipient keyed by this guard slot, but the guard table has no b_submission Address declaration for it. At allocation time the passport lacks the slot, the assert fails, and the distribution aborts — escrowed funds stay stranded because the guard froze at publish and cannot gain the declaration later. A static Address slot in the same position passes the declaration window but fails the same assertion (N-11). The fix is to declare the slot, not to abandon the leg: a declared slot on an order-anchored allocation is payable and is how order refunds work.",
+          "mitigation": "Declare {identifier: N, b_submission: true, value_type: 'Address'} in the bound guard's table so the passport can carry the submitted address. For an order refund leg, identifier 0 carries the paying Order address; the guard should pin that submission to the context (order.owner or an agent may trigger) and the payout is extracted by order::owner_receive.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "EDGE-ROSTER-NULL-PERM-01",
+      "dimension": "fund_flow",
+      "trigger": "A forward on a MONEY machine edge (destination is a final/cancelled-role node or an allocator-covered one) declares a NON-EMPTY namedOperator roster with NO permissionIndex. Verified kernel truth (ddmc4 B-24, progress.move:266-310): the permission pre-check computes permissionNeeded=false for that shape and skips the Permission assert entirely — the roster is pure decoration (the namedOperator rail only AUTHORIZES roster members and never DENIES non-members), so ANYONE with a valid order passport can push the fund/terminal forward. ddmc4 live: an outside account triggered ReturnReceived and CompensateBadItem through exactly this shape.",
+      "cases": [
+        {
+          "when": { "field": "first_roster_null_perm_edge", "op": "present" },
+          "level": "critical",
+          "title": "Money edge '${first_roster_null_perm_edge}' rides a decoration-only roster rail — anyone can push the fund forward",
+          "description": "The forward on ${first_roster_null_perm_edge} names a roster but binds no permission index. On chain the permission pre-check needs a permissionIndex to DENY: with none bound, permissionNeeded reads false, the assert is skipped, and the named-operator roster never excludes anyone (it only authorizes members — verified progress.move:266-310, ddmc4 B-24: an outsider executed ReturnReceived/CompensateBadItem). A roster rail alone on a fund/terminal edge is a world-executable payout.",
+          "mitigation": "Bind ONE denying rail on this forward: a permission_index (>= 1000; the namedOperator rail is checked first, so pick ONE rail per forward — compile rejects both), or keep the roster rail and mount the kernel roster predicate query(1575 order.named_operator member) on the edge's guard so membership actually EXCLUDES non-members (1575 is gated by the v138 flag enable_order_named_operator_member — check upgrade_check (DEPLOY-K1); on old binaries it reads false, so also tighten the rail).",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "PERM-COARSE-BUCKET-01",
+      "dimension": "fund_flow",
+      "trigger": "One permission index is bound on >= 2 money edges (final/cancelled or allocator-covered destinations) whose rail classes DIFFER — settle vs recover|award vs refund|return vs arb, classified by destination node name, forward names, and the edge guards' queries (ddmc4 B-25: 9 heterogeneous fund edges shared bucket 1002, so the arbiter entity could execute the merchant's settle AND refund rails — the coarse bucket turns one compromised permission entity into every fund action at once). A shared bucket inside ONE class is a capacity choice, not a widening.",
+      "cases": [
+        {
+          "when": { "field": "coarse_perm_bucket_index", "op": "present" },
+          "level": "medium",
+          "title": "Permission index ${coarse_perm_bucket_index} spans rail classes [${coarse_perm_bucket_classes}] — one coarse bucket plays every fund rail",
+          "description": "Money edges of DIFFERENT rail classes (${coarse_perm_bucket_classes}) all bind permission index ${coarse_perm_bucket_index}, so the entity holding that one slot can execute every heterogeneous fund action (ddmc4 B-25: the arbiter bucket rode the merchant's settle and refund edges alike). Compromise or misuse of that single permission entity is no longer contained to one rail class.",
+          "mitigation": "Split the bucket per rail class: give settle, recover/award, refund/return and arbitration-facing edges DISTINCT permission indexes held by disjoint entities (least privilege — the arbiter should hold only the arb-class slot). If one entity legitimately must span classes, document the shared custody in the build notes so the scan disclosure is a conscious choice.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "WRITE-GUARD-TAUTOLOGY-01",
+      "dimension": "field_capability",
+      "trigger": "A repository policy's write_guard whose only Signer legs are TAUTOLOGIES — Signer == a self-reported (b_submission) address the caller fills with their own, or Signer != the Entity system object 0xaab that no human wallet equals — while the policy routes rows caller-keyed (id_from none/unset, the row key also caller-supplied). Identity chosen at WRITE time is not identity: anyone may write a row under ANY order key, and before write_once anyone may OVERWRITE anyone's (pdd F-18 live: arbitrary order evidence rewritten by an outsider; h1w9 F-03 live: an outsider pre-wrote the report row and front-ran the real hunter's bounty). Guards freeze at publish (IMMUT-001).",
+      "cases": [
+        {
+          "when": { "field": "first_tautology_write_guard", "op": "present" },
+          "level": "critical",
+          "title": "Write guard ${first_tautology_write_guard} admits EVERYONE — the policy is world-writable",
+          "description": "${first_tautology_write_guard} compiles legs that prove nothing: a caller always 'equals' the writer address they themselves submitted, and no wallet equals the 0xaab system object. Combined with caller-keyed rows (id_from none), any address can author — and, absent write_once, rewrite — rows under any key, so evidence, reports and receipts carry zero attribution weight (pdd F-18: an outsider overwrote a live order's evidence). A defence that authorizes everyone is worse than none: downstream readers treat the row as verified.",
+          "mitigation": "Bind the writer set to values FIXED before publish: swap the guard to tpl_repository_write_allowlist (Signer ∈ a VecAddress allowlist frozen at publish) or tpl_repository_write_order_holder (order-keyed rows: Signer must hold the row's own Order), and arm policy write_once on final evidence so even an allowlisted writer cannot rewrite history (one evidence KIND per policy — pdd F-04: two kinds on one order-keyed policy share the row id and overwrite each other). Chain residual registered for protocol review: writer ∈ permission-entity membership as a native write-guard primitive (staff rotation today needs a guard rebuild).",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "WRITE-GUARD-TAUTOLOGY-KEYED-01",
+      "dimension": "field_capability",
+      "trigger": "Same tautology shape (only self-reported / system-constant Signer legs) on a WALLET-keyed policy (id_from signer/clock): each wallet can write only its own row, so the blast radius is smaller than the caller-keyed critical, but the written CONTENT is still unverified self-assertion — the guard validates nothing beyond 'the writer is who their wallet says' (no institutional sign-off, no order binding).",
+      "cases": [
+        {
+          "when": { "field": "first_keyed_tautology_write_guard", "op": "present" },
+          "level": "medium",
+          "title": "Write guard ${first_keyed_tautology_write_guard} verifies only the wallet, never the claim",
+          "description": "${first_keyed_tautology_write_guard} constrains WHERE a row lands (the writer's own wallet key) but not WHO may assert it or WHAT it may say: any wallet authors self-serving rows about itself under a guard that reads as a credential check. Consumers of the row get no verification signal — the policy name suggests an institutional gate the legs never encode.",
+          "mitigation": "If the rows represent an institution's attestation, pin the INSTITUTION's signer: tpl_repository_write_allowlist with the institution addresses (or the pinned single-signer twin tpl_identity_check_single) so only the attesting writer can author rows under this policy. If self-asserted rows are the intent, say so in the policy description — never borrow credential vocabulary for an unverified rail.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "WRITE-GUARD-PROMISE-GAP-01",
+      "dimension": "privacy",
+      "trigger": "A TAUTOLOGY write guard whose policy description PROMISES an authorization bound the compiled legs never encode — authorization vocabulary ('only ... signed', 'must bind the writer', 'allowlist', 'restricted to ...') over a guard whose Signer legs admit everyone. The description-vs-legs divergence is the trust failure itself (h1w9 F-03: the catalog prose said hunter-bound while the root verified nothing, so an outsider's pre-written report row outranked the real hunter's). Judged ONLY on tautology guards — a guard with one binding leg is never flagged, so pinned rails get zero false positives. A description that DISCLOSES its own tautology shape ('these legs are a TAUTOLOGY', 'the self-report shape') is exempt: prose stating the ACTUAL guarantee does not diverge from the legs — only divergence is the failure.",
+      "cases": [
+        {
+          "when": { "field": "first_promise_gap_write_guard", "op": "present" },
+          "level": "critical",
+          "title": "Policy description promises a bound writer, the guard encodes none: ${first_promise_gap_write_guard}",
+          "description": "${first_promise_gap_write_guard}: the policy text promises authorization vocabulary while the compiled guard legs admit every caller — the documented trust model and the enforced one diverge. Anything built on the prose (buyer due diligence, dispute framing, downstream automation) inherits a guarantee the chain does not deliver. Fix the LEGS or fix the PROSE — shipping both as-is is the exact failure h1w9 F-03 recorded.",
+          "mitigation": "Encode the promised bound for real: swap to tpl_repository_write_allowlist (Signer ∈ a publish-time allowlist vector) or tpl_repository_write_order_holder (order-keyed rows) and pair with policy write_once on final evidence. If the bound is genuinely not expressible today, rewrite the description to state the ACTUAL guarantee (who writes, what stays unverified) — never keep authorization vocabulary over an open guard. Three residual asks are registered for protocol review: writer ∈ permission-entity membership as a native write-guard primitive, composite row keys (order + kind), and data_remove refusing write_once rows with an event (repository.move:178-183 checks neither today).",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "NODE-MATCH-01",
+      "dimension": "fund_flow",
+      "trigger": "A guard bound on a machine forward also asserts progress.current == L where L is not that edge's prev node — the machine pins current == prev on every traversal, so the literal is unsatisfiable and the edge (with any money rail behind it) is permanently unreachable after publish (machines and guard tables freeze; ksc-tn-261024 F-02 live: a receiver-return edge pinned to 'return_requested' instead of 'return_shipped' stranded 0.45 WOW). Multi-node OR sets pass as long as prev is a member; entry edges and guards without a progress.current literal are exempt.",
+      "cases": [
+        {
+          "when": { "field": "first_node_mismatched_guard", "op": "present" },
+          "level": "critical",
+          "title": "Guard ${first_node_mismatched_guard} can never pass",
+          "description": "The guard re-checks progress.current against a node the machine has already ruled out on this edge. On chain the guard predicate is permanently false, so the forward aborts guard_rejected forever and any allocator/exit rail keyed to the destination node strands its escrow. Guards and machines freeze at publish — shipping now bakes the deadlock in.",
+          "mitigation": "Remove the progress.current literal from the guard (the machine's prev_node already enforces the source node — double-pinning only creates this class of deadlock), or correct the literal to the edge's actual prev node. One guard instance per edge; never reuse a guard across edges with different source nodes.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "HOST-GRAPH-01",
+      "dimension": "composition",
+      "trigger": "A guard exists but is bound to no host, or a guard queries repository data while the plan has no repository — the TRAILHAVEN B-2 failure: the Repository object and the third guard were silently dropped, leaving the shipping-evidence gate with nothing to check.",
+      "cases": [
+        {
+          "when": { "field": "first_repo_query_without_repository", "op": "present" },
+          "level": "critical",
+          "title": "Guard '${first_repo_query_without_repository}' queries a repository the plan never creates",
+          "description": "The guard reads repository.* data, but no repository step exists in the plan. On chain the query aborts on missing data — the forward it gates can never pass.",
+          "mitigation": "Add the repository create step and bind the guard to it, or remove the repository queries.",
+          "stakeholders": ["merchant"]
+        },
+        {
+          "when": { "field": "first_orphan_guard", "op": "present" },
+          "level": "high",
+          "title": "Guard '${first_orphan_guard}' is bound to no host",
+          "description": "The guard is created but never referenced by any machine forward, service buy_guard, allocator row, repository policy, arbitration, or reward. It is dead weight — usually a sign that a host binding was silently dropped during composition.",
+          "mitigation": "Wire the guard into its intended host binding, or delete the step.",
+          "stakeholders": ["merchant"]
+        }
+      ]
+    },
+    {
+      "rule_id": "REPO-GATE-KEY-01",
+      "dimension": "composition",
+      "trigger": "A guard's composite where-query scans a PLAN-LOCAL repository under a static policy key that no repository policy declares (ZR-32, ziroom-mn-261013: the review gate queried a key the write side never wrote — the count stayed 0 forever and the benefit was unreachable; note policies are NOT chain-frozen: permission 102 (policy_add/policy_set) can add or replace them in place post-publish, so the divergence is repairable by adding the missing policy — but the plan must not ship it). Runtime key rows and external repository addresses are unknowable at plan time and are judged by the chain-side round-trip (analyze_guard_semantics compare_with) instead.",
+      "cases": [
+        {
+          "when": { "field": "repo_gate_key_unbacked_count", "op": "gt", "value": 0 },
+          "level": "high",
+          "title": "Repository gate key ${first_repo_gate_key_unbacked} is written by no policy",
+          "description": "Unbacked scans: ${repo_gate_key_unbacked_display}. The plan declares these repository policies: ${repo_policy_keys_display}. A where-scan over an undeclared key reads an empty table as built — count/sum stay 0 and find/keys return empty — so the gated path can never pass. Repository policies are NOT chain-frozen (permission 102 can add/replace them in place post-publish; already-written rows stay bound by write_once/write_guard), so the divergence is repaired by ADDING the missing policy via permission 102 or by aligning names before publish — not by rebuilding the repository. Guards DO freeze at creation: a guard-side key literal cannot self-heal.",
+          "mitigation": "Reconcile the two sides before publish: change the guard's static key row to a declared policy name (${repo_policy_keys_display}), or rename the repository policy to the queried key. After fixing, re-verify the resolved guard with analyze_guard_semantics compare_with after creation.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "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",
+      "trigger": "A repository WRITE guard (bound via a repository policy write_guard ref) negates a 'repository.data has' probe in its root — the RETRACTED write-once idiom (bk15 K3b; ofn-mn-261012 F-02, mainnet A/B verified). The write guard is verified inside the same PTB as the write, BEFORE the row exists, so the negated probe evaluates against the pre-write state and always fails the write. The chain now has a native per-policy write-once (PolicyRule write_once, K3(a)): the WRITE PATH itself rejects overwriting an existing record — but it is declared on the policy, never expressible as a guard leg.",
+      "cases": [
+        {
+          "when": { "field": "first_repo_write_once_guard", "op": "present" },
+          "level": "high",
+          "title": "Repository write guard '${first_repo_write_once_guard}' carries an INEFFECTIVE write-once leg",
+          "description": "${repo_write_once_guard_count} write-bound guard(s) negate a 'repository.data has' probe. The leg can never do what it claims: at verification time the row does not exist yet (same-PTB pre-write evaluation), so the negation always aborts the write with E_VERIFY_FAILED — the evidence row it gates can never be written. Mainnet A/B: the identical guard minus the leg succeeded, and the author then overwrote their own review. A defence that cannot be enforced is worse than none.",
+          "mitigation": "Remove the negated has-leg from the write guard and declare write-once on the policy instead (policy write_once: true — the write path rejects overwriting an existing record with E_POLICY_WRITE_ONCE_CONFLICT). For order-bound rails use the task-binding slot (254) plus the order anchor instead; for one-write-per-guard-pool semantics use the ONCE slot (255, b_submission=true) — per guard-pool, not per order. Do NOT re-teach the negated probe: it is a guaranteed runtime abort on the write path.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "BUY-INFO-UNENFORCED-01",
+      "dimension": "composition",
+      "trigger": "A service declares customer_required but mounts no buy_guard (bk15 K11). The buy family on-chain never reads customer_required — the field alone enforces nothing at buy time. The chain has a buy-time enforcement primitive: buy_guard is evaluated inside the passport buy path, and non-passport buys reject outright when one is mounted.",
+      "cases": [
+        {
+          "when": { "field": "first_customer_required_unbacked", "op": "present" },
+          "level": "medium",
+          "title": "Service '${first_customer_required_unbacked}' declares customer_required with no buy_guard mounted",
+          "description": "${customer_required_unbacked_count} service(s) declare required customer information that nothing enforces at buy time: the on-chain buy entry points never read customer_required. Buyers who skip the info still complete the purchase, and fulfillment stalls later (post-buy collection, manual follow-up, or dispute).",
+          "mitigation": "Pick one deliberately: (a) mount a buy-spec guard (host service, key buy) whose submission legs carry the declared info, so the passport buy path enforces collection and non-passport buys reject; or (b) keep post-buy collection and disclose it honestly in the service description. Do not leave the declaration silently unenforced.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "GUARD-REACH-01",
+      "dimension": "composition",
+      "trigger": "A guard's root AND chain carries a proof-level structural contradiction: an ordering interval crossing (>= 10 conjoined with <= 5, or equal bounds with a strict side like >= X with < X), an equality family contradiction (one channel asserted == to two different numeric constants or to opposite Bool constants, or == X conjoined with > X / < X), or a same-binding self-comparison with a strict direction (X > X / X < X). The predicate is unsatisfiable by construction: the guard can never pass, and every path it gates is permanently unreachable after publish (guards freeze at creation; S3 plane static reachability). Deliberately conservative — only proof-level classes are reported: query-vs-query legs across DIFFERENT bindings (e.g. allocation.balance >= order.amount) and runtime submission values are decided at runtime and are never reported here; OR branches and negation scopes are not conjunctive and are not descended.",
+      "cases": [
+        {
+          "when": { "field": "guard_reach_contradiction_count", "op": "gt", "value": 0 },
+          "level": "critical",
+          "title": "Guard predicate is self-contradictory: ${first_guard_reach_contradiction}",
+          "description": "All contradictions: ${guard_reach_contradiction_display}. Each is a proof, not a heuristic: two legs on the same channel demand impossible bounds at the same constant, so the guard evaluates false on every submission. Any forward, allocator row or claim rail gated by it is dead on arrival — and any escrow that can only leave through that path is stranded. Guards freeze at creation, so nothing can repair the predicate after publish.",
+          "mitigation": "Repair the predicate before creation: drop the redundant leg (keep the one that states the business intent — e.g. the window lower bound OR the upper bound, never a crossing pair), or correct the constant so the legs can both hold. If one leg was meant for a DIFFERENT state, split the guard per state instead of conjoining them.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "COMPOSE-PAIR-01",
+      "dimension": "composition",
+      "trigger": "A guard reads order.* on a slot other than the host slot 0 (the P2 cross-order shape from chain-semantics/composition-truth.ts) but carries NO pairing key. Owner equality plus a provider pin proves only that this buyer has another order at that provider - it does NOT prove that order served THIS order, so one delivery order can unlock settlement on every order the same buyer ever placed. Allocation is append-only after publish and the Guard freezes at creation, so the missing key can never be added later.",
+      "cases": [
+        {
+          "when": {
+            "all": [
+              {
+                "field": "first_cross_order_guard_unpaired",
+                "op": "present"
+              }
+            ]
+          },
+          "level": "critical",
+          "title": "Cross-order gate has no pairing key (one fulfilment order can unlock many host orders)",
+          "description": "Guard '${first_cross_order_guard_unpaired}' reads a foreign order slot (${cross_order_slots_display}) with neither a repository.data rendezvous leg nor a declared 255 ONCE row. ${cross_order_unpaired_count} cross-order guard(s) are unpaired. A buyer who orders food twice and delivery once can present the same delivery order twice; the chain accepts it both times because nothing binds the fulfilment order to one host order.",
+          "mitigation": "Emit a pairing key. Preferred: a shared Repository row keyed by the HOST order address (P1) read via `repository.data has`, with write_once set on that policy rule so the fulfilment fact cannot be rewritten after settlement. Cheapest: declare {identifier: 255, b_submission: true} on the guard so the once-key includes the submitted bytes and the same foreign order address can only be consumed once.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "COMPOSE-PROVIDER-PIN-01",
+      "dimension": "composition",
+      "trigger": "A cross-order gate does not pin the foreign order's Service to a constant address. Without the pin any order the caller happens to own - at any merchant, for any amount, in any state - satisfies the gate.",
+      "cases": [
+        {
+          "when": {
+            "all": [
+              {
+                "field": "first_cross_order_guard_unpinned",
+                "op": "present"
+              }
+            ]
+          },
+          "level": "high",
+          "title": "Cross-order gate does not pin the fulfilment provider",
+          "description": "Guard '${first_cross_order_guard_unpinned}' reads a foreign order slot but never compares order.service on that slot against a constant Address row. The native evaluator enforces the submitted object's TYPE (a Progress or Service submitted as an Order aborts) but it cannot know WHICH service was intended, so the caller supplies that fact and the gate believes it.",
+          "mitigation": "Add a non-submission Address table row holding the sub-Service address as a constant, plus a leg comparing order.service(foreignSlot) to it. That constant is the merchant's own commitment (P3) and is what makes the cross-order read meaningful.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "COMPOSE-OWNER-CROSS-01",
+      "dimension": "composition",
+      "trigger": "A cross-order gate does not cross-check order.owner between the host slot and the foreign slot, so a stranger's order can satisfy it.",
+      "cases": [
+        {
+          "when": {
+            "all": [
+              {
+                "field": "first_cross_order_guard_no_owner_cross",
+                "op": "present"
+              }
+            ]
+          },
+          "level": "high",
+          "title": "Cross-order gate does not tie the two orders to one buyer",
+          "description": "Guard '${first_cross_order_guard_no_owner_cross}' reads a foreign order slot without reading order.owner on BOTH slots. Any sufficiently-shaped order from any buyer then passes, which turns a per-buyer fulfilment condition into a global one.",
+          "mitigation": "Add the leg order.owner(hostSlot) == order.owner(foreignSlot). Note this alone is still not a pairing key - see COMPOSE-PAIR-01.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "COMPOSE-LIABILITY-01",
+      "dimension": "composition",
+      "trigger": "A third party fulfils part of the service but no payout path for that party was pre-set before publish. arbitration compensation_claim transfers to order::owner(order) - the recipient is hard-bound - and indemnity is capped at MAX_INDEMNITY_MULTIPLE (3) times the order amount, so a ruling in the fulfilment party's favour has NO on-chain execution path. Allocation rows are append-only after publish, so this cannot be repaired later (chain-semantics/composition-truth.ts S4; RD-C4 ruled 2026-10-29: block, do not warn).",
+      "cases": [
+        {
+          "when": {
+            "all": [
+              {
+                "field": "third_party_fulfilment_without_payout",
+                "op": "truthy"
+              }
+            ]
+          },
+          "level": "critical",
+          "title": "Third-party fulfilment with no pre-set payout path (a ruling for the rider is unexecutable)",
+          "description": "This plan procures fulfilment from a third party (a cross-order gate is present; declared axis '${fulfillment_axis}') but declares no Entity/Signer sharing leg and creates no Reward pool. If an arbitration finds the fulfilment party was wronged - or the merchant wants to pay a rider directly - no leg can carry the money, and the only remaining channel is an off-chain transfer with no on-chain evidence.",
+          "mitigation": "Pre-set one of two paths before publish. (a) An arbitration-triggered sharing leg with Recipient::Entity or Recipient::Signer: those legs are NOT constrained by payment_info.for_object, so they can pay a party who is not the order owner; gate it with the same identity pattern the refund rails already use. (b) A Reward pool (P6) the fulfilment party claims itself - claim asserts recipient == tx sender, the only permissionless channel that reaches a third party - with store_from pinned so one fulfilment pays once.",
+          "stakeholders": ["supplier", "merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "COMPOSE-DUALREFUND-01",
+      "dimension": "composition",
+      "trigger": "V3 (the buyer procures fulfilment as a separate order) puts two escrow pools behind the SAME buyer address with different counterparties. Neither Service can read the other's claimed_by, so the chain cannot block a refund on both - a reachable 200% window. This is an inherent property to disclose, not a defect to fix (chain-semantics/composition-truth.ts S2/S3; RD-C3 ruled 2026-10-29: offer V3 as a first-class variant with mandatory disclosure).",
+      "cases": [
+        {
+          "when": {
+            "all": [
+              {
+                "field": "composition_dual_refund_unblockable",
+                "op": "truthy"
+              }
+            ]
+          },
+          "level": "medium",
+          "title": "V3 double refund cannot be blocked on chain - disclosure required",
+          "description": "The plan declares V3. The buyer owns both orders, the two pools have different counterparties, and each refund rail can only read its own order's claimed_by. Refunding on both orders is technically reachable, and the buyer's disputes must be filed twice with two fees and two panels that may rule contradictorily. ${composition_disclosure_count} disclosures are owed before purchase.",
+          "mitigation": "Surface all three V3 disclosures at build time and at the purchase gate, and require the buyer to confirm each one: (1) double refund is not blockable and is the buyer's own liability; (2) disputes cannot be merged - two filings, two fees, possibly contradictory rulings; (3) the merchant has no recourse against and no visibility into the buyer's fulfilment order. Never describe the two orders as linked on chain.",
+          "stakeholders": ["customer", "merchant"]
+        }
+      ]
+    },
+    {
+      "rule_id": "COMPOSE-VARIANT-01",
+      "dimension": "composition",
+      "trigger": "A commercial variant is declared but the plan does not emit the primitives that variant requires, so the declared business model and the materialized chain objects disagree.",
+      "cases": [
+        {
+          "when": {
+            "all": [
+              {
+                "field": "composition_variant_missing_primitives",
+                "op": "present"
+              }
+            ]
+          },
+          "level": "medium",
+          "title": "Declared variant is not backed by the primitives it needs",
+          "description": "Variant ${composition_variant} requires primitives this plan does not emit: ${composition_variant_missing_primitives}. The listing will promise a composition the published objects cannot gate - for example a merchant-procured delivery with no cross-order gate means the main order settles whether or not the sub-order was ever fulfilled.",
+          "mitigation": "Either emit the missing primitives (chain-semantics/composition-truth.ts gives the shape of each) or declare the variant the emitted topology actually supports. Emitted primitives for this plan: ${composition_primitives_emitted}.",
+          "stakeholders": ["merchant", "customer"]
+        }
+      ]
+    },
+    {
+      "rule_id": "PRIV-PUBLICFACE-01",
+      "dimension": "privacy",
+      "trigger": "A build-time public face carries text matching a language-neutral PII shape. The chain has no confidentiality primitive at all: Contact, Proof, Repository data, Entity records and listing copy are public and permanent, and the Messenger type is commented out of the registrar. The write is therefore the ONLY defence (chain-semantics/composition-truth.ts S5; RD-C5 ruled: hard gate at build time and on runtime submission).",
+      "cases": [
+        {
+          "when": {
+            "all": [
+              {
+                "field": "first_pii_public_face",
+                "op": "present"
+              }
+            ]
+          },
+          "level": "critical",
+          "title": "PII on a permanent public face (cannot be retracted after creation)",
+          "description": "Step '${first_pii_public_face_step}' writes ${first_pii_public_face} and the text matches the '${first_pii_kind}' shape. Once created, this value is publicly readable forever - there is no delete, no redaction and no read-permission primitive. A delivery address, phone number or identity number published here is published to every indexer and every competitor.",
+          "mitigation": "Move the value off chain: PII travels only through Messenger (E2EE), and the chain carries a presence gate instead - `order.required_info some` proves the buyer supplied it without publishing it. If a proof of the value is genuinely needed on chain, store a hash. Contact.location should stay city-level.",
+          "stakeholders": ["customer", "merchant"]
+        }
+      ]
+    },
+    {
+      "rule_id": "PRIV-TRACKING-RAW-01",
+      "dimension": "privacy",
+      "trigger": "A repository data value is a RAW carrier tracking number rather than a hash. Repository data is publicly readable with no author field, and a tracking number is a quasi-identifier: the carrier's own public lookup resolves it to a recipient name and address, so the raw number republishes the delivery address by reference.",
+      "cases": [
+        {
+          "when": {
+            "all": [
+              {
+                "field": "first_raw_tracking_value",
+                "op": "present"
+              }
+            ]
+          },
+          "level": "high",
+          "title": "Raw tracking number stored in a public repository row",
+          "description": "Step '${first_raw_tracking_value_step}' writes '${first_raw_tracking_value}' as a repository data value. Anyone reading the row can resolve it at the carrier to a recipient and an address, and the row can be correlated with the order it was written for.",
+          "mitigation": "Store a salted hash of the tracking number and hand the raw value to the buyer and the carrier over Messenger. If the row must stay human-readable for support, store the last four characters only.",
+          "stakeholders": ["customer", "supplier"]
+        }
+      ]
+    },
+    {
+      "rule_id": "PRIV-PROOF-PERORDER-01",
+      "dimension": "privacy",
+      "trigger": "required_info is attested through a Proof bound to the ORDER, which publicly associates that order with the contact record. The reusable shape (about = the contact) carries the same attestation without the per-order link.",
+      "cases": [
+        {
+          "when": {
+            "all": [
+              {
+                "field": "per_order_proof_binding_step",
+                "op": "present"
+              }
+            ]
+          },
+          "level": "low",
+          "title": "Per-order Proof binding publicly links the order to a contact record",
+          "description": "Step '${per_order_proof_binding_step}' binds a Proof to the order (or binds required_info through a proof). The binding is verifiable by anyone and permanently ties that order address to that contact record, widening what an observer can correlate.",
+          "mitigation": "Prefer the reusable Proof shape whose `about` is the contact rather than the order, unless per-order binding is a deliberate requirement of the flow.",
+          "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"]
+        }
+      ]
+    }
+  ]
+}