@danmoisan/drm-copilot-mcp 1.1.22 → 1.1.24

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

@@ -255,15 +255,30 @@ not a cryptographic or security control.
 
 Field checks 3 through 9 run in the fixed order `pr_url`, `issue_num`, `branch_name`, `authorized_by`, `authorized_at`, `basis`, `run_slug`, `session_id`; the first failure wins and the gate denies with `STANDALONE_MERGE_AUTHORIZATION_MALFORMED` naming that field.
 
+## Green-CI standalone merge (issue #997)
+
+A standalone run (neither an epic child nor a parallel item) merges its own pull request at S9 step 7 of `.claude/skills/orchestrate/SKILL.md` without an authorization record. The merge gate evaluates this green-CI condition after its parallel condition and before the `standalone_merge_authorizations` condition, and allows the merge only when all of the following hold:
+
+1. The command is a single structural `gh pr merge` naming an explicit pull request number, with no chain, wrapper, inline environment prefix, `-R` or `--repo`, `/pull/` URL selector, `--auto`, or `--admin`.
+2. Exactly one live worktree's per-feature checkpoint records that number, and no epic or parallel checkpoint records the number or that worktree's path.
+3. The per-feature checkpoint has `epic_mode` absent, `null`, or JSON `false`; carries no `parallel_mode: true` and no non-blank `parallel_slug`; records `step9_status` exactly `passed` and `ci_gate.conclusion` exactly `success`; records `pr_gate.pr_number` as a JSON integer equal to the command number (an authorization record does not substitute); records `ci_gate.head_sha` as a lowercase 40 or 64 character object id; and, when `pr_gate.head_sha` is present and not `null`, records it equal to `ci_gate.head_sha`.
+4. The live pull-request head from one bounded `gh pr view` call equals `ci_gate.head_sha`, and a `--match-head-commit` value, when present, equals the live head.
+
+`parallel_mode`, `parallel_slug`, and `pr_merge` are tolerated, unvalidated top-level checkpoint keys: no validator reads them. A parallel child records `parallel_mode: true` and `parallel_slug` at kickoff, and a standalone run records `pr_merge: { merge_commit_sha, target_branch, merged_at }` only after its merge is confirmed.
+
+Honest disclosure: the parallel exclusion is best-effort. The `Parallel mode: true` marker lives in the delegation prompt and is not present in a Bash `PreToolUse` payload, so a parallel child whose number and worktree path the parallel checkpoint has not yet recorded, and which omits the `parallel_mode` key, is not excluded by the hook. Like the authorization record above, the green-CI condition is a policy-level control, not a security control. A push after the live-head lookup can also change the head unless the command passes `--match-head-commit`, which the hook does not require.
+
 ## Issue-Adoption Scope and Backward Compatibility
 
 These invariants apply only when a checkpoint contains a top-level `issue_adoption` key. The key records that the orchestration adopted a GitHub issue that already existed before orchestration started (transferred, filed by hand, or created by epic decomposition), so the issue was never created through `potential_to_issue`. The key is presence-gated: a checkpoint without it validates byte-identically to before and produces no new errors. It is evaluated only by the routing-contract completion check (`validate_routing_contract` and its TypeScript and PowerShell ports). It is not a member of `REQUIRED_STATE_KEYS`, it is not read by plain (non-completion) validation, and it is not read by the PR-creation-readiness gate. No JSON Schema file is authored, imported, or read for it.
 
 Honest disclosure: the validators perform no network I/O. They cannot confirm that the issue exists, so `evidence` and `verified_via` are an auditable declaration of the read-only verification the orchestrator performed, not proof of it. This matches the `standalone_merge_authorizations` precedent above: the record is a policy-level declaration, not a security control.
 
+The `feature_folder_record` is likewise declaration-only in every validator: the Python, TypeScript, and PowerShell validators perform no file-system or git access, so the validator checks, the MCP `validate_orchestration_artifacts` path, the Python CLI, and Codex gates cannot confirm that the folder exists or is committed. The folder is probed only under the Claude `SubagentStop` hook `.claude/hooks/validate-orchestrator-output.ps1`, through `.claude/hooks/validate-orchestrator-output-feature-folder.ps1`: when an `orchestrator-state` checkpoint waives `new_active_feature_folder` and passes the routing contract, the hook re-checks the checkpoint `feature-folder` against the path pattern and runs `git -C <worktree root> cat-file -t HEAD:<feature-folder>`. It allows only exit code 0 with the output `tree`; any other outcome blocks with `ROUTING_CONTRACT_BLOCKED: Checkpoint feature-folder is not committed in HEAD: <feature-folder>.`, which the subagent can repair. The probe proves only that `HEAD` of the run worktree holds a tree at that path at stop time; it does not prove which tool created the folder or that its contents are correct.
+
 ## Invariants (issue_adoption object)
 
-The object has the shape `{ issue_num, issue_url, origin, verified_via, verified_at, evidence, waived_tools, potential_record? }`.
+The object has the shape `{ issue_num, issue_url, origin, verified_via, verified_at, evidence, waived_tools, potential_record?, feature_folder_record? }`.
 
 | Field | Rule |
 | --- | --- |
@@ -275,6 +290,7 @@ The object has the shape `{ issue_num, issue_url, origin, verified_via, verified
 | `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` | 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`). |
+| `feature_folder_record` | Required when `waived_tools` includes `new_active_feature_folder`, and validated whenever it is an object: `{ path, verified_via, verified_at, evidence }`, where `path` is a folder under `docs/features/active/` equal to the checkpoint `feature-folder`, `verified_via` is `git_cat_file_head` or `git_ls_tree_head`, `verified_at` is present, and `evidence` is a non-empty string. |
 
 The rules run in this order, and their errors accumulate:
 
