Harden shell-mounted host tables

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

- Require passive-load, explicit-action, and non-primary route coverage for shared modal, wizard, tour, and takeover hosts.

- 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 shell-mounted UI hosts as a first-class reachability case. Tables must inventory inherited route classes, distinguish passive navigation or refresh from explicit start/resume actions, and require non-primary route coverage when a shared modal, wizard, tour, or takeover can block or replay 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, shell-mounted UI 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,7 +27,7 @@ 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, shell-mounted UI 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 layout/sidebar/modal host mounts, 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 global UI hosts, distinguish passive route entry from explicit user actions and include non-primary routes that inherit the mount, not only the route 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.
 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`.
@@ -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 shell-mounted UI hosts, modals, tours, and takeovers, include passive entry on every inherited route class plus explicit resume/start 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 |
+| shell-mounted UI host reachability | route-class inventory and passive-load tests for inherited routes, not only the primary route or explicit resume 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>
+- Shell-mounted UI 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 shell-mounted UI hosts, include every inherited route class and distinguish passive load from explicit start/resume actions, with non-primary route coverage when the host can block or replay UI 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.
 
+## Shell-mounted UI host reachability
+
+When a modal, wizard, tour, banner, takeover, or other UI host is mounted by a shared shell, layout, sidebar, provider, or root component, include rows for every route class that inherits the host, not only the feature's primary route. Distinguish passive navigation or refresh from explicit start, resume, continue, retry, or recovery actions. If product or guardrail text forbids an automatic takeover, replayed tour, or blocking prompt for already-authenticated users, include rows proving legacy and already-complete users stay non-blocked on at least one non-primary authenticated route.
+
+**Tests:** require a positive control for the intended guided entry path, a passive-load negative case on a non-primary inherited route, and a legacy or already-complete state case when persisted onboarding, 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.