@danmoisan/drm-copilot-mcp 1.1.18 → 1.1.20

package/resources/claude-customizations/.claude/rules/orchestrator-state.md

@@ -32,6 +32,37 @@ A hardened snapshot from another repository contains a JSON Schema for the orche
 
 This prohibition is specific to the disqualified foreign schema identified by the `drmoisan.github.io/mix-calculator/` `$id`. A schema whose `$id` is repo-local and whose required-field set and `additionalProperties` policy match this repository's checkpoint contract is not the disqualified foreign artifact; even so, the repository's enforcement mechanism remains the Python validator prose-and-logic above, not an imported schema file.
 
+## Required Top-Level Keys
+
+Plain validation requires every key below at the top level of the orchestrator-state checkpoint. The authority is `REQUIRED_STATE_KEYS` in `scripts/dev_tools/validate_orchestrator_state.py`. The TypeScript port in `extensions/drm-copilot/src/lib/validate/orchestrator-state-core.ts` and the PowerShell port in `.claude/lib/orchestrator-state/OrchestratorState.psm1` carry the same keys in the same order.
+
+- `objective`
+- `change_budget_estimate`
+- `path_selected`
+- `promotion-type`
+- `short-name`
+- `relativeFile`
+- `long-name`
+- `issue-num`
+- `feature-folder`
+- `work-mode`
+- `plan-path`
+- `completed_steps`
+- `next_step`
+- `last_updated`
+- `step5_status`
+- `step6_status`
+- `step7_status`
+- `step8_status`
+- `step9_status`
+- `step10_status`
+- `delegation_receipts`
+- `blocked_reason`
+
+The check is unconditional: it runs with or without `--require-complete`, `--require-pr-creation-ready`, `--require-model-routing`, `--require-codex-model-routing`, and `--require-codex-topology`, and it is skipped only for a `portable_orchestration_handoff` envelope. The check is presence-only: a key whose value is any JSON value, including `null`, satisfies it. Each absent key produces one error line, `Checkpoint missing required key: <key>`. Some keys carry further validation when present, such as the step-status vocabulary for the `step*_status` keys and the Blocked-Reason Vocabulary below for `blocked_reason`.
+
+`last_updated` records when the checkpoint was last written. Write it as an ISO-8601 UTC date-time string, for example `2026-10-08T17:28:00Z`. The value is rewritten on every checkpoint write: after every completed step and every state transition, including halts. The validators check presence only and do not parse the value, so a non-UTC, placeholder, or `null` value still passes the required-key check.
+
 ## Scope and Backward Compatibility
 
 These invariants apply only when the checkpoint contains a top-level `remediation_loop`; the per-cycle invariants apply when it has a `cycles` array, and the review-outcome and attempt-count invariants apply when their keys are present. A checkpoint with no `remediation_loop` (the existing step-based checkpoint shape) is unaffected: it validates exactly as before and produces no new errors. The invariants are additive.
@@ -170,7 +201,7 @@ The complexity-assessment and model-routing-receipt invariants above are key-gat
 
 ## Bare-Module CLI Contract
 
-The validator module runs directly as `python -m scripts.dev_tools.validate_orchestrator_state <path> [--require-complete] [--require-model-routing] [--require-pr-creation-ready] [--require-codex-model-routing] [--require-codex-topology]`. The dispatcher `python -m scripts.dev_tools.validate_orchestration_artifacts orchestrator-state` stays available and accepts the same flags. Exit code 0 means the checkpoint passed and the success line `orchestrator-state validation passed: <path>` is written to stdout. Exit code 1 means validation errors, written one per stderr line. Exit code 2 means the path is missing, unreadable, or not UTF-8, with one stderr diagnostic and no traceback; argparse usage errors also exit 2.
+The validator module runs directly as `python -m scripts.dev_tools.validate_orchestrator_state <path> [--require-complete] [--require-model-routing] [--require-pr-creation-ready] [--require-codex-model-routing] [--require-codex-topology]`. The dispatcher stays available and accepts the same flags in two invocation forms: the module form `python -m scripts.dev_tools.validate_orchestration_artifacts orchestrator-state`, run from the repository root, and the file-path form `python scripts/dev_tools/validate_orchestration_artifacts.py orchestrator-state`. Both forms reach the same `main()`, so their flags, output lines, and exit codes are identical, and a relative artifact path resolves against the working directory in both. The file-path form derives the repository root from the script location and inserts it first in `sys.path` only when the script runs without a package context. The bare-module validator is supported in the module form only. Exit code 0 means the checkpoint passed and the success line `orchestrator-state validation passed: <path>` is written to stdout. Exit code 1 means validation errors, written one per stderr line. Exit code 2 means the path is missing, unreadable, or not UTF-8, with one stderr diagnostic and no traceback; argparse usage errors also exit 2.
 
 ## Invariants (require_model_routing mode)
 