@@ -287,12 +303,19 @@ The rules run in this order, and their errors accumulate:
 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`, 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.
+10. Only when the rule-8 shape check passed: when `waived_tools` includes `new_active_feature_folder` and `feature_folder_record` is absent or not an object (including `null`), the error is `Checkpoint issue_adoption.feature_folder_record must be an object when waiving new_active_feature_folder.`
+11. Only when the rule-8 shape check passed: whenever `feature_folder_record` is an object, waived or not, its fields are checked in this order, and the errors accumulate:
+    - 11a. `path` must be a string that fully matches `^docs/features/active/[A-Za-z0-9][A-Za-z0-9._-]*(/[A-Za-z0-9][A-Za-z0-9._-]*)*$`, so dot segments, empty segments, a trailing slash, backslashes, drive letters, glob characters, and a leading `-` are rejected: `Checkpoint issue_adoption.feature_folder_record.path must be a folder path under docs/features/active/ without dot segments or a trailing slash.`
+    - 11b. Only when `path` passed 11a: the checkpoint `feature-folder` must be the identical string; an absent, non-string, or different value yields `Checkpoint issue_adoption.feature_folder_record.path must equal the checkpoint feature-folder.`
+    - 11c. `verified_via` must be `git_cat_file_head` or `git_ls_tree_head`: `Checkpoint issue_adoption.feature_folder_record.verified_via must be one of git_cat_file_head, git_ls_tree_head.`
+    - 11d. `verified_at` must be present; absent, `null`, and blank strings are rejected: `Checkpoint issue_adoption.feature_folder_record.verified_at must be present.`
+    - 11e. `evidence` must be a non-empty string: `Checkpoint issue_adoption.feature_folder_record.evidence must be a non-empty string.`
 
-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.
+The closed waivable set is `potential_to_issue`, `new_potential_entry`, `new_potential_bug_entry`, and `new_active_feature_folder`; `new_active_feature_folder` is waived only together with a valid `feature_folder_record`. `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.
+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. Rule 10 and rule 11 errors follow the rule 9 errors in the adoption error list, so a checkpoint that waives `new_active_feature_folder` without a valid record reports the missing-receipt line for each unreceipted required tool first, in `required_mcp_tools` order, and the rule 10 or rule 11 error after them. 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
 
@@ -302,7 +325,8 @@ Fail-closed behavior: any adoption error waives nothing, so each missing receipt
 - `scripts/dev_tools/validate_orchestrator_state.py` appends one error per violated `model_routing_receipts` invariant when a `model_routing_receipts` key is present, delegating to `scripts/dev_tools/_orchestrator_state_model_routing.py`, which recomputes the resolved model via `resolve_delegation_model`. The check does not import or read any schema file.
 - `scripts/dev_tools/validate_orchestrator_state.py` appends one error per violated `require_model_routing` invariant only when the caller passes `require_model_routing=True`, delegating to `scripts/dev_tools/_orchestrator_state_model_routing_gate.py`, which reuses the complexity and model-routing per-entry validators. When the flag is not passed the gate does not run, so existing calls are byte-identical.
 - The validator is consumed by the MCP tool `validate_orchestration_artifacts`; backward compatibility for existing step-based checkpoints is preserved.
-- The standalone-merge authorization invariants are enforced by the `PreToolUse` merge gate (`.claude/hooks/enforce-epic-merge-gate.ps1` with its dot-sourced helpers file, and `.codex/hooks/enforce-epic-merge-gate.ps1`) at merge time. The Python checkpoint validator
+- The standalone-merge authorization invariants are enforced by the `PreToolUse` merge gate (`.claude/hooks/enforce-epic-merge-gate.ps1` with its dot-sourced helpers file, and `.codex/hooks/enforce-epic-merge-gate.ps1`) at merge time. The green-CI standalone merge conditions are enforced by the same Claude gate through its dot-sourced sibling `.claude/hooks/enforce-epic-merge-gate-green-ci.ps1`; the Codex gate has no green-CI branch. The Python checkpoint validator
   does not currently validate standalone_merge_authorizations
   entries; adding that check is recorded as follow-up FU-3.
-- The `issue_adoption` invariants are enforced at completion by the routing-contract check in all three runtimes: `scripts/dev_tools/_orchestrator_state_issue_adoption.py` (Python authority), `extensions/drm-copilot/src/lib/validate/orchestrator-state-issue-adoption.ts`, and `.claude/lib/orchestrator-state/OrchestratorStateIssueAdoption.psm1`, with byte-identical error strings pinned by the shared corpus under `tests/fixtures/orchestrator_state_issue_adoption/`.
+- The `issue_adoption` invariants are enforced at completion by the routing-contract check in all three runtimes: `scripts/dev_tools/_orchestrator_state_issue_adoption.py` (Python authority), `extensions/drm-copilot/src/lib/validate/orchestrator-state-issue-adoption.ts`, and `.claude/lib/orchestrator-state/OrchestratorStateIssueAdoption.psm1`, with byte-identical error strings pinned by the shared corpus under `tests/fixtures/orchestrator_state_issue_adoption/`. Rules 10 and 11 live in the record modules `scripts/dev_tools/_orchestrator_state_feature_folder_record.py`, `extensions/drm-copilot/src/lib/validate/orchestrator-state-feature-folder-record.ts`, and `.claude/lib/orchestrator-state/OrchestratorStateFeatureFolderRecord.psm1`. The `HEAD` probe for a waived `new_active_feature_folder` lives in the hook sibling `.claude/hooks/validate-orchestrator-output-feature-folder.ps1`, loaded by `.claude/hooks/validate-orchestrator-output.ps1`.
+- The batch-budget hooks (`.claude/hooks/enforce-python-batch-budget.ps1`, `.claude/hooks/enforce-powershell-batch-budget.ps1`, and the Codex copies under `.codex/hooks/`) read the checkpoint of the target worktree that `Resolve-HookTargetWorktree` resolves for the edited file, so a coordinating session never needs a checkpoint at its own root for them.

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

