fix(code): harden decision-table gates

CHANGELOG.md

@@ -4,6 +4,17 @@ All notable changes to the claude-plugins project will be documented in this fil
 
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/). Entries are listed newest-first; each plugin section is treated as released when merged to `main`.
 
+### code v1.14.8
+
+#### Added
+- Contract test suite `test_decision_table_skill_contract.py` pinning the new decision-table skill guarantees: `Not aligned` as a terminal workflow stop, required coexisting-source interaction and precedence rows, shared-corpus production-boundary parity for executable twins, and row-ID-to-test traceability in `Required Tests`.
+
+#### Changed
+- Hardened the `decision-table` skill's alignment gate: `Final Alignment Status: Not aligned` is now a terminal workflow stop, not a report-only status. No PR creation, merge, completion signal, or success closeout may follow until the artifact is re-verified as `Aligned`; fixable repo-local findings remain unresolved work and cannot be normalized into a successful handoff. The human-facing closeout for a `Not aligned` run must state that downstream PR/merge/completion is blocked, name every unresolved blocker, and give the exact next action and owner. A matching common-miss item ("Not-aligned status treated as success") and a contract-heavy review bullet enforce the stop during review-prevention passes.
+- Decision rows now carry stable row IDs, and `Required Tests` is a traceability table instead of a prose list. The `Current Code` and `Intended Change` tables gain a `Row ID` column, and each required test maps to its decision-row IDs with a positive control, a wrong-input or mixed-state negative case, the real production boundary exercised, and expected evidence. Every material row must be covered by at least one mapped test or carried into `Not aligned` with a blocker; a test listed without row IDs or without the negative case needed to distinguish the row's branch is a named review-prevention anti-pattern.
+- New "Executable policy twins and parity" edge-case category: when one behavior or policy has multiple executable twins (a pure helper, SQL predicate, route, worker, producer, batch path, or recovery path), one shared scenario corpus must exercise every twin through its real production boundary and assert identical decisions. Source-string, AST-presence, and SQL-shape assertions are supplemental only and never establish parity, and a negative shape assertion that requires a policy predicate, identity term, join, or branch to be absent is flagged as pinning missing policy: if it permits divergence, the row is `Not aligned` until corrected. Two new review-prevention anti-patterns cover parity inferred from separate tests and shape assertions that pin missing policy.
+- New "Coexisting sources and precedence" edge-case category: when multiple evidence, authority, history, cache, or fallback sources can coexist, singleton rows are insufficient. The table must add a bounded interaction set (pairwise plus code-identified high-risk intersections, never an unbounded Cartesian product) covering legacy or absent evidence alongside fresh valid evidence, corrupt or undated evidence alongside fresh valid evidence, irrelevant historical evidence alongside a current authoritative record, tied or conflicting current records, and source/state precedence, stating which source wins and why. Singleton-only source coverage is a named review-prevention anti-pattern.
+
 ### platform v1.1.4
 
 #### Fixed

plugins/code/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "code",
   "description": "Code and planning framework plugin",