@@ -204,7 +235,7 @@ Enforcement is validator logic plus this prose, never an imported JSON Schema. T
 
 These invariants apply only when a checkpoint contains a top-level `standalone_merge_authorizations` array. The key may appear in any of the three checkpoints the epic merge gate reads: `artifacts/orchestration/orchestrator-state.json`, `artifacts/orchestration/epic-orchestrator-state.json`, and `artifacts/orchestration/parallel-orchestrator-state.json`. A checkpoint with no such key (the existing checkpoint shape) is unaffected: it validates exactly as before and produces no new errors. The invariants are additive and key-gated. No JSON Schema file is authored, imported, or read for the block (see the Foreign Schema Warning above); the enforcing surface is the `PreToolUse` merge gate (issue #670).
 
-Each entry records one authorized standalone merge with the shape `{ pr_number, pr_url, issue_num, branch_name, authorized_by, authorized_at, session_id, basis, run_slug? }`. The gate consults the array only for a `gh pr merge --merge` command that names an explicit pull request number, and only after its per-feature, epic, and parallel allow conditions have all declined.
+Each entry records one authorized standalone merge with the shape `{ pr_number, pr_url, issue_num, branch_name, authorized_by, authorized_at, session_id, basis, run_slug? }`. The gate consults the array only for a `gh pr merge --merge` command that names an explicit pull request number, and only after its per-feature, epic, and parallel allow conditions have all declined. For a command that names an explicit pull request number, the gate reads the per-feature checkpoint `artifacts/orchestration/orchestrator-state.json` beneath the one live worktree whose checkpoint records that number in `pr_gate.pr_number` or in a `standalone_merge_authorizations` entry, and it reads no per-feature checkpoint when no live worktree or more than one records it; a bare command reads the checkpoint beneath the session worktree.
 
 Honest disclosure: the standalone-merge authorization record is a policy-level, auditable declaration and is
 not a cryptographic or security control.
@@ -243,7 +274,7 @@ The object has the shape `{ issue_num, issue_url, origin, verified_via, verified
 | `verified_at` | Present, not `null`, and not a blank string. |
 | `evidence` | A string with non-whitespace content. |
 | `waived_tools` | A non-empty list of non-blank tool names that includes `potential_to_issue`. |
-| `potential_record` | Required when waiving a promotion-entry tool: a path under `docs/features/potential/` ending in `.md`. |
+| `potential_record` | When waiving a promotion-entry tool: required when `origin` is `epic_decomposition`, optional when `origin` is `transferred` or `filed_before_orchestration`, and validated whenever it is present (a path under `docs/features/potential/` ending in `.md`). |
 
 The rules run in this order, and their errors accumulate:
 
@@ -255,10 +286,12 @@ The rules run in this order, and their errors accumulate:
 6. `verified_at` must be present: absent, `null`, and blank strings are rejected; any other value passes.
 7. `evidence` must be a non-empty string.
 8. `waived_tools` must be a non-empty list of non-blank strings; otherwise no further rule-8 or rule-9 check runs. Each entry, in list order, receives the first applicable error of: listed more than once; not in the closed waivable set; not required by the selected route after promotion-type resolution; already holding a successful MCP receipt. The list must include `potential_to_issue`.
-9. Only when the rule-8 shape check passed: each distinct waived promotion-entry tool (`new_potential_entry` or `new_potential_bug_entry`) requires a valid `potential_record`.
+9. Only when the rule-8 shape check passed: each distinct waived promotion-entry tool (`new_potential_entry` or `new_potential_bug_entry`) requires a valid `potential_record`, except that rule 9 reports nothing when `origin` is `transferred` or `filed_before_orchestration` and the `potential_record` key is absent. A present `potential_record`, including `null`, is always validated.
 
 The closed waivable set is `potential_to_issue`, `new_potential_entry`, and `new_potential_bug_entry`. `new_active_feature_folder`, `collect_pr_context`, `validate_orchestration_artifacts`, and every other tool can never be waived. All comparisons are ordinal and case-sensitive.
 
+A lifecycle record moved to `docs/features/potential/promoted/` satisfies the `potential_record` path rule, because the rule checks only the `docs/features/potential/` prefix and the `.md` suffix and does not check that the file exists.
+
 Fail-closed behavior: any adoption error waives nothing, so each missing receipt is still reported as `Checkpoint missing successful MCP receipt: <tool>.`. Adoption errors are placed after the receipt-loop errors and before the `local_execution_overrides` errors. The waiver affects only receipt presence: the declared `required_mcp_tools` equality check with the routing matrix is unchanged, so a checkpoint must still declare every route tool it waives.
 
 ## Enforcement

package/resources/claude-customizations/.claude/rules/parallel-orchestration.md

@@ -87,13 +87,13 @@ When `require_complete` is not passed, invariants 20 and 21 contribute zero erro
 
 ## Invariants (parallel planner checkpoint)
 
-Enforced by `validate_parallel_planner_state_text(text, *, require_ready_for_execution=False)` in `scripts/dev_tools/validate_parallel_planner_state.py`. P1 through P4 are enforced unconditionally; P6 through P9 are enforced only under `require_ready_for_execution`.
+Enforced by `validate_parallel_planner_state_text(text, *, require_ready_for_execution=False)` in `scripts/dev_tools/validate_parallel_planner_state.py`. P1 through P4 are enforced unconditionally; P6 through P10 are ready-gate invariants, enforced only under `require_ready_for_execution`.
 
 - **P1 — Required keys.** The checkpoint must carry `objective`, `parallel_slug`, `parallel_manifest_path`, `mode`, `max_concurrency`, `items`, `cohorts`, `conflict_edges`, `recolor_generation`, `completed_steps`, `next_step`, and `last_updated`. One error is emitted per missing key. `kickoff_prompt_path` is optional outside the ready gate.
 
 - **P2 — Route-consistent identity.** `parallel_slug` and `parallel_manifest_path` must be non-empty strings; `mode` and `max_concurrency` satisfy orchestrator invariants 3 and 4.
 
-- **P3 — Item shape.** Each `items[]` entry must carry `issue_num`, `feature_folder`, `kind`, `state`, `blast_radius`, `preparation_status`, `research_path`, `plan_path`, and `preflight_status`. `issue_num` must be a positive integer unique across items; `kind` must be in `{feature, bug}`; `state` must be in the item-state enum; `blast_radius` must satisfy orchestrator invariant 9; `complexity_band`, when present, must be in `{C1, C2, C3, C4}`. The prohibited-key rejections of orchestrator invariants 10 and 11 apply.
+- **P3 — Item shape.** Each `items[]` entry must carry `issue_num`, `feature_folder`, `kind`, `state`, `blast_radius`, `preparation_status`, `research_path`, `plan_path`, and `preflight_status`. `issue_num` must be a positive integer unique across items; `kind` must be in `{feature, bug}`; `state` must be in the item-state enum; `blast_radius` must satisfy orchestrator invariant 9; `complexity_band` is optional outside the ready gate (P10 requires it under `require_ready_for_execution`) and, when present, must be in `{C1, C2, C3, C4}`. The prohibited-key rejections of orchestrator invariants 10 and 11 apply.
 
 - **P4 — Cohort and edge shape.** `cohorts[]`, `conflict_edges[]`, and `recolor_generation` satisfy orchestrator invariants 12 through 15.
 
@@ -107,7 +107,9 @@ Enforced by `validate_parallel_planner_state_text(text, *, require_ready_for_exe
 
 - **P9 — Ready gate, kickoff path.** Under `require_ready_for_execution`, `kickoff_prompt_path` must be exactly `artifacts/orchestration/parallel-kickoff-<parallel_slug>.md`.
 
-The planner checkpoint carries no `epic_worthiness` analogue and no `NON_EPIC_RECOMMENDED` branch; the parallel surface has no worthiness verdict, and scale assessment happens before parallel planning is invoked. When `require_ready_for_execution` is not passed, P6 through P9 contribute zero errors.
+- **P10 — Ready gate, routing record.** Under `require_ready_for_execution`, each object-shaped item must carry `complexity_band` in `{C1, C2, C3, C4}`; a `complexity_assessment` object `{band, floor, signals_present, rationale, assessed_at}` whose `floor` equals `compute_complexity_floor(signals_present)`, whose `band` is at or above `floor` and equals `complexity_band`, and whose `rationale` and `assessed_at` are non-empty strings; and a Claude `model_routing_receipt` object `{agent, phase, complexity_band, fable_policy, table_model, clamped_from, model}` with `agent == 'orchestrator'`, `complexity_band` equal to the item's band, `fable_policy` in `{disabled, available, preferred}`, and `model` equal to `resolve_delegation_model('orchestrator', complexity_band, fable_policy)['model']`, including the disabled-mode clamp invariants. The checks run per item in this order: (1) the band enum, reported as `None` when absent; (2) the assessment object, skipping checks 3 through 5 when it fails; (3) the assessment entry checks of `_validate_complexity_assessments`, prefix-rewritten to `<item> complexity_assessment`; (4) `assessed_at`; (5) assessment band equals item band; (6) the receipt object, skipping checks 7 through 10 when it fails; (7) the receipt entry checks of `_validate_model_routing_receipts`, prefix-rewritten to `<item> model_routing_receipt`; (8) `agent`; (9) receipt band equals item band; (10) the `fable_policy` enum. Checks 5 and 9 are reported whenever the two values differ, including when check 1 failed. Each item's P10 errors follow that item's P7 errors.
+
+The planner checkpoint carries no `epic_worthiness` analogue and no `NON_EPIC_RECOMMENDED` branch; the parallel surface has no worthiness verdict, and scale assessment happens before parallel planning is invoked. When `require_ready_for_execution` is not passed, P6 through P10 contribute zero errors.
 
 ## Invariants (parallel run manifest)
 
@@ -380,6 +382,44 @@ admits.
 Enforcement of this rejection is prose plus validator logic, exactly as for the three shapes above.
 No JSON Schema is authored, imported, or read for it, and `config/blast-radius.json` gains no key.
 
+### File-shape recognition (issue #797)
+
+The classifier accepts a wildcard-free token that carries a separator only when its final component
+names a file. After any `:<line>` suffix is stripped, the final component names a file when either
+condition holds:
+
+1. **Dotted file name.** The component has a non-empty stem before its last dot, and the text after
+   that dot, lower-cased, fully matches the pattern
+   `[a-z][a-z0-9]*`
+   (an ASCII letter followed by ASCII letters or digits).
+2. **Known file name.** The component is an exact, ordinal member of the closed known-name set:
+   `Dockerfile`, `Makefile`, `LICENSE`, `CODEOWNERS`, `NOTICE`, `.gitignore`, `.gitattributes`,
+   `.gitkeep`, `.gitmodules`, `.vscodeignore`, `.npmignore`, `.npmrc`, `.nvmrc`, `.editorconfig`,
+   `.prettierrc`, `.prettierignore`, `.eslintignore`, `.shellcheckrc`.
+
+This rule replaces the former extension allowlist, which dropped files a plan writes with an
+unlisted extension (`.bats`, `.cjs`, `.out`), every dotfile, and every extensionless file name. The
+same predicate decides the wildcard branch: a wildcard token outside the known top-level segments is
+accepted only when its final component names a file by this rule.
+
+Directory-shaped tokens remain rejected (issue #489). A final component with no dot, a trailing
+slash, a dot-directory such as `.claude` or `.git` that is not in the known-name set, a digit-led
+tail such as `v1.2.0`, and a trailing dot all fail the predicate.
+
+**Accepted residuals (fail-closed direction).** Three token shapes that do not name a file are
+accepted by this rule: a dotted directory cited without a trailing slash, such as the C#-style
+`src/<Product>.Domain`; host-qualified tokens such as `example.com/page.html` or `owner/repo.git`;
+and refs whose final segment has a letter-led dotted tail. Each produces at most an extra contention
+edge, which serializes work. A missed write schedules concurrent edits, which is the unsafe
+direction under this doctrine. In the self-hosted repository W4 removes the host-qualified cases; in
+destinations, where `path_roots` is empty, W2 and W3 bound them.
+
+**Parity.** The known-name set and the extension pattern are code constants in both runtimes
+(`scripts/dev_tools/_blast_radius_token_shapes.py` and
+`.claude/lib/blast-radius/BlastRadiusTokenShape.psm1`), not configuration keys, so neither copy of
+`config/blast-radius.json` changes. A Pester test reads the Python source and pins the PowerShell
+known-name set and extension pattern equal to it.
+
 ### Module-map granularity criterion
 
 Issue #472 removed the location-bucket modules `docs` and `tests` because a bucket keyed on where a
@@ -525,6 +565,11 @@ Write-intent extraction can drop a genuine write in these cases:
 5. a new top-level directory not yet in `path_roots` (W4);
 6. a genuine file whose stem is in the placeholder set (W6).
 
+The file-shape classifier, which runs before write-intent extraction, drops one further case: a
+genuine file cited only as a separator-free bare file name is not recorded, because only
+repository-relative paths and configured root surfaces are accepted (issue #797). The planner
+cites the repository-relative path or appends it to the declared radius.
+
 Three mitigations bound these cases:
 
 1. **The planner remains obliged to enumerate a genuine write explicitly.** When an item's plan will
@@ -635,10 +680,10 @@ shipped surface or a derived module.
 ## Enforcement
 
 - `scripts/dev_tools/validate_parallel_orchestrator_state.py`, with the helper modules `scripts/dev_tools/_parallel_state_common.py`, `scripts/dev_tools/_parallel_state_structures.py`, and `scripts/dev_tools/_parallel_state_records.py`, appends one error per violated orchestrator invariant. The completion-gate invariants 20 and 21 run only when the caller passes `require_complete=True`.
-- `scripts/dev_tools/validate_parallel_planner_state.py` appends one error per violated planner invariant. The ready-gate invariants P6 through P9 run only when the caller passes `require_ready_for_execution=True`.
+- `scripts/dev_tools/validate_parallel_planner_state.py`, with the helper module `scripts/dev_tools/_parallel_planner_state_routing.py` for invariant P10, appends one error per violated planner invariant. The ready-gate invariants P6 through P10 run only when the caller passes `require_ready_for_execution=True`.
 - `scripts/dev_tools/parallel_manifest_contract.py` appends one error per violated manifest invariant and exposes the default-resolving accessors. Manifest validation is a library call, not an MCP artifact type.
 - `scripts/dev_tools/validate_orchestration_artifacts.py` registers the CLI subparsers `parallel-orchestrator-state` (with `--require-complete`) and `parallel-planner-state` (with `--require-ready-for-execution`). An unknown artifact type continues to fail with `Unsupported artifact type: {type}`.
-- The TypeScript parity port at `extensions/drm-copilot/src/lib/validate/parallel-state-shared.ts`, `parallel-state-structures.ts`, `parallel-state-records.ts`, `parallel-orchestrator-state-core.ts`, and `parallel-planner-state-core.ts` reproduces the same invariants and is dispatched from `extensions/drm-copilot/src/lib/validate/orchestration-artifacts.ts` for both new `artifact_type` values. Verified scope: 96 of 96 error strings matched across 43 constructed documents, for JSON-representable values that round-trip through both runtimes' native types. Three divergence classes are known outside that verified scope: (1) **`pythonRepr` quote selection** — `parallel-state-shared.ts:112-132` always single-quotes, while Python's `repr` switches to double quotes when the value contains a single quote (recorded repo-wide at `docs/features/potential/2026-08-07-python-repr-quote-selection-divergence.md`); (2) **integral floats** — `JSON.parse` erases Python's `int`/`float` distinction, so an integral float value produces a different Python-side error count than the TypeScript side; (3) **boolean/integer equality** — `parallel-state-structures.ts:228` uses `===`, so a boolean value is not selected the way Python's `True == 1` equality selects it, producing differing error counts.
+- The TypeScript parity port at `extensions/drm-copilot/src/lib/validate/parallel-state-shared.ts`, `parallel-state-structures.ts`, `parallel-state-records.ts`, `parallel-orchestrator-state-core.ts`, and `parallel-planner-state-core.ts` reproduces the same invariants and is dispatched from `extensions/drm-copilot/src/lib/validate/orchestration-artifacts.ts` for both new `artifact_type` values. Verified scope: 96 of 96 error strings matched across 43 constructed documents, for JSON-representable values that round-trip through both runtimes' native types. Three divergence classes are known outside that verified scope: (1) **`pythonRepr` quote selection** — `parallel-state-shared.ts:112-132` always single-quotes, while Python's `repr` switches to double quotes when the value contains a single quote (recorded repo-wide at `docs/features/potential/2026-08-07-python-repr-quote-selection-divergence.md`); (2) **integral floats** — `JSON.parse` erases Python's `int`/`float` distinction, so an integral float value produces a different Python-side error count than the TypeScript side; (3) **boolean/integer equality** — `parallel-state-structures.ts:228` uses `===`, so a boolean value is not selected the way Python's `True == 1` equality selects it, producing differing error counts. For ready-gate invariant P10, `extensions/drm-copilot/src/lib/validate/parallel-planner-state-routing.ts` enforces the P10 structural subset (the band enums, the assessment and receipt object checks, `signals_present` shape, `band >= floor` ordering, non-empty `rationale` and `assessed_at`, the band-equality cross-checks, `agent`, and the `fable_policy` enum) with byte-identical error strings; the Python validator is authoritative for floor equality, resolved-model equality, and the disabled clamp, which the TypeScript port does not check.
 - Enforcement is therefore Python validator logic, plus the TypeScript parity port, plus this prose file. It is NEVER an imported JSON Schema. No schema file is read at validation time.
 - The `parallel` route entry lives in `config/orchestration-routing.json` with `requires_pr_gate: false` (there is no run-level pull request to gate; each child's own route checkpoint enforces its per-item pull-request gate) and is mirrored byte-for-byte in `extensions/drm-copilot/resources/config/orchestration-routing.json`.
 - The `PreToolUse` merge gate `.claude/hooks/enforce-epic-merge-gate.ps1` carries a parallel allow-branch that authorizes a per-item `gh pr merge --merge` from the parallel-orchestrator checkpoint when `route_id == "parallel"`, the target item's `merge_status == "ci_green"`, and the command's PR number matches that item's `pr_number`; any other case fails closed with `EPIC_MERGE_GATE_BLOCKED`.

package/resources/claude-customizations/.claude/rules/plan-acceptance-gates.md

@@ -7,14 +7,14 @@ paths:
   - "docs/features/**/plan.*.md"
   - "docs/features/**/remediation-plan.*.md"
   - ".claude/skills/atomic-plan-contract/SKILL.md"
-description: Acceptance-gate rules G1 through G6 applied to the shell commands an atomic plan states as acceptance conditions.
+description: Acceptance-gate rules G1 through G13 for atomic plans. G1 through G9 judge the shell commands a plan states as acceptance conditions; the document-level rules G10 through G13 report a SCRATCH definition that is not namespaced by issue number, a line-number citation, a commit-SHA citation, and a plan above the size guideline without a size justification.
 ---
 
-# Atomic-Plan Acceptance Gates (G1 through G6)
+# Atomic-Plan Acceptance Gates (G1 through G13)
 
-This rule governs the acceptance-gate rules the plan validator applies to the shell commands an atomic plan states as acceptance conditions. It exists because a plan can state an acceptance condition that cannot fail: a coverage argument that collects no data, or a search for a literal that returns zero matches whatever the executor does. Such a condition reads as a verification step and gates nothing (issue #486).
+This rule governs the acceptance-gate rules the plan validator applies to an atomic plan: G1 through G9 judge the shell commands the plan states as acceptance conditions, and G10 through G13 judge the whole plan document. It exists because a plan can state an acceptance condition that cannot fail: a coverage argument that collects no data, or a search for a literal that returns zero matches whatever the executor does. Such a condition reads as a verification step and gates nothing (issue #486).
 
-The rules are enforced by `scripts/dev_tools/plan_gate_discrimination.py` and by the TypeScript parity port at `extensions/drm-copilot/src/lib/validate/plan-gate-discrimination.ts` with its shared-predicate module `plan-gate-rules.ts`, both fed by the command extractor (`scripts/dev_tools/plan_gate_commands.py` and `extensions/drm-copilot/src/lib/validate/plan-gate-commands.ts`). Enforcement is validator logic plus this prose file. No JSON Schema is authored, imported, or read.
+The rules are enforced by `scripts/dev_tools/plan_gate_discrimination.py` and by the TypeScript parity port at `extensions/drm-copilot/src/lib/validate/plan-gate-discrimination.ts` with its shared-predicate module `plan-gate-rules.ts`. G1 through G9 are fed by the command extractor (`scripts/dev_tools/plan_gate_commands.py` and `extensions/drm-copilot/src/lib/validate/plan-gate-commands.ts`); G10 reads the whole document through `scripts/dev_tools/plan_gate_scratch.py` and `extensions/drm-copilot/src/lib/validate/plan-gate-scratch.ts`, and G11 through G13 read it through `scripts/dev_tools/plan_gate_document.py` and `extensions/drm-copilot/src/lib/validate/plan-gate-document.ts`. Enforcement is validator logic plus this prose file. No JSON Schema is authored, imported, or read.
 
 ## Scope of Invocation — no grandfathering or exemption mechanism
 
@@ -26,7 +26,7 @@ The consequence is that adding a rule to this set is cheap in migration cost and
 
 ## Rule Table
 
-Every finding string begins with the square-bracketed `P#-T#` identifier of the task the command is attributed to, and renders the offending value or literal between backticks.
+Every finding string begins with the square-bracketed `P#-T#` identifier of the task the command is attributed to, and renders the offending value or literal between backticks. The G10 exception: a G10 finding begins with `Line N: ` instead, because a SCRATCH definition sits outside any task window; the prefix matches the structural-error prefix in the same error channel, and the offending logical line is still rendered between backticks. G11, G12, and G13 findings use the same `Line N: ` prefix for the same reason; G13 always reports `Line 1: ` because it judges the document as a whole.
 
 | Rule | Condition | Shipped severity |
 | --- | --- | --- |
@@ -40,14 +40,18 @@ Every finding string begins with the square-bracketed `P#-T#` identifier of the
 | **G8** | A `git diff` invocation carrying no non-flag ref operand and neither `--cached` nor `--staged`. It compares the worktree against the index, which is ambient state: the comparison passes vacuously once the change is committed. Exonerated when the attributed task text carries a second `git diff` or a `git status` span. | **Warning** |
 | **G8b** | A `git diff` invocation carrying a non-flag ref operand together with `--name-only` or `--name-status`, whose attributed task text carries neither a `git add` span nor a `git status --porcelain` span. A name-listing diff enumerates tracked changes only, so a path the plan creates is invisible to it. | **Warning** |
 | **G9** | A command carrying a `--cov` token, carrying no token beginning `--cov-report=term` and no token beginning `--cov-fail-under`, whose project `addopts` value also carries no `--cov-report=term`. No coverage table is printed, so a coverage number the acceptance condition demands can never be read. | **Warning** |
+| **G10** | An unfenced logical line of the plan document (a physical line plus its indented continuation lines) that matches the SCRATCH definition predicate, and whose text after the first definition match carries neither an `issue-<issue-num>` nor an `issue-<digits>` namespace. One finding per logical line, reported against its first physical line. | **Blocking** |
+| **G11** | A line-number citation in unfenced text, in any of three forms: the prose form `\b[Ll]ines?[ \t]+[0-9]+` evaluated with inline code spans masked; the path form `[A-Za-z0-9_./-]+\.[A-Za-z][A-Za-z0-9]{0,5}:[0-9]+` evaluated including inline code, skipped when the enclosing whitespace-delimited token contains `://`; and the anchor form `#L[0-9]+`. A line position moves whenever `main` moves. One finding per match. | **Blocking** |
+| **G12** | A commit-SHA citation in unfenced text, including inline code: a bounded run `\b[0-9a-f]{7,40}\b` that holds at least one digit and at least one letter, is not preceded by `-`, `_`, or `.`, and is not followed by `-` or `_`. The adjacency conditions are checked in code, not by lookbehind. One finding per match. | **Blocking** |
+| **G13** | A plan whose unfenced canonical task lines exceed `PLAN_TASK_GUIDELINE` (40) or whose physical lines exceed `PLAN_LINE_GUIDELINE` (400), with no `## Size Justification` heading followed by at least one non-blank, non-heading line before the next heading of level one or two. One finding per document. | **Blocking** |
 
-G1 through G9 are the complete shipped set. G1 through G6 were added by issue #486 and G7 through G9 by issue #519; the parenthetical in this file's title names the original set only.
+G1 through G13 are the complete shipped set. G1 through G6 were added by issue #486, G7 through G9 by issue #519, G10 by issue #932, and G11 through G13 by issue #964.
 
 G1 through G4 form a cascade over each `--cov` value: the value is decided once, so a value G1 rejects is never additionally reported by G2 or G3. G4 is evaluated independently of the cascade because the ambiguous form is a defect whatever the value resolves to. G6 is evaluated before G5, because cross-line presence falsifies G5's tree-absence claim.
 
 G8b is a distinct rule from G8 and not a sub-case of it: G8 reports a diff with no ref operand, G8b reports one that has a ref operand but cannot observe an untracked path. A single invocation can satisfy only one of the two, because the presence of a ref operand decides between them.
 
-G1 and G4 are context-free and run on every invocation. G2, G3, G5, and G6 require a repository seam; with no context supplied they do not run, and the Blocking list is byte-identical to the pre-change output for the same text. G7, G8, and G8b are likewise context-free and run on every invocation. G9 requires the repository seam, because it reads the project `addopts` value through it, so with no context supplied G9 does not run. All four of the rules added by issue #519 ship in the Warning channel, so none of them can alter the Blocking list at all.
+G1 and G4 are context-free and run on every invocation. G2, G3, G5, and G6 require a repository seam; with no context supplied they do not run. G7, G8, and G8b are likewise context-free and run on every invocation. G9 requires the repository seam, because it reads the project `addopts` value through it, so with no context supplied G9 does not run. All four of the rules added by issue #519 ship in the Warning channel, so none of them can alter the Blocking list at all. G10 is context-free and document-level: it reads the whole plan text, including the preamble and terms lists the command extractor drops, runs on every invocation, and can add Blocking findings without a context. G11, G12, and G13 are context-free and document-level in the same way, skip fenced code blocks with the command extractor's fence pattern, split physical lines on CR LF, LF, and CR only, use no lookbehind, and run after G10 on every invocation.
 
 ### Attribution window
 
@@ -136,6 +140,73 @@ The remaining 4 findings are true positives, and each is the exact defect the ru
 
 Counts, and every one of the 4 false positives named by plan path, task identifier, offending span, and the reason its acceptance condition is falsifiable: `docs/features/completed/2026-08-23-plan-acceptance-gates-miss-unobservable-and-ambient-state-gates-519/evidence/qa-gates/corpus-measurement.2026-08-24T00-00.md`.
 
+### G10 — ships as Blocking by operator-approved scope and the pre-declared rule
+
+G10 enforces the child-unique scratch location rule introduced by issue #900: a plan that uses scratch files points the `SCRATCH` token at `<session scratchpad>/issue-<issue-num>/`, so concurrent child runs in one session do not collide. Unlike G1 through G9, it judges document prose rather than task-attributed commands, because a SCRATCH definition is written in a plan preamble or terms list that the command extractor drops.
+
+The detection contract has two steps, and both patterns use no lookbehind so the Python and JavaScript dialects agree. Step 1 is the definition predicate; step 2 is the namespace that accepts the line when it appears in the text after the first definition match:
+
+```text
+(?:^|[^A-Za-z0-9_<>$/.-])`?SCRATCH`?(?:\*\*)?[ \t]*(?:means\b|:=|=|:|is (?:the|a|an)\b|resolves to\b|abbreviates\b|denotes\b|refers to\b|stands for\b)
+issue-(?:<issue-num>|[0-9]+)
+```
+
+Lines inside fenced code blocks are skipped, and a logical line is reported once however many definition matches it contains.
+
+A continuation line is non-blank, begins with whitespace, and is not a fence line, so a heading or task line written at column 0 ends the logical line, and an indented heading or task line is absorbed into it. Both runtimes split the document into physical lines on the CR LF, LF, and CR terminators only; a form feed, a vertical tab, the information separators, NEL, and the Unicode line and paragraph separators do not end a physical line. Both runtimes share one explicit whitespace class for the blank-line test, the continuation test, and whitespace normalization, declared once per runtime as `PLAN_WHITESPACE_CLASS` in the command extractor module, with an identical pattern string in both: tab, line feed, vertical tab, form feed, carriage return, space, the Unicode space separators, and the Unicode line and paragraph separators. NEL, the information separators, and the byte-order mark are outside that class, so in both runtimes a line that begins with one of them ends the logical line, and the character is kept verbatim in the normalized text. G6 uses the same class for its single-line test, its sliding-window join, and the split of the search literal into words, so a tracked file that contains NEL, an information separator, or the byte-order mark produces the same G6 result in both runtimes; the plan-quotation exoneration, which reads the plan text rather than a tracked file, keeps each runtime's native class. The fence test keeps the command extractor's fence pattern, whose leading whitespace is each runtime's native class, so a fence line that begins with NEL, an information separator, or the byte-order mark can be recognized differently by the two runtimes, for G1 through G9 as well as for G10.
+
+The severity was fixed by the same two-conjunct decision rule used for G5 through G9, written and committed before the measurement was taken: Blocking if and only if the total G10 finding count is greater than zero **and** the recorded false-positive count is zero; otherwise the measurement indicates Warning. The pre-declared false-positive definition is a flagged logical line that is not a SCRATCH definition, or that defines SCRATCH in the canonical issue-namespaced form.
+
+The measurement is recorded in `docs/features/archive/2026-10-15-plan-validator-accepts-bare-scratch-paths-932/evidence/qa-gates/g10-corpus-measurement.2026-10-16T01-21.md`. It scanned 493 plan and remediation-plan files under `docs/` at the merge base and produced 17 findings, all 17 true positives and 0 false positives, so both conjuncts hold and the rule yields Blocking.
+
+G10 also ships Blocking by operator-approved scope for issue #932. The measurement alone is a weaker basis than the G7 through G9 precedent, because the research for issue #932 observed the committed plan corpus, including the definition forms the predicate targets, before the measurement was taken. The severity is a single constant in each runtime (`G10_SEVERITY`), and a parity test asserts the two constants agree.
+
+### Known false-negative classes — G10
+
+G10 does not report the following, and each is a stated limitation rather than a deferred promise:
+
+- **Wrong issue number.** A namespaced definition whose issue number differs from the plan's own issue is accepted, because the predicate checks the namespace shape, not its value.
+- **`SCRATCHPAD`-family tokens.** `SCRATCHPAD`, `<SCRATCHPAD>`, and `<SCRATCH>` tokens, and root paths written under them, are excluded by the preceding-character class and the token boundary.
+- **Definition by reference.** A plan that defines SCRATCH by pointing at another plan's definition carries no definition text for the predicate to match.
+- **Fenced definitions.** A definition placed inside a fenced code block is skipped, which is also what lets plans and specifications quote rejected forms as examples.
+- **Any issue token after the definition.** A logical line is accepted when an `issue-<digits>` or `issue-<issue-num>` token appears anywhere in its text after the first definition match, including a cross-reference that is not the scratch location, such as `(see issue-900 for context)`. Step 2 checks the namespace shape anywhere in that text, not inside a path segment.
+
+One false-positive class is possible and recorded: the colon connector matches prose in which the word SCRATCH is directly followed by a colon that introduces something other than a definition, as in the line below. The measured corpus contains no instance.
+
+```text
+Each artifact names the token SCRATCH: it never records a host path.
+```
+
+### G11 — ships as Blocking by operator-approved scope
+
+G11 enforces the design-level plan contract introduced by issue #964: a plan anchors on symbols, headings, and test names, never on line positions, because a line position moves whenever `main` moves and every such citation becomes a preflight defect. The severity was set by operator-approved scope for issue #964, following the G10 precedent, and not by a pre-declared measurement. The severity is a single constant in each runtime (`G11_SEVERITY`), and a parity test asserts the two constants agree.
+
+The finding message is ``Line N: line-number citation `<match>` anchors on a position that moves when main moves; cite the symbol, heading, or test name instead.`` A G11 finding is a trivial preflight defect: the preflight executor replaces the citation in place and records the fix, so the Blocking channel does not cost a return to the planner.
+
+### G12 — ships as Blocking by operator-approved scope
+
+G12 enforces the same contract for commit identifiers: a commit SHA names a state that goes stale when `main` moves. The severity was set by operator-approved scope for issue #964. The digit-and-letter condition excludes decimal run and ruleset identifiers and all-letter words; the adjacency conditions exclude UUID segments and agent or worktree suffixes joined by `-` or `_`; and the bounded run excludes SHA-256 digests, because a 64-character run has no word boundary at 40 characters, so a digest literal can remain where it is the actual assertion. The severity is a single constant in each runtime (`G12_SEVERITY`), and a parity test asserts the two constants agree.
+
+The finding message is ``Line N: commit-SHA citation `<match>` names a commit that goes stale when main moves; cite the branch, ref name, or merge base derivation instead.``
+
+### G13 — ships as Blocking because its exoneration is author-controlled
+
+G13 reports a plan above 40 canonical task lines or 400 physical lines that carries no `## Size Justification` section with content. The guideline numbers were derived from the issue #962 item, whose specification maps to an estimated 35 to 45 design-level tasks in 300 to 400 lines. G13 ships Blocking because the author controls its exoneration: a plan that needs more states why in one paragraph, which costs less than a preflight round. A justification section that holds only blank lines or headings does not exonerate. The severity is a single constant in each runtime (`G13_SEVERITY`), and a parity test asserts the two constants agree.
+
+The finding message is ``Line 1: plan size `<T> tasks, <L> lines` exceeds the guideline of 40 tasks or 400 lines and carries no `## Size Justification` section; split the item or state why the size is necessary.``
+
+### Known false-positive classes — G11 and G12
+
+G11 and G12 do not suppress the following; each is a documented false-positive class rather than a deferred fix:
+
+- **G11, prose that refers to a line of command output.** A sentence such as "line 1 of the output" is reported, because the prose form cannot tell a file position from an output position.
+- **G11, a quoted validator message outside backticks.** A validator prefix such as `Line 5:` written as plain prose matches the prose form; the same text inside an inline code span is masked and not reported.
+- **G11, an inline code span opened with two or more backticks.** The mask pairs single backticks, so a span such as a doubled-backtick quotation of a finding message that itself contains backticks is masked only in part, and a line reference inside it can match the prose form.
+- **G11, a host and port written without a URL scheme.** A token such as `api.github.com:443` matches the path form, because only a token containing `://` is skipped and the path form is matched inside inline code spans as well as in prose; the same host and port written as a URL with a scheme, such as `https://api.github.com:443`, is not reported.
+- **G12, a hexadecimal identifier that is not a commit.** A run of seven or more hexadecimal characters with a digit and a letter that is not joined by `-` or `_` is reported. The measured instances are synthetic fixture identifiers written into test-scenario task text and git object identifiers that are not commits, such as blob hashes recorded as parity evidence; a bare hexadecimal color is the same class.
+
+The corpus measurement informed the false-positive class list and did not decide the channel. It is recorded in `docs/features/archive/2026-10-16-planning-process-churn-964/evidence/other/g11-g13-corpus-measurement.2026-10-16T23-46.md`. It scanned 615 committed plan and remediation-plan files under `docs/` and counted 13190 G11 findings in 350 files, 1681 G12 findings in 218 files, and 280 G13 findings. Those counts describe plans written before the rules existed; the validator runs only against the plan it is pointed at, so they do not enter any gate.
+
 ## The Write-Mode Register
 
 G7 reads a fixed register of six entries. Each entry is an argv predicate plus a set of observation markers matched case-sensitively as substrings of the owning task's attributed text. The register is data, not code, so the same six entries are transcribed into the TypeScript twin without porting behaviour.
@@ -239,19 +310,23 @@ The following are prohibited in gate messages:
 
 The reason is byte-identity across the two runtimes. Python's `repr` selects its quote character based on the value's contents, switching to double quotes when the value contains a single quote, while the TypeScript `pythonRepr` helper used elsewhere in this repository always single-quotes. A value carrying an apostrophe would therefore render differently in the two runtimes, and the parity requirement would fail on exactly the class of value a maintainer is most likely to encounter in a path or a prose literal. Backtick delimiting has no content-dependent behaviour and needs no helper.
 
-The prohibition is enforced by tests, not only by prose: a parity test asserts the Python gate module contains neither `!r` nor `repr(`, a companion test asserts no `pythonRepr(` call appears in any of the three TypeScript gate modules, and the parity fixture set includes an apostrophe-bearing `--cov` value and an apostrophe-bearing search literal whose expected strings are asserted identically in both runtimes.
+The prohibition is enforced by tests, not only by prose: a parity test asserts the Python gate module contains neither `!r` nor `repr(`, a companion test asserts no `pythonRepr(` call appears in any of the TypeScript gate modules, and the parity fixture set includes an apostrophe-bearing `--cov` value and an apostrophe-bearing search literal whose expected strings are asserted identically in both runtimes.
 
 ## Authoring Guidance for Plan Authors
 
 - Express coverage targets as importable dotted names (`--cov=scripts.dev_tools.module`), never as filesystem paths, and always with the `=` form.
 - Where an acceptance condition is a search, assert a short, single-line, non-interpolated token that the plan quotes verbatim.
 - Prefer a named test over a phrase search whenever a test can carry the assertion.
+- Cite a symbol, a heading, or a test name. Never cite a line number, a `path:line` locator, a `#L` anchor, or a commit SHA; name the branch, the ref, or the merge-base derivation instead (G11, G12).
+- Keep a plan within 40 tasks and 400 lines; a plan that needs more carries a non-empty `## Size Justification` section (G13).
 
 `.claude/skills/atomic-plan-contract/SKILL.md` carries the authoring-side statement of this guidance and cross-references this file.
 
 ## Enforcement
 
-- `scripts/dev_tools/plan_gate_commands.py` extracts task-attributed command candidates; `scripts/dev_tools/plan_gate_discrimination.py` evaluates G1 through G6 and returns the two severity channels.
+- `scripts/dev_tools/plan_gate_commands.py` extracts task-attributed command candidates; `scripts/dev_tools/plan_gate_discrimination.py` evaluates G1 through G9, calls `scripts/dev_tools/plan_gate_scratch.py` for G10 and `scripts/dev_tools/plan_gate_document.py` for G11 through G13, and returns the two severity channels.
 - `scripts/dev_tools/validate_orchestration_artifacts.py` routes the existing `plan` artifact type through the two-channel entry point, prints each Warning to stderr prefixed with `PLAN GATE WARNING: `, and derives its exit code from the error channel alone. No new flag, option, or artifact type is added.
 - The TypeScript parity port is dispatched from `extensions/drm-copilot/src/lib/validate/orchestration-artifacts.ts` for the existing `plan` artifact type. The MCP `validate_orchestration_artifacts` input-schema property-key set is unchanged; Warnings surface on an optional `warnings` field that is absent when there are none.
-- `.claude/hooks/validate-planner-output.ps1` is not modified by this rule and carries no part of its enforcement.
+- `scripts/dev_tools/plan_gate_scratch.py` evaluates G10, the document-level SCRATCH definition rule, and `evaluate_plan_gates` in `scripts/dev_tools/plan_gate_discrimination.py` calls it on every invocation, with or without a context. The TypeScript twin `extensions/drm-copilot/src/lib/validate/plan-gate-scratch.ts` is called the same way from `evaluatePlanGates`. Through the Python CLI a G10 finding is printed as an error and the process exits 1; through the MCP service call it causes the call to throw with the message included.
+- `scripts/dev_tools/plan_gate_document.py` evaluates G11, G12, and G13, and `evaluate_plan_gates` calls it on every invocation immediately after G10, with or without a context. The TypeScript twin `extensions/drm-copilot/src/lib/validate/plan-gate-document.ts` is called the same way from `evaluatePlanGates`. The MCP validator applies these rules only after the extension release that carries them is installed; until then, branch-current validation runs through `poetry run python -m scripts.dev_tools.validate_orchestration_artifacts plan <path>`.
+- `.claude/hooks/validate-planner-output.ps1` carries no part of G1 through G13 enforcement. It separately rejects a line-reference locator in a `CITATION:` entry of the planner internal-review record, which is consistent with G11 but is a hook rule, not a validator rule.

package/resources/claude-customizations/.claude/rules/quality-tiers.md

@@ -6,19 +6,21 @@ description: Module rigor tier system and uniform coverage thresholds.
 
 # Module Rigor Tiers
 
-This rule defines the T1–T4 module rigor tier system used by all CI gates in this repository. The tier definitions and gate matrix in this document are the tier system's source of truth; the file `quality-tiers.yml` at the repository root maps every project to a tier. Adding a project without a tier classification fails CI.
+Applicability: this rule applies only when `quality-tiers.yml` exists at the repository root, which indicates that the repository has adopted module rigor tiers. When that file is absent, there is no tier classification requirement, no `tier-classification` CI stage, and no tier-dependent gate (the escape-hatch limits, property-test density, mutation score, contract-bump rule, determinism retry rate, golden tests, and E2E suite scope in the Tier-dependent table below), and the absence of `quality-tiers.yml` is not a defect. The coverage defaults listed under Uniform across all tiers do not depend on tier adoption; their precedence is stated in that section.
+
+When `quality-tiers.yml` exists, this rule defines the T1–T4 module rigor tier system used by the repository's CI gates, and the tier definitions and gate matrix in this document are the tier system's source of truth.
 
 ## Tiers
 
-- **T1 — Critical.** Behavior bugs cause silent data loss, model drift, or security holes. Examples (No-COM architecture): classifier engines (SpamBayes, Triage), ToDo ID allocator and hierarchy operations, Graph extended-properties adapter, auth/token handling, host-agnostic command bus.
-- **T2 — Core.** Bugs cause feature regressions but not data loss. Examples: `TaskMaster.Domain`, `TaskMaster.Application`, mail-item DTOs, settings store abstraction, schema definitions.
-- **T3 — Adapters & UI.** Glue around APIs the team does not own. Examples: Outlook task pane UI, Office.js wrappers, Microsoft Graph SDK wrappers, persistence I/O.
+- **T1 — Critical.** Behavior bugs cause silent data loss, model drift, or security holes. Examples: classifier and scoring engines, identifier allocators and hierarchy operations, adapters that write to an external system of record, authentication and token handling, command dispatch.
+- **T2 — Core.** Bugs cause feature regressions but not data loss. Examples: domain and application layers, data-transfer objects, settings store abstractions, schema definitions.
+- **T3 — Adapters & UI.** Glue around APIs the team does not own. Examples: user-interface surfaces, host-platform API wrappers, third-party API and SDK wrappers, persistence I/O.
 - **T4 — Scaffolding.** Examples: DI wiring, bootstrap, build scripts, dev tooling, generated code, manifests.
 
 ## Source of Truth
 
-- `quality-tiers.yml` at repo root maps every project to one tier.
-- The CI pipeline's `tier-classification` stage validates that every project entry has a tier and that no unclassified project exists. Adding a project without a tier classification fails CI.
+- When `quality-tiers.yml` exists at the repository root, it maps every project to one tier.
+- In a repository that runs a `tier-classification` CI stage, that stage validates that every project entry has a tier and that no unclassified project exists, and it fails CI for an unclassified project.
 
 ## Uniform-vs-Tier-Dependent Gate Matrix
 
@@ -26,6 +28,8 @@ Per Authoritative Decision #2, line and branch coverage thresholds are uniform a
 
 ### Uniform across all tiers (T1–T4)
 
+Threshold precedence: when the repository's root `CLAUDE.md` states line or branch coverage thresholds, those thresholds govern. The 85% line and 75% branch figures are defaults that apply only when the root `CLAUDE.md` states none. This precedence applies to every restatement of these figures in other rule files, agents, and skills. Each metric falls back independently: when the root `CLAUDE.md` states only a line threshold or only a branch threshold, the stated threshold governs that metric and the default governs the other.
+
 - Format check: 100% pass.
 - Lint errors: 0.
 - Type errors: 0.
@@ -48,4 +52,4 @@ Per Authoritative Decision #2, line and branch coverage thresholds are uniform a
 
 ## Rationale (uniform coverage thresholds)
 
-High test coverage is a fundamental quality-control design choice that enables autonomous agentic development and trust in the work product. For that reason, line coverage >= 85% applies uniformly across T1–T4 to every coverage language, and branch coverage >= 75% applies uniformly across T1–T4 to every language whose coverage tooling measures branch coverage; tier-specific lower coverage floors are not used in this repository. The branch threshold is not applied to PowerShell or bash because Pester and kcov do not measure branch coverage. That exemption is a capability limit on an unevaluable threshold, not a licence to exclude files from measurement: PowerShell and bash production files remain in the coverage denominator under the Coverage Exclusion Policy in `.claude/rules/general-unit-test.md`.
+High test coverage is a fundamental quality-control design choice that enables autonomous agentic development and trust in the work product. For that reason, line coverage >= 85% applies uniformly across T1–T4 to every coverage language, and branch coverage >= 75% applies uniformly across T1–T4 to every language whose coverage tooling measures branch coverage; tier-specific lower coverage floors are not used. These figures are defaults under the threshold precedence stated above: a root `CLAUDE.md` that states coverage thresholds overrides them. Each metric falls back independently, so a root `CLAUDE.md` that states only one of the two thresholds overrides only that one. The branch threshold is not applied to PowerShell or bash because Pester and kcov do not measure branch coverage. That exemption is a capability limit on an unevaluable threshold, not a licence to exclude files from measurement: PowerShell and bash production files remain in the coverage denominator under the Coverage Exclusion Policy in `.claude/rules/general-unit-test.md`.

package/resources/claude-customizations/.claude/rules/shell.md

@@ -45,11 +45,12 @@ single pass. Do not substitute the VS Code task wrappers for the native command
 
 ## Discovery Contract
 
-- Search roots: `tools/`, `scripts/`, `.claude/lib/bash/`, and `.claude/skills/`, relative to the
-  current working directory; a missing root is silently skipped. The `.claude/lib/bash/` root carries
-  the destination-portable bash library published by push-down, and the `.claude/skills/` root carries
-  scripts bundled inside a skill folder, so those scripts are held to the same format, lint, test, and
-  coverage standards as `tools/` and `scripts/`.
+- Search roots: `tools/`, `scripts/`, `.claude/lib/bash/`, `.claude/skills/`, and `.codex/`, relative
+  to the current working directory; a missing root is silently skipped. The `.claude/lib/bash/` root
+  carries the destination-portable bash library published by push-down, the `.claude/skills/` root
+  carries scripts bundled inside a skill folder, and the `.codex/` root carries the Codex runtime
+  scripts (for example `.codex/codex-web-setup.sh`), so those scripts are held to the same format,
+  lint, test, and coverage standards as `tools/` and `scripts/`.
 - A file is a shell script when its suffix (lowercased) is `.sh` or its first line is a
   shebang whose resolved interpreter is `bash` or `sh` (including `env` and `env -S`/`-flag`
   forms; the shebang is lowercased before parsing, so `#!/usr/bin/env BASH` qualifies).
@@ -63,9 +64,10 @@ single pass. Do not substitute the VS Code task wrappers for the native command
 - Coverage is measured with kcov, which emits a single merged Cobertura report `cov.xml` under
   `artifacts/pester/kcov` (or `SHELL_QC_KCOV_OUT_DIR`). The run prints
   `Bash coverage (lines): NN.N%`.
-- The kcov include pattern covers all four discovery roots — `tools/`, `scripts/`,
-  `.claude/lib/bash/`, and `.claude/skills/` — so the Claude bash library and skill-bundled scripts are
-  measured, not merely discovered. The `tests/` tree remains excluded.
+- The kcov include pattern covers all five discovery roots — `tools/`, `scripts/`,
+  `.claude/lib/bash/`, `.claude/skills/`, and `.codex/` — so the Claude bash library, skill-bundled
+  scripts, and Codex runtime scripts are measured, not merely discovered. The `tests/` tree remains
+  excluded.
 - kcov reports **line coverage only**. The uniform line-coverage threshold (>= 85% per
   `.claude/rules/quality-tiers.md`) applies. Branch coverage is not measurable by kcov for
   bash; there is no bash branch-coverage gate.

package/resources/claude-customizations/.claude/rules/typescript.md

@@ -54,7 +54,7 @@ Run the toolchain in order: format → lint → type-check → test. Restart fro
 
 ## Architecture Boundaries
 
-Layer rules and the No-COM architecture assertions are defined in `.claude/rules/architecture-boundaries.md`. The TypeScript enforcement tool is `dependency-cruiser` with configuration file `.dependency-cruiser.cjs`.
+Layer rules and the host-neutral architecture assertions are defined in `.claude/rules/architecture-boundaries.md` under the heading "Host-Neutral Architecture Rules (enforceable assertions)". The TypeScript enforcement tool is `dependency-cruiser` with configuration file `.dependency-cruiser.cjs`.
 
 ## Property-Based and Mutation Testing
 

package/resources/claude-customizations/.claude/settings.json

@@ -5,8 +5,11 @@
       "Bash(git *)",
       "Bash(poetry run *)",
       "Bash(pwsh *)",
+      "Bash(bash .claude/lib/bash/abandon-parallel-item.sh*)",
       "Bash(bash .claude/lib/bash/compute-cohorts.sh*)",
       "Bash(bash .claude/lib/bash/compute-concurrency-batches.sh*)",
+      "Bash(bash .claude/lib/bash/mutate-parallel-run.sh*)",
+      "Bash(bash .claude/lib/bash/remove-parallel-item.sh*)",
       "Bash(bash .claude/lib/bash/validate-parallel-manifest.sh*)",
       "Read",
       "Edit(docs/**)",
@@ -211,10 +214,6 @@
       {
         "matcher": "atomic-planner|atomic-executor|feature-review|task-researcher|prd-feature|staged-review|epic-review|status-updater|python-typed-engineer|powershell-typed-engineer|csharp-typed-engineer|typescript-engineer|orchestrator|epic-orchestrator|epic-planner",
         "hooks": [
-          {
-            "type": "command",
-            "command": "pwsh -NoProfile -Command \"$input = $env:CLAUDE_HOOK_INPUT | ConvertFrom-Json; $output = $input.output; if (-not ($output -match '(plan-path|research-path|review-artifact|PREFLIGHT|evidence/)')) { Write-Error 'Subagent stopped without required completion artifact path'; exit 1 }; exit 0\""
-          },
           {
             "type": "command",
             "command": "pwsh -NoProfile -File .claude/hooks/validate-discovery-artifact-gate.ps1"

package/resources/claude-customizations/.claude/skills/acceptance-criteria-tracking/SKILL.md

@@ -88,7 +88,7 @@ During feature review (feature-audit phase):
 
 ### When Orchestrators Enforce AC Tracking
 
-Orchestrators do not directly check off AC items. Instead:
+Orchestrators do not directly check off AC items. The one exception is a CI-dependent criterion, which the item's own orchestrator run checks off at S9 as described in `### CI-Dependent Criteria` above. For every other criterion, orchestrators instead:
 
 1. Ensure delegated executors and reviewers reference this skill.
 2. After executor or reviewer completion, verify that AC source files reflect delivered work (spot-check; do not re-execute verification).