@@ -13,6 +13,7 @@ paths:
   - "scripts/dev_tools/validate_orchestration_artifacts.py"
   - "extensions/drm-copilot/src/lib/validate/orchestration-artifacts.ts"
   - ".claude/hooks/enforce-epic-merge-gate.ps1"
+  - ".claude/hooks/validate-orchestrator-output-rejection.ps1"
   - ".claude/agents/parallel-orchestrator.md"
   - ".claude/agents/parallel-planner.md"
   - ".claude/skills/parallel-*/SKILL.md"
@@ -213,6 +214,38 @@ The wave-4 features — F6 (mutation protocol), F7 (enforcement hooks), and F8 (
 
 Integration-cost scheduling (issue #722) adds no `conflict_edges[].reason` member; the four members above are unchanged. The scheduling data travels in tolerated-not-validated fields: an edge may carry the extra fields `hard`, `cost`, and `benefit`, and the planner and orchestrator checkpoints may carry a `tolerated_overlaps` list. No validator reads these fields, and the Python validators and the TypeScript validator port accept them with zero errors.
 
+## Mutation Rejection Signal (issue #1012)
+
+A parallel skill that rejects a mutation before any run checkpoint exists stops without writing state. Its final output then carries a rejection signal so that the completion stop hook `.claude/hooks/validate-orchestrator-output.ps1` can release the stop without demanding a checkpoint that the skill correctly did not write.
+
+**Line grammar.** The signal is the last non-blank line of the final output, after trailing whitespace (including a carriage return) is trimmed, and it matches `^PARALLEL_MUTATION_REJECTED: (?<code>[a-z_]+)$` case-sensitively: the uppercase prefix, a colon, exactly one space, and one code from the table below, with no Markdown formatting (no backticks, no bold), no leading text, and no trailing text. A token on an earlier line, inside prose, or in any other form is not a signal. Where the run's slug is known, the line `parallel_slug: <slug>` precedes the signal.
+
+**Closed code set.** The set is defined here and nowhere else:
+
+| Code | Meaning |
+| --- | --- |
+| `kickoff_artifact_missing` | `/parallel-run` found no committed kickoff artifact for the run and delegated nothing. |
+| `run_not_started` | The run is pending or not started, or no checkpoint tracks the named `parallel_slug`, so there is no running run to mutate. |
+| `items_in_flight` | The mutation is rejected because an item is in flight: a close while any item is in flight, or a removal of an in-flight item without `--disposition`. |
+| `unknown_item` | The removal target is not a live item: it is unknown, `withdrawn`, or `blocked`. |
+
+**Output signal, not a schema member.** The signal is an output signal, not a checkpoint field, and it is not one of the nine enums owned by `## Enum Ownership (F6/F7/F8 consume, never extend)`; that table and its count are unchanged. No validator reads the signal and no checkpoint records it.
+
+**Hook behavior.** The hook evaluates the signal only for `parallel-orchestrator-state` when the checkpoint resolution status is `NoTarget`:
+
+| Condition | Result |
+| --- | --- |
+| parallel, `NoTarget`, valid signal, no contradicting state in any live worktree | allow, regardless of `stop_hook_active` |
+| parallel, `NoTarget`, no signal or an invalid signal | block as before (repairable); the message gains a hint line naming the signal form and this section, and lists the allowed codes when the final line carries the prefix with an invalid code |
+| parallel, `NoTarget`, valid signal, and a live worktree holds parallel checkpoint text that is unparseable, has a non-object root, is off-route, lacks a `parallel_slug`, or records the slug the output names | block as before |
+| parallel, `Ambiguous` or `Rejected`, any signal | block as before |
+| parallel, resolved checkpoint, any signal | full validation as before |
+| `orchestrator-state` or `epic-orchestrator-state`, any signal | unchanged |
+
+A signal never relaxes validation when a checkpoint resolves, and a path that wrote state validates fully. The parser, the state-absence scan, and the decision live in `.claude/hooks/validate-orchestrator-output-rejection.ps1`, whose code array mirrors the table above and is pinned to it by a parity test.
+
+**Ownership.** The parallel skills consume these codes and never redefine them. Each mapped STOP path in `parallel-run`, `parallel-add`, `parallel-close`, and `parallel-remove` names only its own code and cites this section by heading; no skill restates the full set. A new code requires an amendment to this section, to the hook array, and to the parity test in the same change.
+
 ## F7 Seam
 
 The retrospective cohort-ordering invariant `PARALLEL_COHORT_BARRIER_VIOLATION` (design section 9, Layer 2) is F7's explicitly assigned addition to the orchestrator validator. It is NOT implemented here. The entry point of `scripts/dev_tools/validate_parallel_orchestrator_state.py` contains a clearly delimited, appendable helper-invocation block, marked with explicit begin and end comments that name F7 and the invariant token, so that F7's edit is one appended helper call with no reflow of existing code. The TypeScript core `extensions/drm-copilot/src/lib/validate/parallel-orchestrator-state-core.ts` carries the matching comment-delimited seam. Existing helper calls sit outside the block.
@@ -255,19 +288,45 @@ Three constraints bound the mandate-read exclusion:
 1. **The planner remains obliged to enumerate a genuine write explicitly.** An exclusion describes
    the default reading relationship, not a permanent ban. When an item's plan will actually write an
    excluded path, the planner appends that exact path to the declared radius after normalization.
-2. **`quality-tiers.yml` stays a shared surface.** It is listed in both `shared_surfaces` and
-   `mandate_reads`: the first governs what happens when an item really writes it, the second governs
-   what happens when an item merely cites it.
+2. **`quality-tiers.yml` is an append-only registry and a mandate read (issue #1006).** Every item
+   that adds a module appends one entry to it, so both committed truth tables list it in
+   `conflict_tolerance.append_only_paths` and in `mandate_reads`, not in `shared_surfaces`. When an
+   item really writes it, the planner-appended or observed path contends on `path_overlap` at the
+   `append_only` weight and is never a hard edge; when an item merely cites it, the mandate-read
+   exclusion drops the citation. Separator-free token acceptance for it through the root-surface rule
+   (`config_root_surfaces`, `Get-ConfigRootSurface`) no longer applies, because that rule reads only
+   the separator-free entries of `shared_surfaces`; the planner append obligation in constraint 1 and
+   `detect_escaped_paths` in constraint 3 are the backstops.
 3. **`detect_escaped_paths` makes the read/write distinction exact at execution time.** The
    derivation heuristic reads intent from plan text and can be wrong in either direction; drift
    detection compares the declared radius against the paths a diff actually touched, so an item that
    wrote an excluded path is caught against observed evidence rather than against prose.
 
-The extractor additionally rejects four token shapes that were never write claims: a wildcard-free
+The extractor additionally rejects five token shapes that were never write claims: a wildcard-free
 token whose final component names a directory rather than a file, a `docs/features/` glob whose
 wildcard occupies or truncates the feature-folder segment, a contract token carrying no ASCII
-letter, and a token containing a placeholder or interpolation marker. `artifacts/` is not a known
-top-level segment, so a bare `artifacts/**` subtree claim no longer satisfies the shape rules.
+letter, a token containing a placeholder or interpolation marker, and a contract token that is a
+default spreadsheet sheet name (`Sheet` or `Chart` followed by ASCII digits, compared
+case-insensitively). `artifacts/` is not a known top-level segment, so a bare `artifacts/**`
+subtree claim no longer satisfies the shape rules.
+
+#### Generic contract-token rejection (issue #1006)
+
+A spreadsheet application names a new worksheet or chart sheet with a default stem followed by a
+number, so a spec that mentions `Sheet1` in an interface section names a worksheet, not an
+exported symbol, schema, or CLI identifier. Two unrelated items that both named `Sheet1` received a
+hard `contract_dependency` edge. The stems are a code constant, not a truth-table key:
+`GENERIC_CONTRACT_STEMS` in `scripts/dev_tools/_blast_radius_token_shapes.py` and
+`$script:GenericContractStem` in `.claude/lib/blast-radius/BlastRadiusTokenShape.psm1`, pinned equal
+across Python and PowerShell by a Pester parity test that reads the Python source. Workbook and
+object names such as `Book1` and `Table1` are a different class and are not rejected. The predicate
+(`is_generic_contract_token`, `Test-GenericContractToken`) first requires an ASCII token, because a
+.NET case-insensitive match folds the Kelvin sign and the long s to ASCII letters while Python
+`re.ASCII` does not (the issue #903 precedent). It is applied at all six contract-filtering sites:
+`extract_contract_identifiers`, `extract_write_intent_contracts`, and `normalize_declared_radius` in
+Python, and `Get-ContractIdentifier`, `Get-WriteIntentSpecContract`, and
+`Get-NormalizedDeclaredRadius` in PowerShell, so a previously recorded `Sheet1` is dropped on
+recompute. TypeScript has no contract extractor, so no TypeScript parity applies.
 
 ### Mechanically-mergeable path class (issue #643)
 
@@ -454,12 +513,16 @@ narrowing. The only sanctioned mechanisms for relaxing contention are the config
 radius: editing a declared radius to suppress an edge remains prohibited.
 
 **Configuration.** `config/blast-radius.json` carries an optional `conflict_tolerance` object with
-tolerance_percent (integer, at least 0), `weights` (same_file, possible_overlap, append_only, and
-module, each an integer of at least 1), `band_durations` (C1 through C4, each an integer of at least
-1), `default_band` (one of C1 through C4), and append_only_paths (a list of exact entries and `**`
-globs). The reader fails fast with an error naming the key for any other shape; booleans are
-rejected wherever an integer is required. An absent key means strict scheduling, identical to
-tolerance_percent 0.
+tolerance_percent (integer, at least 0), `weights` (same_file, possible_overlap, append_only,
+module, and contract, each an integer of at least 1), `band_durations` (C1 through C4, each an
+integer of at least 1), `default_band` (one of C1 through C4), append_only_paths (a list of exact
+entries and `**` globs), and the optional `combination_threshold_percent` (integer, at least 0;
+default 400 when absent). The `contract` weight (issue #1013) is required and validated like the
+other weights; its committed value is 8, and a destination overrides it, like every other member,
+through `config/blast-radius.local.json`. `combination_threshold_percent` is committed as 400 and is
+overridden through the same overlay. The reader fails fast with an error naming the key for any other
+shape; booleans are rejected wherever an integer is required. An absent key means strict scheduling,
+identical to tolerance_percent 0.
 
 **Edge rule.** For each unordered pair of items:
 
@@ -473,7 +536,14 @@ tolerance_percent 0.
    possible_overlap weight for a glob or directory-prefix overlap, and the module weight times the
    number of shared modules. The append_only_paths check runs before the same_file check (append-only
    precedence), so an append-only file stays low cost even when both items name it. Mergeable paths
-   contribute 0 because they are excluded before enumeration.
+   contribute 0 because they are excluded before enumeration. Add the contract weight times the
+   number of distinct shared contract identifiers: the set the relation intersects to report
+   `contract_dependency`, each identifier counted once however often either radius lists it.
+   `contract_dependency` remains a hard class, so the contract term changes recorded edge costs and
+   combination eligibility and never an edge set. Invariant: at tolerance_percent 0 the edge set
+   equals strict scheduling for any `contract` weight, and at every tolerance the edge set with the
+   contract term equals the edge set without it; only the `cost` of edges whose pair shares a
+   contract differs.
 4. **Benefit** (integer, pairwise). The smaller of the two items' band durations; a missing band uses
    `default_band`. Running the pair concurrently saves at most one cohort step of the shorter item.
 5. **Rule.** The pair is an edge if and only if it conflicts and either it is hard or
@@ -485,8 +555,27 @@ least 1. A detected conflict that is not hard therefore has a cost of at least 1
 tolerance_percent 0 the inequality `cost * 100 > 0` always holds and the edge set equals the
 detected-conflict set exactly; cohort coloring of that set is identical to strict scheduling. At
 every tolerance an edge requires a conflict, so every edge implies a conflict and the edge set is
-always a subset of the detected-conflict set. Raising tolerance_percent never adds an edge, and the
-decision for (a, b) equals the decision for (b, a).
+always a subset of the detected-conflict set. Raising tolerance_percent never turns a pairwise
+decision into an edge, and the decision for (a, b) equals the decision for (b, a). Because the
+aggregate cap below can promote a tolerated overlap, this monotonicity holds for the pairwise
+decision only, not for the capped edge set.
+
+**Aggregate cap (issue #1013).** The pairwise rule judges each pair alone, so the single entry point
+in each runtime (`schedule_conflict_edges` through `select_capped_pairs` in
+`scripts/dev_tools/_blast_radius_aggregate.py`, and Get-BlastRadiusConflictEdge through
+Get-AggregateCappedPair in `.claude/lib/blast-radius/BlastRadiusAggregate.psm1`) applies a post-pass
+that planners and `parallel-add` cannot skip. For item `i`, `total(i)` is the summed cost of its
+remaining tolerated overlaps, and `i` is over its cap when
+`total(i) * 100 > band_duration(i) * tolerance_percent` (integers only; a missing band reads as
+`default_band`). While any item is over its cap, the smallest-key such item promotes the overlap with
+the minimum key (benefit ascending, cost descending, a ascending, b ascending) to an edge carrying
+`hard` false and the overlap's first reason, and the totals are recomputed. At tolerance_percent 0
+nothing is tolerated, so the pass is a no-op and strict identity holds. A single tolerated overlap
+never exceeds the cap, so the cap binds only for an item with two or more tolerated overlaps. The
+capped scheduling output has five pinned set-level properties: the capped edges are a superset of
+the pairwise edges and a subset of the detected conflicts; the output at tolerance 0 equals the
+uncapped output; every item is within its cap after the pass; the output is invariant to input
+order; and a second pass changes nothing.
 
 **Soft-overlap handling.** A detected, non-hard pair within tolerance is a tolerated overlap, not an
 edge. The planner records it in a tolerated_overlaps list on the planner checkpoint (and the
@@ -502,7 +591,39 @@ the checkpoint (`default_band` when absent), through the helper module
 yields an edge and the pair is not already a recorded edge. A tolerated pair whose observed overlap
 stays within tolerance halts neither item; one whose observed overlap exceeds tolerance, or becomes
 hard, is reported. An unevaluable peer radius still counts as an edge (fail closed). At
-tolerance_percent 0 the drift output equals strict drift output.
+tolerance_percent 0 the drift output equals strict drift output. Drift detection stays pairwise: it
+does not apply the aggregate cap, and a cap-promoted pair is a recorded edge, so drift never reports
+it as newly conflicting.
+
+**Telemetry (issue #1013).** Three fields are tolerated and not validated; no validator reads them:
+`tolerated_overlaps[].observed_resolution` on the orchestrator checkpoint, `items[].combined_issue_nums`
+on the planner and orchestrator checkpoints and the run manifest, and a top-level `combinations` list
+on the planner checkpoint. `observed_resolution` has the shape `later_item` (integer), `conflicted`
+(boolean), `conflict_detected_at` (timestamp or null), `resolved_at` (timestamp or null),
+`resolution_minutes` (integer), and `recorded_at` (timestamp). The parallel orchestrator writes it for
+the later-merging item of a tolerated pair. Attribution is non-exclusive: one conflict episode is
+attributed to every tolerated peer that merged before it. Nothing reads `observed_resolution`, and no
+weight changes automatically from it.
+
+**Issue combination (issue #1013).** At planning time only, `find_combinations` in
+`scripts/dev_tools/_blast_radius_combination.py` and Get-BlastRadiusCombination in
+`.claude/lib/blast-radius/BlastRadiusCombination.psm1` find pairs that are cheaper to deliver as one
+item. Combination is disabled when `conflict_tolerance` is absent or tolerance_percent is 0. A
+conflicting pair is a candidate when its full reasons contain `contract_dependency` or it has a
+same-file overlap (two equal concrete entries, after the mergeable exclusion, neither matching
+append_only_paths), and it qualifies when `cost * 100 >= benefit * combination_threshold_percent`.
+A contract-only pair is a candidate and qualifies when its contract-term cost meets the threshold;
+one that does not qualify still serializes as a hard `contract_dependency` edge. Qualifying pairs
+are grouped into connected components; each becomes one combination with ascending members, the
+smallest member as primary, its pairs sorted by `(a, b)`, and `estimated_savings` equal to the sum
+of its pair costs. There is no size cap on a combined item. The planner re-plans the primary
+member's branch to cover every member, removes the other members from `items[]`, and records
+`combined_issue_nums` and the `combinations` entry. No umbrella issue is created: the member issues
+stay separate on GitHub, and the one PR closes every member through its author-asserted autoclose
+line. A combined item remediates as one unit (one child, one `remediation_loop`, one PR) and never
+splits back into separate PRs. A larger combined PR to review and a shared remediation budget are an
+accepted trade; a destination tunes `combination_threshold_percent` to change how often items
+combine.
 
 ### Write-intent extraction (issue #722)
 
@@ -674,8 +795,19 @@ keys are appended after the base keys. An overlay `version` must equal the base
 forbidden-glob guard (`**`, `docs/**`, `tests/**`) applies to the composed module map, including
 overlay-authored modules. A malformed overlay, a `version` mismatch, or a forbidden glob raises an
 error before any write, so `config/blast-radius.json` keeps its prior bytes. With no overlay
-present, the written file is byte-identical to the base document. The overlay cannot remove a
-shipped surface or a derived module.
+present, the written file is byte-identical to the base document. A destination demotes a shipped
+shared surface with the overlay directive `shared_surfaces_demote`, a list of strings (issue
+#1006). It is applied after all other keys are composed: each named entry is removed from
+`shared_surfaces`, with the order of the remaining entries preserved, and unioned into
+`conflict_tolerance.append_only_paths`, base entries first. The directive is consumed, not emitted,
+so the composed file stays within the truth-table key set. An entry that is already an append-only
+path and not a shared surface is accepted as a no-op, so composing a composed result again yields
+identical output. The directive fails closed, before any write, on a non-list value, a non-string
+member, a composed document without `conflict_tolerance.append_only_paths` (no partial
+`conflict_tolerance` is created), or an unknown entry that is neither a shared surface nor an
+append-only path. Demotion never touches `modules`, so the forbidden-glob guard is unchanged. A
+demoted entry that a `shared_surface_globs` pattern still matches stays shared through the glob; the
+bundled glob list is empty. The overlay still cannot remove a derived module.
 
 ## Enforcement
 
@@ -686,5 +818,5 @@ shipped surface or a derived module.
 - 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`.
-- The `PreToolUse` worktree-removal gate `.claude/hooks/enforce-epic-worktree-removal-gate.ps1` likewise carries a parallel allow-branch that authorizes a per-item worktree removal from the parallel-orchestrator checkpoint when `route_id == "parallel"` and the `items[]` entry whose `worktree_path` matches the normalized removal target has `merge_status` in `{merged, worktree_removed}`; any other case — neither checkpoint present, either checkpoint unparseable, `route_id` absent or not `"parallel"`, no matching `worktree_path`, or a matched entry whose `merge_status` is outside that set or absent — fails closed with `EPIC_WORKTREE_REMOVAL_BLOCKED`. Removal is keyed on the worktree path rather than on `pr_number`, because the command names a path. This gate and the sibling gate `.claude/hooks/enforce-parallel-worktree-removal-gate.ps1`, which owns `PARALLEL_WORKTREE_REMOVAL_BLOCKED`, both fire on the same command, and `PreToolUse` denials are conjunctive, so both must allow for a removal to proceed.
+- 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`. After the parallel allow-branch, a standalone green-CI branch (issue #997), implemented in `.claude/hooks/enforce-epic-merge-gate-green-ci.ps1`, allows a run to merge its own pull request only when no epic or parallel checkpoint records the PR number or the item worktree path, the per-feature checkpoint carries no `parallel_mode` or `parallel_slug` marker, and its recorded green S9 gate matches the live PR head. That parallel exclusion is best-effort, because the `Parallel mode: true` marker is not visible in a Bash payload; a parallel child never merges its own pull request.
+- The `PreToolUse` worktree-removal gate `.claude/hooks/enforce-epic-worktree-removal-gate.ps1` likewise carries a parallel allow-branch that authorizes a per-item worktree removal from the parallel-orchestrator checkpoint when `route_id == "parallel"` and the `items[]` entry whose `worktree_path` matches the removal target has `merge_status` in `{merged, worktree_removed}`, where a rooted `worktree_path` is compared to the normalized target, a relative one is joined to the main checkout root and to the root holding the checkpoint, and a blank, `.`, `..`, dot-segment, or `:`-bearing relative value matches nothing, through `Test-WorktreeRunRecordedPathMatchesTarget` in `.claude/lib/worktree-resolution/WorktreeRunRecordPath.psm1` (issue #995); any other case — neither checkpoint present, either checkpoint unparseable, `route_id` absent or not `"parallel"`, no matching `worktree_path`, or a matched entry whose `merge_status` is outside that set or absent — fails closed with `EPIC_WORKTREE_REMOVAL_BLOCKED`. Removal is keyed on the worktree path rather than on `pr_number`, because the command names a path. This gate and the sibling gate `.claude/hooks/enforce-parallel-worktree-removal-gate.ps1`, which owns `PARALLEL_WORKTREE_REMOVAL_BLOCKED`, both fire on the same command, and `PreToolUse` denials are conjunctive, so both must allow for a removal to proceed.

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

@@ -32,7 +32,7 @@ Run the toolchain in order: format → analyze → test. Restart from step 1 if
 - Avoid `Invoke-Expression`, plaintext secrets, and hard-coded credentials/paths.
 - Use `Write-Error`/`throw` for failures; avoid silent catch-alls.
 - Use approved verbs and descriptive nouns for function names (PSScriptAnalyzer enforces this).
-- Keep scripts cohesive and under 500 lines.
+- Keep scripts cohesive and within the tiered file-size policy in `.claude/rules/general-code-change.md` (`## File Size Limit`).
 
 ## Change Budget
 

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

@@ -89,7 +89,7 @@ single pass. Do not substitute the VS Code task wrappers for the native command
 - Use shfmt default formatting (tab indentation, as in `scripts/bash/coverage_lib.sh`).
 - Quote all expansions; resolve tools with `command -v` (honoring the `SHELL_QC_<TOOL>_BIN`
   override seam).
-- No production, test, or reusable shell file may exceed 500 lines.
+- Production, test, and reusable shell files follow the tiered file-size policy in `.claude/rules/general-code-change.md` (`## File Size Limit`).
 - Tests live in `tests/shell/*.bats` and mirror `scripts/bash/`. Tests must not create
   temporary files; use checked-in fixtures under `tests/fixtures/` and checked-in stub
   binaries under `tests/fixtures/shell_qc/stub-bin/` wired through the `SHELL_QC_<TOOL>_BIN`

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

@@ -150,6 +150,10 @@
             "type": "command",
             "command": "pwsh -NoProfile -File .claude/hooks/enforce-evidence-locations.ps1"
           },
+          {
+            "type": "command",
+            "command": "pwsh -NoProfile -File .claude/hooks/enforce-file-size-limit.ps1"
+          },
           {
             "type": "command",
             "command": "pwsh -NoProfile -File .claude/hooks/enforce-orchestration-preimplementation-gate.ps1"
@@ -168,11 +172,16 @@
           },
           {
             "type": "command",
-            "command": "pwsh -NoProfile -File .claude/hooks/enforce-discovery-artifact-gate.ps1"
-          },
+            "command": "pwsh -NoProfile -File .claude/hooks/enforce-mermaid-validation.ps1"
+          }
+        ]
+      },
+      {
+        "matcher": "Bash|Write|Edit|MultiEdit|NotebookEdit|Agent|Task|WebFetch|WebSearch|mcp__.*",
+        "hooks": [
           {
             "type": "command",
-            "command": "pwsh -NoProfile -File .claude/hooks/enforce-mermaid-validation.ps1"
+            "command": "pwsh -NoProfile -File .claude/hooks/enforce-discovery-artifact-gate.ps1"
           }
         ]
       },
@@ -183,6 +192,10 @@
             "type": "command",
             "command": "pwsh -NoProfile -File .claude/hooks/enforce-prd-feature-before-planner.ps1"
           },
+          {
+            "type": "command",
+            "command": "pwsh -NoProfile -File .claude/hooks/enforce-discovery-planning-gate.ps1"
+          },
           {
             "type": "command",
             "command": "pwsh -NoProfile -File .claude/hooks/enforce-orchestration-preimplementation-gate.ps1"
@@ -210,6 +223,17 @@
         ]
       }
     ],
+    "SubagentStart": [
+      {
+        "matcher": "legacy-parity-analyst|runtime-characterization-analyst|requirements-reconciler|migration-coverage-reviewer",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "pwsh -NoProfile -File .claude/hooks/record-discovery-agent-start.ps1"
+          }
+        ]
+      }
+    ],
     "SubagentStop": [
       {
         "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",
@@ -220,6 +244,15 @@
           }
         ]
       },
+      {
+        "matcher": "legacy-parity-analyst|runtime-characterization-analyst|requirements-reconciler|migration-coverage-reviewer",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "pwsh -NoProfile -File .claude/hooks/validate-discovery-artifact-gate.ps1"
+          }
+        ]
+      },
       {
         "matcher": "feature-review",
         "hooks": [

package/resources/claude-customizations/.claude/skills/adjudicate-unspecified-behavior/SKILL.md

@@ -0,0 +1,135 @@
+---
+name: adjudicate-unspecified-behavior
+description: 'Draft traceable proposals for unresolved behavior and separate them from root-owned approval. Use when asked to adjudicate contradictory or undocumented behavior and derive explicitly requested acceptance criteria.'
+---
+
+# Adjudicate Unspecified Behavior
+
+## When to Use This Skill
+
+Use for selected unresolved records with competing interpretations and a named decision owner. A request to adjudicate does not let the specialist approve its own proposal.
+
+## Inputs
+
+These are human-facing workflow selections, not additional service-request fields.
+Supply explicit selections; neither omitted inputs nor profile roots create authority.
+
+| Input | Required contract |
+| --- | --- |
+| profile | Required validated profile and trusted workspace binding. |
+| unresolved_ids | Required explicit unresolved record selection. |
+| interpretations | Required competing interpretations and unknowns. |
+| evidence_refs | Required selected evidence supporting or contradicting each interpretation. |
+| decision_owner | Required explicit owner for a proposed decision. |
+| approval_record | Optional explicitly supplied approval evidence; only the authorized root may apply it. |
+| derived_acceptance | Optional explicit selection of derived acceptance records/views; it adds no feature-contract authority. |
+
+## Routing
+
+Logical role: `requirements-reconciler`.
+The root owns preparation and launch; this skill never auto-launches a logical
+role through frontmatter. The existing resolver selects the exact deployment,
+model, effort and profile hash under the existing C1-C4 ceiling and execution
+context. Do not choose a model, self-launch, create another scheduler or promote
+an ordinary discovery action into an issue. The production-write count is zero.
+
+## Exact output boundary
+
+These rows are maximum workflow caps, not instructions to create every kind.
+Only the prepared required outputs may be created or replaced.
+
+| Artifact kind | Profile key | Constraint |
+| --- | --- | --- |
+| product-decision | product_decisions | Selected proposed decision IDs only |
+| product-decision-collection | product_decisions | Selected proposed decision members only |
+| unspecified-behavior | unspecified_behaviors | Selected unresolved IDs only |
+| unspecified-behavior-collection | unspecified_behaviors | Selected unresolved members only |
+| acceptance-specification | acceptance | Explicitly requested derived criteria only |
+| acceptance-view | acceptance | Explicitly requested eligible views or pending material |
+| required-output-manifest | reports | Exact invocation manifest only |
+
+The profile keys are maximum configured locations, not write grants. Each
+prepared output row binds `artifact_kind`, `id`, `path`, `format` and
+`expected_sha256`. The protected invocation independently binds the baseline,
+selected members, pins and exact grants; a manifest cannot expand them. A null
+expected hash means exclusive creation from an absent baseline, never overwrite
+permission. Preserve unselected collection members and all unrelated inputs.
+Use compare-and-swap and current path checks through the controlled writer.
+
+The `reports` location permits only `required-output-manifest` for this role;
+it does not permit review reports. The manifest itself requires an exact grant.
+
+## Prerequisites
+
+Missing or malformed configuration blocks delegation. Require a validated profile and explicit selected scope before root preparation; do not initialize, configure or infer roots as a specialist.
+
+Require verified native prepare/finalize/start/stop capability. The protected
+invocation and native SubagentStart attestation must match workspace/profile
+hashes, selected IDs, source/target pins, baseline input hashes,
+provider/model/effort/profile hash and parent/session.
+Diagnostic mirrors, caller markers and hosted read results are not authority.
+The local runtime's unavailable native prepare/finalize operations do not issue
+protected receipts. There is no local-user fallback or self-attested host success.
+
+Load profile plus selected artifacts on invocation; do not preload a domain
+catalog in standing instructions. Managed project memory is host-controlled.
+Memory cannot grant filesystem authority or replace evidence. Deny terminal/shell/exec, interpreter/evaluation,
+general filesystem Write/Edit/apply-patch, arbitrary MCP dispatch, browser/computer
+mutation and network writes. Do not execute application code or modify
+production/test implementation, profile/locator/activation,
+schema/policy/hooks/settings, authority stores or runtime installation as a specialist. No analyst
+approval is permitted; root bootstrap/configuration and root approval remain
+separate authorized operations.
+
+## Step-by-Step Workflows
+
+1. Validate the explicit inputs and selected configuration. Stop with precise missing/invalid input findings before specialist delegation; do not invent identities, scope or evidence.
+
+2. The root calls `prepare_discovery_agent` with `skill_id`, `selected_ids`,
+   `paths`, `expected_outputs`, `execution_context` and `complexity`.
+   Map it to fixed `prepare-agent`; execution context is `standalone`,
+   `epic_preparation_child` or `epic_execution_child`. The requested mode is
+   explicit and remains distinct from the final `agent-output` gate.
+   Use `skill_id=adjudicate-unspecified-behavior`; workflow inputs do not add wire fields.
+3. The root launches that exact deployment. Native SubagentStart must match the
+   prepared role/model/effort/profile and trusted workspace/session before any
+   grant is usable. Missing capability or attestation blocks the action.
+4. Use only the granted operations. Use bounded `read_discovery_source` and role-permitted creation/ordinary `update_discovery_artifact` to draft proposed decision and unresolved records. Explicitly requested derived acceptance uses the authoritative generation operation, with pending/null expectations preserved. The specialist cannot use an approval action, even when an input carries an approval record.
+5. Preserve observed source facts, competing interpretations and approved history. Draft proposed decisions only. Do not approve/reject/supersede product decisions or alter approval history. Pending questions cannot become approved requirements. Derived criteria do not authorize `feature_contracts` writes. Without root approval, a proposal remains a proposal.
+6. Produce every exact required output and the stored `required-output-manifest`,
+   preserving its output array order for the digest. Validate claims, references,
+   pins and selected-ID accounting. Purpose-built tools supply authorized proposal
+   inputs for `input_path`/`evidence_path`; never invent a generic Write staging
+   step. Server-side role checks, exact one-use authorization and prospective
+   validation remain mandatory. Bounded source reads preserve content identity
+   and line ranges; truncation requires a narrower selection, not a completeness
+   claim or filesystem fallback.
+7. Call `finalize_discovery_agent` as the specialist, mapped to `finalize-agent`
+   with `mode=agent-output`, non-null `invocation_ref` and no operation inputs.
+   It validates the protected invocation's outputs, not final-message paths.
+   Native SubagentStop then verifies current output authority.
+   Missing final text cannot skip native stop validation.
+8. After proposal finalization and native stop, the authorized root may separately call `update_discovery_artifact`, mapped to `update-artifact` with `update_action=approve-decision`, exact product-decision identity, whole-document `input_path`, `expected_sha256`, `approval_owner` and nonempty `approval_evidence_refs`. Ordinary replacement cannot set approval-only fields. Root approval is a separate authorized operation from reconciler proposal validity; it invalidates prior completion receipts and requires fresh validation before any later gate.
+9. After the separate root operation, the root records the explicit result, content-addressed artifact references,
+   selected-ID accounting and all findings. A successful tool call or generated
+   path alone is not evidence of completed discovery.
+
+## Stop and result
+
+Return proposal findings and any separate root approval result explicitly. Do not report a proposed or pending decision as approved; omit approval when the required authorization or evidence is absent.
+
+Structural success is not discovery, parity or planning completion.
+Missing prepare/finalize/start/stop capability, missing outputs, invalid claims,
+unresolved required work, wrong role/model/start context or a stale/missing
+receipt blocks successful completion. Return explicit
+PASS, FAIL or BLOCKED, distinguishing valid incremental outputs from a passing
+completion gate. Missing native enforcement remains BLOCKED even when ordinary
+local-user operations can run; do not substitute CLI success for native authority.
+
+## References
+
+- [Canonical requirements-reconciler contract](../../../.claude/agents/requirements-reconciler.md)
+- Installed v2 `service-request` and `required-output-manifest` schema contracts;
+  consume them through the authoritative runtime, with no checkout-schema fallback.
+- The selected profile and pinned local artifacts supplied for this invocation;
+  references do not preload catalogs or grant access to unselected paths.