-  "version": "1.14.7",
+  "version": "1.14.8",
   "author": {
     "name": "ClosedLoop",
     "email": "support@closedloop.ai"

plugins/code/skills/decision-table/SKILL.md

@@ -29,13 +29,13 @@ Keep multiple behavior areas as sections inside the same artifact. Only split in
 5. Read the actual code paths. Build the table from code, not expectations.
 6. For shared routes, handlers, helpers, contracts, or policy surfaces, build a call-site inventory before choosing axes. Search for literal route paths, exported helper names, feature flag keys, rollout keys, query parameters, cache key segments, environment variable names, storage keys, event names, command names, plugin or marketplace identifiers, header/reason/status strings, and shared types. For each caller, record what data it can supply, what response shapes/statuses it expects, peer version skew, and how missing/unknown fields degrade. Classify each literal by semantic purpose and source of truth; do not treat similar-looking strings as aliases unless a shared constant, documented contract, or existing compatibility path proves they are aliases.
 7. For dependencies, model success, null/absent, validation failure, and thrown/rejected branches whenever externally visible behavior depends on them.
-8. Run the behavioral edge-case expansion pass. Apply every category in `references/edge-cases.md`. Each must be represented by rows or an explicit non-applicability note with source-backed evidence. For distributed command, signing, key, capability, or cross-process state work, treat web app, backend, Electron, local store, OS notification, cache, and remote peer behavior as separate surfaces unless code proves they are the same surface.
+8. Run the behavioral edge-case expansion pass. Apply every category in `references/edge-cases.md`. Each must be represented by rows or an explicit non-applicability note with source-backed evidence. When multiple evidence, authority, history, or fallback sources can coexist, add a bounded interaction pass: cover pairwise and high-risk intersections instead of an unbounded Cartesian product, including legacy/absent plus fresh valid, corrupt/undated plus fresh valid, irrelevant historical plus current authoritative, tied/conflicting current records, and source/state precedence. For distributed command, signing, key, capability, or cross-process state work, treat web app, backend, Electron, local store, OS notification, cache, and remote peer behavior as separate surfaces unless code proves they are the same surface.
 9. Choose a small set of state axes that explain the branch behavior. Reuse the same axes within a behavior area across `Current Code` and `Intended Change`.
 10. Write the artifact using `references/artifact-format.md`.
 11. When a plan is in scope, include `Current Code`, `Intended Change`, `Delta Checklist`, and `Required Tests`. When no plan is in scope, omit `Intended Change` and focus on the current-state table plus gaps or suspicious branches.
-12. For `Required Tests`, name the invariant being proved, the positive path, and the failure or compatibility mutation. A test must prove the specific binding/fallback/diagnostic the row claims; it cannot just trigger a generic rejection. When a row depends on an exact external contract literal, the test oracle must fail closed for the wrong literal: feature-flag mocks enable only the exact expected key, query/header/event assertions check exact names and values, and cache/storage/command/plugin identifiers are asserted by semantic type rather than broad substring or "any key" matching.
+12. Give every material decision row a stable row ID. For `Required Tests`, map each test to one or more row IDs and name the invariant being proved, the positive path, and the wrong-input, mixed-state, failure, or compatibility mutation. A test must prove the specific binding/fallback/diagnostic the row claims; it cannot just trigger a generic rejection. When a row depends on an exact external contract literal, the test oracle must fail closed for the wrong literal: feature-flag mocks enable only the exact expected key, query/header/event assertions check exact names and values, and cache/storage/command/plugin identifiers are asserted by semantic type rather than broad substring or "any key" matching.
 13. Once implementation begins, freeze `Current Code` and `Intended Change`. All later updates are append-only in `Verification Findings`, `Fixes Applied`, `Final Alignment Status`, and optional `Plan Clarifications`.
-14. After implementation, verify the final code against the intended behavior. If drift, missing edges, missing tests, or guardrail violations exist, fix them, append the verification/fix sections, and re-verify until aligned.
+14. After implementation, verify the final code against the intended behavior. If drift, missing edges, missing tests, or guardrail violations exist, fix them, append the verification/fix sections, and re-verify until aligned. `Final Alignment Status: Not aligned` is a terminal stop: do not proceed to PR creation, merge, completion, or any downstream success state while it remains. Fixable repo-local findings remain unresolved work and must be fixed and re-verified; they cannot be normalized into a successful handoff.
 15. Record evidence artifacts for high-yield coverage and non-applicability claims. Use `references/artifact-format.md` and capture the actual command or source evidence for changed exports, package subpaths, CLI flags, route/query/header/event/cache/storage/command literals, path or filesystem writes, untrusted input fields, persisted schema fields, replay/idempotency behavior, and test-boundary coverage. Do not accept an assertion such as "no consumers", "not externally visible", or "covered by tests" without the corresponding evidence.
 16. Run the adversarial responsibility split described below. When delegation is available, this is a post-implementation review by independent lane workers. When delegation is unavailable, run the applicable lanes sequentially and record that the pass was not independent.
 17. Group `Fixes Applied` by discovery source when more than one source exists (e.g., `Initial verification`, `Adversarial abuse/filesystem lane`, `Adversarial compatibility lane`, `Runtime testing`, `Review findings`, `Validation failures`, `Repo guardrails`, `Plan clarification`, `Final hygiene`). Do not leave a broad `During verification` bucket once other sources have produced fixes.
@@ -45,7 +45,7 @@ Keep multiple behavior areas as sections inside the same artifact. Only split in
     - **Review-prevention:** for every touched externally visible surface, walk `references/review-prevention.md`. Each item must be fixed, already covered by a named row/test, marked not applicable with source-backed evidence, or carried into `Not aligned`. Do not mark `Aligned` while any item is merely assumed covered.
     - **Coverage and evidence disposition rule (hard rule):** every `Covered` or `already covered` disposition, whether it appears in `Verification Findings`, in the Behavioral Edge-Case Expansion, in the adversarial lanes, or in the review-prevention pass, must cite a specific test name and the wrong-input or negative case that test fails closed on. Every `not applicable` disposition must cite source-backed evidence such as grep output, export/package inventory, call-site inventory, schema/query inventory, or code references proving the surface is absent or out of scope. A coverage claim backed only by a happy-path assertion, a pure helper test for an integration boundary, or no evidence is treated as `Not aligned`, not as covered. This applies to security findings: do not mark a security finding `Covered` without a named test proving the rejected or blocked case.
 20. Only change `Intended Change` post-implementation if the plan itself was ambiguous or wrong. Record this as `Plan Clarifications` with reason and source. Never silently rewrite the target.
-21. Always give the user a human-facing closeout summary outside the artifact. Separate: what was verified and fixed, important nuances, and anything still requiring user input or external action. If the agent cannot complete something autonomously (product decision, credentials, deployment access, independent adversarial review), ask the user directly. If no user action is required, say so. If the user also asked for review, use the artifact as a first-class input rather than recreating the analysis.
+21. Always give the user a human-facing closeout summary outside the artifact. Separate: what was verified and fixed, important nuances, and anything still requiring user input or external action. When status is `Not aligned`, explicitly state that downstream PR/merge/completion is blocked, name every unresolved blocker, and give the exact next action and owner; never phrase it as completion. If the agent cannot complete something autonomously (product decision, credentials, deployment access, independent adversarial review), ask the user directly. If no user action is required, say so. If the user also asked for review, use the artifact as a first-class input rather than recreating the analysis.
 
 ## Adversarial Responsibility Split
 
@@ -75,6 +75,7 @@ Do not mark `Final Alignment Status: Aligned` solely on the basis of unavailable
 - Keep wording compact and behaviorally specific. Use clickable file links and plan IDs/URLs for non-obvious rows.
 - Treat an entry path as actual caller plus capabilities, not just a route or module name. Include rows for callers that cannot supply newly required headers, proof material, payload fields, or response handling.
 - Call out parity requirements between entry paths (live vs recovery, upload vs replay, retry vs terminal, middleware vs direct, internal vs external). When two entry paths must enforce the same policy, final verification should confirm a shared helper or focused parity tests unless duplication is intentionally documented.
+- When one behavior or policy has multiple executable twins (for example a pure helper, SQL predicate, route, worker, producer, or recovery path), use one shared scenario corpus to exercise every twin through its real production boundary and assert identical decisions. Source-string, AST-presence, and SQL-shape assertions are supplemental only and never prove behavioral parity. Treat a negative source-shape assertion that requires a predicate or policy term to be absent as suspicious: if it pins a missing predicate or permits divergence, record it as `Not aligned` until corrected.
 - For cross-surface state changes, include how each affected replica or process learns about the write, what durable source of truth resolves disagreement, and how missed events, offline peers, refreshes, reconnects, polling, heartbeats, and startup recovery converge.
 - Separate data visibility from side effects. A table row proving data appears in a list, cache, or refresh result does not prove notifications, telemetry, command dispatch, revocation, deduplication, or other effects fired.
 - For cached peer capabilities or supported operations, include fresh cache, stale false negative, stale false positive, old peer, retry, fallback, and reconciliation rows before relying on the cache to skip a command or safety action.
@@ -88,6 +89,7 @@ Do not mark `Final Alignment Status: Aligned` solely on the basis of unavailable
 - If the same state or failure reason appears in multiple rows with different intended outcomes, add the missing axis or flag the contradiction before implementation.
 - Every `Covered` or `already covered` disposition must cite a specific test name and the wrong-input or negative case that test fails closed on. Coverage for a CLI, route, package export, worker/job, replay, ingest, attribution, or other integration surface must cite a test through that real boundary; a pure helper test only covers helper-local invariants. Every `not applicable` disposition must cite source-backed evidence such as grep output, export/package inventory, call-site inventory, schema/query inventory, or code references proving the surface is absent or out of scope.
 - Do not use soft final states (`Partially aligned`, `Mostly aligned`, `Recorded Gaps`). Use `Aligned` only when no known fixable drift or required-test gap remains; otherwise `Not aligned` with the blocker.
+- Treat `Not aligned` as a hard workflow gate, not a report-only status. No PR, merge, completion signal, or success closeout may follow until the artifact is re-verified as `Aligned`.
 - Do not mark `Aligned` if repo guardrails are violated, a required backward-compatible fallback is missing, plan/guardrail tension is unresolved, throw-capable preparation or framework-managed retry/reconnect paths are unrepresented, required evidence artifacts are missing, required independent adversarial review was not run, or the review-prevention pass is incomplete.
 - The decision table is an LLM working artifact. Never bury user-actionable information only in the artifact; surface it in the final response.