Harden shared host decision tables (#196)

- Add shared host reachability to the decision-table skill, edge-case expansion, artifact format, and review-prevention pass.

- Require passive-entry, explicit-action, and non-primary entry-point coverage for shared wrappers, middleware, dispatchers, schedulers, root components, job runners, and callback registries.

- Bump the code plugin to v1.14.11 and update changelog and README documentation.

Testing: uv run --frozen --group dev pytest plugins/code/tools/python/test_decision_table_skill_contract.py; uv run --frozen --group dev pytest plugins/code/tools/python; uv run --frozen --group dev ruff check .; uv run --frozen --group dev pyright; git diff --check

Risks: Low; guidance and contract-test change only.

Author: shafty023

CHANGELOG.md

@@ -4,6 +4,11 @@ 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.11
+
+#### Changed
+- The `decision-table` skill now treats shared hosts as a first-class reachability case. Tables must inventory inherited entry-point classes, distinguish passive entry from explicit actions, and require non-primary entry-point coverage when a shared wrapper, middleware, dispatcher, scheduler, root component, callback registry, or other common container can trigger behavior outside its intended entry path.
+
 ### code-review v3.7.1
 
 #### Fixed

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

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

plugins/code/README.md

@@ -308,7 +308,7 @@ Runs Codex to review a plan file and returns structured feedback with a verdict.
 
 ### `decision-table`
 
-Generates a repo-local decision-table artifact that makes control-flow and stateful edge cases reviewable. Used when the user wants a code-grounded table for current behavior, wants to compare current behavior against a plan or work item, or needs a control-flow artifact for recovery, retry, finalization, validation, state-machine, or review-heavy edge cases. Writes one artifact per work item under `.closedloop-ai/decision-tables/` (`<plan-id>.md` for plan-scoped work, `<short-work-name>.md` otherwise) using the format defined in `references/artifact-format.md`. Builds the `Current Code` table from code (not expectations), captures the target behavior in `Intended Change`, and freezes both once implementation begins; post-implementation drift is recorded in append-only `Verification Findings`, `Adversarial Review`, `Fixes Applied`, `Final Alignment Status`, and optional `Plan Clarifications` sections. Includes a behavioral edge-case expansion pass that explicitly models structured-result setup failures, library-managed lifecycle re-entry, published contract compatibility, CLI flag parsing, filesystem read/write safety, time-bound credentials/signatures, durable finalization and replay eligibility, diagnostic reason taxonomies, and side-effect boundaries for validation failures. The artifact also records `Evidence Artifacts` for high-yield coverage and non-applicability claims, distinguishing named fail-closed test coverage from source-backed `not applicable` evidence, and supports coordinator-run adversarial lanes with a sequential fallback for subagents that cannot delegate.
+Generates a repo-local decision-table artifact that makes control-flow and stateful edge cases reviewable. Used when the user wants a code-grounded table for current behavior, wants to compare current behavior against a plan or work item, or needs a control-flow artifact for recovery, retry, finalization, validation, state-machine, or review-heavy edge cases. Writes one artifact per work item under `.closedloop-ai/decision-tables/` (`<plan-id>.md` for plan-scoped work, `<short-work-name>.md` otherwise) using the format defined in `references/artifact-format.md`. Builds the `Current Code` table from code (not expectations), captures the target behavior in `Intended Change`, and freezes both once implementation begins; post-implementation drift is recorded in append-only `Verification Findings`, `Adversarial Review`, `Fixes Applied`, `Final Alignment Status`, and optional `Plan Clarifications` sections. Includes a behavioral edge-case expansion pass that explicitly models structured-result setup failures, shared host reachability, library-managed lifecycle re-entry, published contract compatibility, CLI flag parsing, filesystem read/write safety, time-bound credentials/signatures, durable finalization and replay eligibility, diagnostic reason taxonomies, and side-effect boundaries for validation failures. The artifact also records `Evidence Artifacts` for high-yield coverage and non-applicability claims, distinguishing named fail-closed test coverage from source-backed `not applicable` evidence, and supports coordinator-run adversarial lanes with a sequential fallback for subagents that cannot delegate.
 
 ### `design-inventory`
 

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

@@ -27,9 +27,9 @@ Keep multiple behavior areas as sections inside the same artifact. Only split in
 3. Read the plan first (if any) and extract only behaviorally relevant requirements.
 4. Read repo-level guardrails as co-equal requirements: agent instruction files (`AGENTS.md`, `CLAUDE.md`), compatibility rules, contributor docs, API contracts. If the plan and guardrails conflict, record the tension in the artifact, add a `Plan Clarifications` note when appropriate, and surface the conflict to the user if it affects implementation or review.
 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.
+6. For shared routes, handlers, helpers, contracts, hosts, 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, shared mounts or registrations, 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. For shared hosts, distinguish passive entry from explicit user or operator actions and include non-primary entry points that inherit the host, not only the entry point the feature is meant to guide. 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. 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.
+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 client app, server, desktop or native runtime, local store, notification layer, 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.
@@ -73,7 +73,7 @@ Do not mark `Final Alignment Status: Aligned` solely on the basis of unavailable
 
 - Prefer rows over prose. If a behavioral difference matters, capture it as a row.
 - 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.
+- 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. For shared hosts, include passive entry on every inherited entry-point class plus explicit resume/start/dispatch actions.
 - 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.

plugins/code/skills/decision-table/references/artifact-format.md

@@ -42,13 +42,15 @@ Record evidence for high-yield coverage and non-applicability claims. Paste conc
 | filesystem/path write | symlink/clobber/bounds/canonicalization evidence and tests | ... | covered / not applicable / not aligned |
 | new trusted/persisted field | source, forgeability, validation/guard, legacy behavior, and mutation test | ... | covered / not applicable / not aligned |
 | replay/idempotency behavior | replay path test through production sequencing, not only helper state | ... | covered / not aligned |
+| shared host reachability | entry-point inventory and passive-entry tests for inherited entry points, not only the primary entry point or explicit action | ... | covered / not aligned |
 | integration-boundary coverage claim | named test entering through CLI, route, package export, worker/job, replay, ingest, attribution, or public API | ... | covered / not aligned |
 
 ## Behavioral Edge-Case Expansion
 
 Apply every category in [`edge-cases.md`](edge-cases.md). Each must be represented by rows or an explicit non-applicability note with source-backed evidence before marking `Final Alignment Status: Aligned`. The bullets below are placeholder shape — the canonical list is in `edge-cases.md`; do not skip categories that are absent from this template.
 
 - Structured-result setup failures: <rows or non-applicability note>
+- Shared host reachability: <rows or non-applicability note>
 - External contract literal binding: <rows or non-applicability note>
 - Library-managed lifecycle re-entry: <rows or non-applicability note>
 - Cross-surface propagation and reconciliation: <rows or non-applicability note>
@@ -163,6 +165,7 @@ Guidelines:
 - Keep data visibility rows separate from side-effect rows such as notifications, dispatches, telemetry, cleanup, and deduplication.
 - For capability- or operation-gated behavior, include fresh cache, stale false negative, stale false positive, old peer, fallback, retry, and reconciliation rows.
 - For legacy persisted records missing new fields, include conservative defaults, evidence-backed promotion/backfill, downgrade behavior, and manual-record protection.
+- For shared hosts, include every inherited entry-point class and distinguish passive entry from explicit actions, with non-primary entry-point coverage when the host can trigger behavior outside its intended entry path.
 - For distributed command/key/signing workflows, include register/create, approval/authorization, normal command, revoke/delete, offline/reconnect reconciliation, repeated action/idempotency, and stale UI/cache scenarios.
 - Every nontrivial row should include file or plan references.
 - Mark inferred target-state behavior explicitly when the plan implies it but does not say it directly.

plugins/code/skills/decision-table/references/edge-cases.md

@@ -18,6 +18,12 @@ Include rows for synchronous preparation failures before fetch/await/return: URL
 
 When a helper, service, adapter, route, command, job, or handler can be called by more than one path, include rows for the invariants it must enforce itself even when current callers validate first, especially before network I/O, persistence, credentials, filesystem mutation, or other durable side effects. Do not rely only on caller-side validation: either the boundary enforces its own invariants, or record why it is intentionally private/single-caller and how that is kept true.
 
+## Shared host reachability
+
+When behavior is installed by a shared host above multiple entry points, include rows for every entry-point class that inherits the host, not only the feature's primary entry point. Hosts include shared wrappers, root components, providers, middleware, dispatchers, schedulers, route groups, job runners, callback registries, and other common containers. Distinguish passive entry such as navigation, refresh, replay, scheduled execution, callback delivery, or automatic retry from explicit start, resume, continue, dispatch, retry, or recovery actions. If product, plan, or guardrail text forbids an automatic takeover, replayed prompt, blocking gate, or side effect for already-satisfied users or records, include rows proving legacy and already-complete states stay non-blocked on at least one non-primary inherited entry point.
+
+**Tests:** require a positive control for the intended entry path, a passive-entry negative case on a non-primary inherited entry point, and a legacy or already-complete state case when persisted state, consent, setup, or policy records can be absent.
+
 ## Executable policy twins and parity
 
 When the same behavior or policy is implemented by more than one executable path (for example a pure helper, SQL predicate, route, worker, producer, batch path, or recovery path), inventory every twin and identify its real production boundary. Build one shared scenario corpus and run every twin against it so the test proves identical decisions for identical inputs.
@@ -90,7 +96,7 @@ Include rows for success, validation failure, dependency failure, cancellation/t
 
 When a write affects multiple processes, replicas, apps, windows, stores, or peers, include rows for how every affected surface learns about the write. Cover immediate push/control events, polling, heartbeat, reconnect, startup, manual refresh, missed event, offline recovery, and the durable source of truth that wins when surfaces disagree.
 
-For distributed browser-command, key, authorization, or signing workflows, model the web app, backend, Electron process, local trusted-key store, OS notification layer, command dispatcher, and remote peer separately unless implementation proves two surfaces share the same state and lifecycle.
+For distributed client-command, key, authorization, or signing workflows, model the client app, server, desktop or native process, local trusted-key store, notification layer, command dispatcher, and remote peer separately unless implementation proves two surfaces share the same state and lifecycle.
 
 **Tests:** require at least one immediate propagation assertion and one delayed or missed-event reconciliation assertion. The test must prove the affected consumer changed behavior, not only that the source write succeeded.