@danmoisan/drm-copilot-mcp 1.1.19 → 1.1.21

package/resources/claude-customizations/.claude/lib/ci-gate/Invoke-MergeConfirmationParser.ps1

@@ -0,0 +1,203 @@
+<#
+.SYNOPSIS
+    Maps one pull-request snapshot to a merge-confirmation status (issue #952).
+
+.DESCRIPTION
+    Consumes the JSON emitted by
+    `gh pr view <n> --json state,mergeCommit,mergedAt,autoMergeRequest`, or a GraphQL
+    `pullRequest` node that may also carry `isInMergeQueue`, and reports whether the pull
+    request has merged. Merge procedures call this parser while they poll after a merge or
+    merge-queue enqueue, and record a merge only after it reports `merged`.
+
+    Mapping (state values are case-sensitive):
+      - MERGED with a non-empty mergeCommit.oid             -> merged
+      - MERGED with a null mergeCommit or an empty oid      -> error
+      - CLOSED                                              -> closed
+      - OPEN with isInMergeQueue true, or with a present
+        non-null autoMergeRequest                           -> pending
+      - OPEN otherwise                                      -> not_queued
+      - a null snapshot, a missing state, or any other
+        state value                                         -> error
+
+    Every error message starts with 'Invoke-MergeConfirmationParser: '.
+
+    This script does NOT invoke `gh`. The caller runs `gh` and passes the resulting JSON
+    through -PrJson or the pipeline, so the mapping is deterministically testable.
+
+.PARAMETER PrJson
+    The pull-request snapshot JSON. Accepts pipeline input. Defaults to '' so the file can be
+    dot-sourced with no arguments.
+
+.PARAMETER AsJson
+    When set, emits the result as compressed JSON instead of a PowerShell object.
+
+.EXAMPLE
+    pwsh -NoProfile -File .claude/lib/ci-gate/Invoke-MergeConfirmationParser.ps1 -PrJson $snapshot -AsJson
+
+.OUTPUTS
+    A PSCustomObject (or a JSON string when -AsJson is set) with the properties Status
+    (merged, pending, not_queued, or closed), MergeCommitSha, and MergedAt. MergeCommitSha and
+    MergedAt are empty unless Status is merged.
+#>
+
+[CmdletBinding()]
+param(
+    [Parameter(ValueFromPipeline = $true)]
+    [AllowEmptyString()]
+    [string]$PrJson = '',
+
+    [Parameter(Mandatory = $false)]
+    [switch]$AsJson
+)
+
+# Function definitions live in begin so the script is a single explicit begin/process unit;
+# the pipeline-bound -PrJson parameter forces a named process block.
+begin {
+    function Get-MergeConfirmationPropertyValue {
+        <#
+        .SYNOPSIS
+            Return a named property value of a parsed object, or $null when it is absent.
+        .DESCRIPTION
+            Reads through PSObject.Properties so an absent property is not an error under
+            Set-StrictMode -Version Latest.
+        #>
+        [CmdletBinding()]
+        param(
+            [AllowNull()]
+            $InputObject,
+
+            [Parameter(Mandatory = $true)]
+            [string]$Name
+        )
+
+        if ($null -eq $InputObject) {
+            return $null
+        }
+        $property = $InputObject.PSObject.Properties[$Name]
+        if ($null -eq $property) {
+            return $null
+        }
+        return $property.Value
+    }
+
+    function ConvertTo-MergeConfirmationTimeText {
+        <#
+        .SYNOPSIS
+            Render a mergedAt value as text: strings verbatim, dates as UTC ISO-8601.
+        #>
+        [CmdletBinding()]
+        [OutputType([string])]
+        param(
+            [AllowNull()]
+            $Value
+        )
+
+        $format = 'yyyy-MM-ddTHH:mm:ssZ'
+        $culture = [System.Globalization.CultureInfo]::InvariantCulture
+        if ($null -eq $Value) {
+            return ''
+        }
+        if ($Value -is [datetimeoffset]) {
+            return $Value.UtcDateTime.ToString($format, $culture)
+        }
+        if ($Value -is [datetime]) {
+            # A Kind of Unspecified carries no offset; JSON timestamps from gh are UTC.
+            $utc = if ($Value.Kind -eq [System.DateTimeKind]::Unspecified) { [datetime]::SpecifyKind($Value, [System.DateTimeKind]::Utc) } else { $Value.ToUniversalTime() }
+            return $utc.ToString($format, $culture)
+        }
+        return [string]$Value
+    }
+
+    function Get-MergeConfirmationStatus {
+        <#
+        .SYNOPSIS
+            Map one parsed pull-request snapshot to the merge-confirmation result object.
+        .PARAMETER Snapshot
+            The parsed snapshot (gh pr view JSON or a GraphQL pullRequest node).
+        .OUTPUTS
+            PSCustomObject with Status, MergeCommitSha, and MergedAt.
+        #>
+        [CmdletBinding()]
+        [OutputType([pscustomobject])]
+        param(
+            [AllowNull()]
+            $Snapshot
+        )
+
+        if ($null -eq $Snapshot) {
+            throw 'Invoke-MergeConfirmationParser: the pull-request snapshot is null or empty.'
+        }
+        $state = Get-MergeConfirmationPropertyValue -InputObject $Snapshot -Name 'state'
+        if ($null -eq $state) {
+            throw 'Invoke-MergeConfirmationParser: the pull-request snapshot has no state field.'
+        }
+        $stateText = [string]$state
+
+        if ($stateText -ceq 'MERGED') {
+            $mergeCommit = Get-MergeConfirmationPropertyValue -InputObject $Snapshot -Name 'mergeCommit'
+            $oid = [string](Get-MergeConfirmationPropertyValue -InputObject $mergeCommit -Name 'oid')
+            if ([string]::IsNullOrWhiteSpace($oid)) {
+                throw 'Invoke-MergeConfirmationParser: state MERGED carries no merge commit oid.'
+            }
+            $mergedAt = ConvertTo-MergeConfirmationTimeText -Value (Get-MergeConfirmationPropertyValue -InputObject $Snapshot -Name 'mergedAt')
+            return [pscustomobject]@{ Status = 'merged'; MergeCommitSha = $oid; MergedAt = $mergedAt }
+        }
+        if ($stateText -ceq 'CLOSED') {
+            return [pscustomobject]@{ Status = 'closed'; MergeCommitSha = ''; MergedAt = '' }
+        }
+        if ($stateText -ceq 'OPEN') {
+            $inQueue = Get-MergeConfirmationPropertyValue -InputObject $Snapshot -Name 'isInMergeQueue'
+            $autoMerge = Get-MergeConfirmationPropertyValue -InputObject $Snapshot -Name 'autoMergeRequest'
+            $queued = ($inQueue -is [bool] -and $inQueue) -or ($null -ne $autoMerge)
+            $status = if ($queued) { 'pending' } else { 'not_queued' }
+            return [pscustomobject]@{ Status = $status; MergeCommitSha = ''; MergedAt = '' }
+        }
+
+        throw ("Invoke-MergeConfirmationParser: unrecognized pull-request state '{0}'." -f $stateText)
+    }
+
+    function Invoke-MergeConfirmationParser {
+        <#
+        .SYNOPSIS
+            Parse a pull-request snapshot JSON string and map it to a merge-confirmation status.
+        .PARAMETER PrJson
+            The snapshot JSON text.
+        .PARAMETER AsJson
+            Emit compressed JSON instead of the result object.
+        .OUTPUTS
+            PSCustomObject, or System.String when -AsJson is set.
+        #>
+        [CmdletBinding()]
+        param(
+            [AllowEmptyString()]
+            [AllowNull()]
+            [string]$PrJson,
+
+            [switch]$AsJson
+        )
+
+        $snapshot = $null
+        if (-not [string]::IsNullOrWhiteSpace($PrJson)) {
+            try {
+                $snapshot = $PrJson | ConvertFrom-Json -ErrorAction Stop
+            }
+            catch {
+                throw ('Invoke-MergeConfirmationParser: the pull-request snapshot is not valid JSON: ' + $_.Exception.Message)
+            }
+        }
+
+        $result = Get-MergeConfirmationStatus -Snapshot $snapshot
+        if ($AsJson) {
+            return ($result | ConvertTo-Json -Depth 3 -Compress)
+        }
+        return $result
+    }
+}
+
+# Entry point. The parser runs only when the file is executed directly; when dot-sourced,
+# $MyInvocation.InvocationName is '.', so the guard leaves only the function definitions.
+process {
+    if ($MyInvocation.InvocationName -ne '.') {
+        Invoke-MergeConfirmationParser -PrJson $PrJson -AsJson:$AsJson
+    }
+}

package/resources/claude-customizations/.claude/lib/codex-routing/CodexDeployment.psm1

@@ -7,9 +7,9 @@
     `scripts/dev_tools/resolve_codex_deployment.py`. It resolves the exact Codex
     deployment agent, model, and reasoning effort for one delegation from the
     logical agent, the assessed complexity band, the execution context, and the
-    orchestration complexity ceiling. C3 defaults to Terra/high and elevates to
-    Sol/high only for an epic child or a C4 orchestration ceiling; the epic
-    planner and epic orchestrator personas are always forced to Sol/ultra. No
+    orchestration complexity ceiling. C3 defaults to Sol/high and elevates to
+    Astra/high only for an epic child or a C4 orchestration ceiling; the epic
+    planner and epic orchestrator personas are always forced to Astra/ultra. No
     model alias and no silent fallback is accepted.
 
     SINGLE-IMPLEMENTATION RULE. The orchestrator-state U6.X checks
@@ -81,20 +81,20 @@ $script:LOGICAL_AGENT_ALIASES = @{ 'feature-review' = 'feature-reviewer' }
 
 # The per-band deployment profiles (suffix, model, reasoning effort).
 $script:BASE_PROFILES = @{
-    C1 = @{ suffix = 'c1'; model = 'gpt-5.6-luna'; model_reasoning_effort = 'low' }
-    C2 = @{ suffix = 'c2'; model = 'gpt-5.6-terra'; model_reasoning_effort = 'medium' }
-    C3 = @{ suffix = 'c3'; model = 'gpt-5.6-terra'; model_reasoning_effort = 'high' }
-    C4 = @{ suffix = 'c4'; model = 'gpt-5.6-sol'; model_reasoning_effort = 'max' }
+    C1 = @{ suffix = 'c1'; model = 'gpt-6-luna'; model_reasoning_effort = 'low' }
+    C2 = @{ suffix = 'c2'; model = 'gpt-6.1-sol'; model_reasoning_effort = 'medium' }
+    C3 = @{ suffix = 'c3'; model = 'gpt-6.1-sol'; model_reasoning_effort = 'high' }
+    C4 = @{ suffix = 'c4'; model = 'gpt-6-astra'; model_reasoning_effort = 'max' }
 }
 
 # The profile a C3 delegation elevates to when the overlay applies.
-$script:C3_ELEVATED_PROFILE = @{ suffix = 'c3-elevated'; model = 'gpt-5.6-sol'; model_reasoning_effort = 'high' }
+$script:C3_ELEVATED_PROFILE = @{ suffix = 'c3-elevated'; model = 'gpt-6-astra'; model_reasoning_effort = 'high' }
 
 # The personas whose profile is forced regardless of band, context, or ceiling.
 # Their deployment agent is the logical agent itself (empty suffix).
 $script:FORCED_PERSONA_PROFILES = @{
-    'epic-planner'      = @{ suffix = ''; model = 'gpt-5.6-sol'; model_reasoning_effort = 'ultra' }
-    'epic-orchestrator' = @{ suffix = ''; model = 'gpt-5.6-sol'; model_reasoning_effort = 'ultra' }
+    'epic-planner'      = @{ suffix = ''; model = 'gpt-6-astra'; model_reasoning_effort = 'ultra' }
+    'epic-orchestrator' = @{ suffix = ''; model = 'gpt-6-astra'; model_reasoning_effort = 'ultra' }
 }
 
 

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 G10 for atomic plans. G1 through G9 judge the shell commands a plan states as acceptance conditions; the document-level G10 rule reports a SCRATCH definition that is not namespaced by issue number.
+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 an atomic plan: G1 through G9 judge the shell commands the plan states as acceptance conditions, and G10 judges 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).
+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`. 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`. 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. 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.
+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 |
 | --- | --- | --- |
@@ -41,14 +41,17 @@ Every finding string begins with the square-bracketed `P#-T#` identifier of the
 | **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 G10 are the complete shipped set. G1 through G6 were added by issue #486, G7 through G9 by issue #519, and G10 by issue #932; 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. 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.
+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
 
@@ -154,7 +157,7 @@ A continuation line is non-blank, begins with whitespace, and is not a fence lin
 
 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/active/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.
+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.
 
@@ -174,6 +177,36 @@ One false-positive class is possible and recorded: the colon connector matches p
 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.
@@ -284,13 +317,16 @@ The prohibition is enforced by tests, not only by prose: a parity test asserts t
 - 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 G9, calls `scripts/dev_tools/plan_gate_scratch.py` for G10, 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.
 - `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.
-- `.claude/hooks/validate-planner-output.ps1` is not modified by this rule and carries no part of its enforcement.
+- `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/skills/atomic-plan-contract/SKILL.md

@@ -21,6 +21,22 @@ Use this skill when:
 - Task IDs must match their phase and be sequential per phase.
 - Plans must pass the `mcp__drm-copilot__validate_orchestration_artifacts` MCP tool with `artifact_type: "plan"` and `artifact_path: <plan-path>` before they can be reported as approved.
 
+## Design-Level Plan Contract (Mandatory)
+
+A plan is a design-level document: it states what changes and how the change is proven, not a transcript of commands. Every task names the files it creates or edits, the symbols, headings, or tests it touches, the behavior the change produces, the tests that prove that behavior, and an acceptance condition stated as an observable outcome.
+
+Rules:
+
+- **Anchors are symbols, headings, or test names.** A plan never cites a line number, a `path:line` locator, a `#L` anchor, or a commit SHA, because each goes stale when `main` moves (validator rules G11 and G12). Scope comparisons name the merge-base derivation of `origin/main` and `HEAD`, not a commit.
+- **Literals only where they are the asserted value.** A plan quotes a literal when an acceptance condition asserts that exact value. It does not quote file contents, command output, or prose for context.
+- **Tool routes are not restated.** Tool routes, launchers, wrapper scripts, command-text restrictions, the batch budget, hook context, and CI shape are owned by the `execution-environment` skill. A plan references that skill instead of restating its content.
+- **Changed existing behavior names its asserting tests.** A task that changes the observable behavior of an existing function, script, fixture, or test stub (its signature, argv, output, exit status, or the files it writes) names every existing test that asserts that behavior and states each test's disposition: unchanged because it is unaffected, or updated, with the reason for the update. The tests are found by searching the test tree for the symbol, the file name, and the asserted output. A test that asserts the current behavior and is outside the task's file set fails once the change lands, and the plan's own acceptance condition then cannot be met. The planner's adversarial self-review includes this search for every task that changes existing behavior.
+- **Size guideline.** A plan stays within 40 canonical tasks and 400 physical lines. A plan that needs more carries a `## Size Justification` section with at least one line stating why the size is necessary (validator rule G13). Files produced by one generator run count as one generator task.
+- **Pre-Mortem.** Every plan carries a `## Pre-Mortem` section with one bullet beginning with each of the seven labels `Review checklists`, `Coverage`, `Mirror parity`, `File size`, `Test isolation`, `CI-only behavior`, and `Evidence`. Each bullet states how the plan prevents that failure class, or states "not applicable" followed by the reason. The `Test isolation` bullet names the isolation runs the plan performs: a seeded shuffled Jest run with the seed recorded, a reversed-order run of the new or changed Python test modules, and a seeded shuffled file-order run of the touched Pester suites with at least three seeds, each seed recorded. The `Mirror parity` bullet also covers the execution-environment brief: a plan that alters a fact the brief states (for example, it adds or renames a CI job, changes a required status context, a tool route, or a batch-budget rule) includes a task that updates the brief in the same change, in all six byte-identical copies, and the bullet names that task. Without that task the brief states a superseded fact once the change lands, which breaks the brief's own maintenance rule. The planner SubagentStop hook blocks a plan without a complete section.
+- **Final-phase self-review.** The final phase of every plan contains a self-review task that walks the policy-audit, code-review, and feature-audit templates under `docs/features/templates/policy_audit/` against the branch diff from the merge base and writes `<FEATURE>/evidence/qa-gates/self-review.<timestamp>.md` with one PASS, FAIL, or N/A row per checklist item. A FAIL row is fixed and the QA loop is re-run before the self-review is rewritten; the plan does not complete with a FAIL row.
+
+This section takes precedence over the literal-quoting rules of `## Wrap-Tolerant Assertion Authoring (Mandatory)`: those rules govern the asserted value of an acceptance condition, not context.
+
 ## Short-Path Minimal Plan Contract
 
 When orchestration selects short path, a minimal plan is still mandatory and must include these blocks:
@@ -145,38 +161,52 @@ Any regression test task expected to fail must be tagged with `[expect-fail]` an
 
 ## Planner Adversarial Self-Review (Mandatory)
 
-Before any plan handoff, `atomic-planner` MUST complete one explicit adversarial self-review pass over every fact, assumption, and line or file citation the plan relies on. The pass is required on initial authoring and on every revision-delta round. A revision round is not exempt because it changed only part of the plan: the citations the revision touched describe the tree as it stands after the revision, and no earlier pass observed that state.
+Before any plan handoff, `atomic-planner` MUST complete one explicit adversarial self-review pass over every fact, assumption, and file, symbol, heading, or test citation the plan relies on. The pass is required on initial authoring and on every revision-delta round. A revision round is not exempt because it changed only part of the plan: the citations the revision touched describe the tree as it stands after the revision, and no earlier pass observed that state.
 
 Rules:
 
-- **Re-derive every citation in this pass.** Any line, file, test, or assertion that the planner's own edit touched, added, or removed in the current authoring or revision pass MUST be re-derived directly against current repository state in that same pass. The prohibited source is a citation carried forward from an earlier round, including one the planner itself verified in a prior round: that earlier verification observed the tree before the intervening edits, so it is evidence about a superseded state rather than about the state the plan now asserts.
-- **Re-check the sibling region.** The self-review MUST re-check the sibling lines, tests, and assertions that sit in the same file or region as any edited citation. The failure mechanism is sibling invalidation: a fix to one line can invalidate an assumption baked into a sibling line or test that a prior round's citation did not cover, so a pass that verifies only the edited line leaves the invalidated sibling unreported and it surfaces as a defect on a later round.
+- **Re-derive every citation in this pass.** Any file, symbol, heading, test, or assertion that the planner's own edit touched, added, or removed in the current authoring or revision pass MUST be re-derived directly against current repository state in that same pass. The prohibited source is a citation carried forward from an earlier round, including one the planner itself verified in a prior round: that earlier verification observed the tree before the intervening edits, so it is evidence about a superseded state rather than about the state the plan now asserts.
+- **Re-check the sibling region.** The self-review MUST re-check the sibling symbols, tests, and assertions that sit in the same file or section as any edited citation. The failure mechanism is sibling invalidation: a fix to one citation can invalidate an assumption baked into a sibling symbol or test that a prior round's citation did not cover, so a pass that verifies only the edited line leaves the invalidated sibling unreported and it surfaces as a defect on a later round.
 
 Declaration requirement. Every plan handoff MUST carry exactly one of these two signal lines, written in the directive-line form already used elsewhere in this contract:
 
-- `SELF-REVIEW: RE-DERIVED THIS PASS` — the adversarial self-review pass completed in this pass. This signal MUST be followed by an enumeration of the citations re-derived in that pass, one entry per citation, each naming the file and the line, test, or identifier that was re-derived. A signal carrying no enumeration is not a completed declaration.
+- `SELF-REVIEW: RE-DERIVED THIS PASS` — the adversarial self-review pass completed in this pass. This signal MUST be followed by an enumeration of the citations re-derived in that pass, one entry per citation, each naming the file and the symbol, heading, or test name that was re-derived. A signal carrying no enumeration is not a completed declaration.
 - `SELF-REVIEW: BLOCKED` — the pass could not be completed. This signal halts the handoff. It does not permit a self-approved plan: the planner reports the blocking reason and waits for the caller rather than proceeding to hand off an unverified plan.
 
 ## Preflight Validation (Planner ↔ Executor)
 
 ### Planner Internal Review Record
 
-Before executor preflight, the planner must emit exactly one bounded record between `PLANNER-INTERNAL-REVIEW: PASS` and the existing `PREFLIGHT:` signal. The record requires exactly one passing declaration each for `CITATION-TO-TREE`, `AC-TRACEABILITY`, and `SCOPE-BOUNDARY`; one or more `CITATION: <repository-relative path> | <nonblank locator>` entries; exactly one `AC-INVENTORY:` declaration containing unique nonblank IDs; one `AC-MAPPING: <ID> | IMPLEMENTATION: <nonblank> | TESTS: <nonblank> | EVIDENCE: <nonblank>` for every and only inventory ID; and exactly one `UNRESOLVED-GAPS: NONE`. Missing, blank, duplicate, non-passing, out-of-bounds, or inventory/mapping-disagreeing declarations block handoff. If review cannot pass, emit `SELF-REVIEW: BLOCKED` and do not hand the plan to preflight. `SELF-REVIEW: RE-DERIVED THIS PASS` remains distinct and does not replace executor clearance.
+Before executor preflight, the planner must emit exactly one bounded record between `PLANNER-INTERNAL-REVIEW: PASS` and the existing `PREFLIGHT:` signal. The record requires exactly one passing declaration each for `CITATION-TO-TREE`, `AC-TRACEABILITY`, and `SCOPE-BOUNDARY`; one or more `CITATION: <repository-relative path> | <symbol, heading, or test name>` entries, whose locator is never a line reference (bare digits, `L` plus digits, `line` plus digits, or a path followed by a colon and digits); exactly one `AC-INVENTORY:` declaration containing unique nonblank IDs; one `AC-MAPPING: <ID> | IMPLEMENTATION: <nonblank> | TESTS: <nonblank> | EVIDENCE: <nonblank>` for every and only inventory ID; and exactly one `UNRESOLVED-GAPS: NONE`. Missing, blank, duplicate, non-passing, out-of-bounds, or inventory/mapping-disagreeing declarations block handoff. If review cannot pass, emit `SELF-REVIEW: BLOCKED` and do not hand the plan to preflight. `SELF-REVIEW: RE-DERIVED THIS PASS` remains distinct and does not replace executor clearance.
 
 When validating or handing off plans for execution:
-- Use the directive line: `DIRECTIVE: PREFLIGHT VALIDATION ONLY`.
+- Put the directive line `DIRECTIVE: PREFLIGHT VALIDATION ONLY` in the delegation prompt. The preflight directive belongs in the delegation prompt, never in a plan file. A plan file that still carries the line from an earlier contract is harmless, because the executor SubagentStop hook classifies a run from the delegation prompt recorded in the subagent transcript.
 - Require one of the exact signals:
 	- `PREFLIGHT: ALL CLEAR`
 	- `PREFLIGHT: REVISIONS REQUIRED`
-- If revisions are required, provide a precise plan delta and repeat validation until all clear.
 - If the required planner ↔ executor handoff cannot be started or completed, stop and report blocked state; do not self-approve the plan.
 
-Review depth and reporting rules:
+### Single-Pass Preflight
+
+Preflight completes in one pass. The preflight executor fixes trivial defects in place and returns only substantive defects, and a plan returns to the planner at most once.
 
 - **Review the entire plan in one pass.** Under `DIRECTIVE: PREFLIGHT VALIDATION ONLY`, `atomic-executor` MUST continue checking every remaining phase, task, and prose region after finding an initial defect. Stopping at the first defect is prohibited: the unchecked remainder holds defects that the same pass could have reported, and each one that is left unreported becomes an additional round.
-- **Enumerate every defect found.** `PREFLIGHT: REVISIONS REQUIRED` output MUST list every defect found in that pass, not only the first. The failure mechanism is round inflation: a single-defect report causes the next round to rediscover a defect the same pass could have reported, so the round count rises without the review having covered more of the plan.
-- **Check the delta against its own rule.** Before returning either signal, `atomic-executor` MUST check its proposed fix or delta text against every rule the plan enforces, including that delta's own prose against the same violation class it is remediating. Worked example: the delta prose of a tonality-compliance fix must not itself contain the hyperbole or humor that `.claude/rules/tonality.md` prohibits, because a delta that violates the rule it is written to enforce reintroduces the finding it closes.
-- **Two-round target.** The quality bar is a target of at most two preflight rounds per plan. Exhaustive first-pass review is the mechanism that holds the round count to that target: a pass that reports every defect it can find leaves at most a revision round and a confirming round, whereas a pass that reports one defect at a time cannot reach the target however correct each individual report is.
+- **Classify every defect as trivial or substantive.**
+	- **Trivial defects** are a stale or misspelled anchor, symbol, heading, or path whose intent is unambiguous; a citation correction, including removal of a G11 line-number or G12 commit-SHA citation; a typo; a literal-formatting defect that does not change what is asserted (quoting, `-e` for a hyphen-leading search pattern, plain `grep` instead of `git grep` for a file the plan creates, a full repository-relative pathspec); an evidence filename spelling; and a validator-blind defect class listed in the `execution-environment` skill whose correction keeps the assertion's meaning.
+	- **Substantive defects** are a missing or extra task; a wrong file set or design; an acceptance criterion with no implementing task; an unsatisfiable acceptance condition whose correction changes what is asserted; a task-ordering error; and a scope-boundary violation.
+- **Fix trivial defects in place, in task text only.** The preflight executor edits task text and plan preamble in the same plan file. It never adds, removes, or reorders tasks, so the executor's anti-replanning rules are unchanged. Each fix is recorded in `<FEATURE>/evidence/other/preflight-fixes.<timestamp>.md`, which carries `Timestamp:`, `Plan:`, and one entry per fix.
+- **Return substantive defects only, all of them.** `PREFLIGHT: REVISIONS REQUIRED` is returned only when at least one substantive defect remains, and it lists every substantive defect found in the pass. `PREFLIGHT: ALL CLEAR` may follow in-place fixes.
+- **Check the fix against its own rule.** Before returning either signal, `atomic-executor` MUST check each in-place fix and each required change against every rule the plan enforces, including the fix's own prose against the same violation class it is remediating. Worked example: the prose of a tonality-compliance fix must not itself contain the hyperbole or humor that `.claude/rules/tonality.md` prohibits, because a fix that violates the rule it is written to enforce reintroduces the finding it closes.
+
+Output format. After the `PREFLIGHT:` signal and the `CONVERGENCE:` line, the preflight return carries one line per defect:
+
+- `PREFLIGHT-FIX: <task id or heading> | <defect class> | <change made>` for each trivial defect fixed in place.
+- `PREFLIGHT-DEFECT: <task id or heading> | <defect class> | <required change>` for each substantive defect returned.
+- `preflight-fix-record: <path>` when at least one fix was made, naming the record under `<FEATURE>/evidence/other/`.
+
+`PREFLIGHT: ALL CLEAR` carries no `PREFLIGHT-DEFECT:` line, and `PREFLIGHT: REVISIONS REQUIRED` carries at least one. The executor SubagentStop hook blocks, repairably, a preflight return with zero or several `PREFLIGHT:` signals, a signal that disagrees with its defect lines, or a `PREFLIGHT-FIX:` line without an existing `preflight-fix-record:` path under `docs/features/`.
+
+At most one return. A plan returns to the planner at most once. On `PREFLIGHT: REVISIONS REQUIRED`, the orchestrator delegates one planner revision carrying the full `PREFLIGHT-DEFECT:` list, then runs one more preflight. If that second preflight still reports a substantive defect, the orchestrator halts with `blocked_reason: "validator_failed"` during planning, or records `final_status: "blocked_preflight_iteration_limit"` in a remediation cycle. In a proportionate remediation cycle, where preflight and execution run in one executor delegation, a substantive defect stops the run with `BLOCKED at preflight (before [P0-T1])` before any task is checked.
 
 Convergence signal. Every preflight return, whether it carries `PREFLIGHT: ALL CLEAR` or `PREFLIGHT: REVISIONS REQUIRED`, MUST additionally carry exactly one of these two forward-looking lines:
 
@@ -193,14 +223,16 @@ Before a plan can be treated as approved:
 - reject the plan if that validator exits non-zero,
 - do not treat human-readable summaries as a substitute for validator success.
 
-The same validator call also applies the acceptance-gate rules G1 through G6 defined in `.claude/rules/plan-acceptance-gates.md`. Those rules report acceptance conditions that cannot fail — a coverage argument that collects no data, or a search for a literal that returns zero matches whatever the executor does. They run automatically on the existing `plan` route with no additional flag. Blocking findings appear in the validator's error output and fail the gate; Warnings are surfaced without failing it, prefixed with `PLAN GATE WARNING: ` on the CLI and carried on the optional `warnings` field of the MCP result. Read that rule file before authoring acceptance conditions.
+The same validator call also applies the acceptance-gate rules defined in `.claude/rules/plan-acceptance-gates.md`, starting with G1 through G6. Those rules report acceptance conditions that cannot fail — a coverage argument that collects no data, or a search for a literal that returns zero matches whatever the executor does. They run automatically on the existing `plan` route with no additional flag. Blocking findings appear in the validator's error output and fail the gate; Warnings are surfaced without failing it, prefixed with `PLAN GATE WARNING: ` on the CLI and carried on the optional `warnings` field of the MCP result. Read that rule file before authoring acceptance conditions.
 
-The same call additionally applies the rules G7, G8, G8b, and G9, which report a write-mode command observed only by its exit code, an unanchored `git diff`, a name-listing diff with no companion span, and a coverage command that prints no table. All four ship in the Warning channel, so they surface without failing the gate. The same call also applies G10, a document-level rule that reports a SCRATCH definition not namespaced by issue number. G10 ships in the Blocking channel and reports each finding with a `Line N: ` prefix rather than a task identifier, because the definition sits outside any task window. The complete shipped set is therefore G1 through G10.
+The same call additionally applies the rules G7, G8, G8b, and G9, which report a write-mode command observed only by its exit code, an unanchored `git diff`, a name-listing diff with no companion span, and a coverage command that prints no table. All four ship in the Warning channel, so they surface without failing the gate. The same call also applies G10, a document-level rule that reports a SCRATCH definition not namespaced by issue number. G10 ships in the Blocking channel and reports each finding with a `Line N: ` prefix rather than a task identifier, because the definition sits outside any task window. The same call also applies the document-level rules G11, G12, and G13, which report a line-number citation, a commit-SHA citation, and a plan above 40 tasks or 400 lines without a non-empty `## Size Justification` section; all three ship in the Blocking channel with the `Line N: ` prefix. The complete shipped set is therefore G1 through G13. The installed MCP validator applies G11 through G13 only after the extension release that carries them is installed; until then, validate a plan with the repository's Python CLI `scripts/dev_tools/validate_orchestration_artifacts.py` and its `plan` subcommand, as the `execution-environment` skill states.
 
 ## Wrap-Tolerant Assertion Authoring (Mandatory)
 
 An acceptance condition must be able to fail. A condition whose command returns the same result whatever the executor does verifies nothing, however precise it reads. Author every acceptance condition in a wrap-tolerant form: one that survives line wrapping and shell quoting in the file it asserts against.
 
+These rules apply to the asserted value of an acceptance condition and are subordinate to `## Design-Level Plan Contract (Mandatory)`: they say how to quote a value that is asserted, not that a plan should quote file contents, command recipes, or tool routes. Where a rule below names a command shape, the shape is guidance for the executor's choice of command, which the `execution-environment` skill governs.
+
 Rules:
 
 - **Prefer a named test over a phrase search.** When a test can carry the assertion, name the test and its node ID and assert its pass count. A test node ID is stable under reformatting; a prose phrase is not. Reserve searches for cases where no test can express the condition.
@@ -216,7 +248,7 @@ Rules:
 - **Observe a command's success-case output before asserting over that output (mandatory).** Run the command, or read a recorded run of it, and confirm the value you intend to assert is actually printed on a *successful* run. Do not infer it from the tool's documentation, from the plan, or from what the tool prints on failure. This requirement exists because the class of defect it prevents is not detectable by reading: an assertion on a line the tool prints only when it changed something is unsatisfiable on a clean run; a demand for a zero-diagnostic count from a tool that returns only an ok flag names a value with no source; a demand for separate line and branch percentages from a coverage run that prints one combined column reads two numbers that are never printed. G7 and G9 cover two decidable slices of this class. The remainder is covered by this requirement and by nothing else, so a reviewer cannot rely on the gate to catch it.
 - **Fix the evidence in the plan; never leave the executor to select it.** An executor free to choose the evidence it is judged against cannot fail. Do not write an acceptance condition that asks the executor to identify "the known-genuine pair", to choose a survivor list, or to pick any suitable instance. Name the instances, or state the mechanical derivation that produces them, so a third party re-running it obtains the same set. This is authoring guidance and not a rule: a validator rule that scanned acceptance text for selection vocabulary was proposed and rejected, because that vocabulary is ordinary plan prose used in roles carrying no selection semantics and a keyword scan over prose is not statically decidable for the property it would claim to detect. The judgment is the author's, and it is not automated. `.claude/rules/plan-acceptance-gates.md` records the rejection and the reason for it.
 - **Check that the task-ordering does not make the condition unsatisfiable.** No rule covers this. A gate that runs a test path containing deliberately-failing cases added by an earlier task, before the later task that makes them pass, cannot exit 0. A baseline captured after a write-mode formatter has already repaired pre-existing drift becomes either a blanket waiver or makes a later gate unsatisfiable. Read each acceptance condition against the state the plan will actually be in when its task runs.
-- **Name the runner and job for a Pester acceptance criterion.** CI runs Pester in two jobs of `.github/workflows/_poshqc.yml`: `poshqc / PowerShell QC` runs every suite with coverage on `windows-latest`, and `poshqc / PowerShell hook suites (Linux)` runs only `tests/scripts/claude-hooks` and `tests/scripts/codex-hooks` on `ubuntu-latest`, with coverage disabled. A Pester acceptance criterion may cite `ubuntu-latest` only for suites under `tests/scripts/claude-hooks` or `tests/scripts/codex-hooks`, never for coverage, and must name the job it relies on (`poshqc / PowerShell QC` or `poshqc / PowerShell hook suites (Linux)`).
+- **Name the runner and job for a Pester acceptance criterion.** In `.github/workflows/_poshqc.yml`, the Pester suites run with coverage on `windows-latest` in the shard jobs `poshqc / PowerShell QC shard 1`, `shard 2`, and `shard 3`; `poshqc / PowerShell QC` is the aggregating required check, which requires the static and shard jobs to succeed and merges shard coverage; and `poshqc / PowerShell hook suites (Linux)` runs only `tests/scripts/claude-hooks` and `tests/scripts/codex-hooks` on `ubuntu-latest`, with coverage disabled. The execution-environment brief's `## CI Shape and Required Checks` section is the authoritative description of this shape. A Pester acceptance criterion may cite `ubuntu-latest` only for suites under `tests/scripts/claude-hooks` or `tests/scripts/codex-hooks`, never for coverage, and must name the job it relies on (`poshqc / PowerShell QC` or `poshqc / PowerShell hook suites (Linux)`).
 - **Do not assert a fixed-string search literal that contains a backslash.** Git for Windows grep 3.0 reads a doubled backslash in a `grep -F` pattern as one backslash, so the same check returns a different count locally than on a CI runner and cannot pass in both places. Assert a backslash-free substring of the literal, a named test, or a hash or byte-identity check instead.
 
 ## Plan-Path Continuity Contract (Mandatory)
@@ -224,10 +256,10 @@ Rules:
 When a caller provides an explicit target plan file path (for example `${plan-path}` or `${file}`):
 
 - Planner MUST update that exact file in place.
-- Planner MUST reuse the same file for all preflight revision iterations.
+- Planner MUST reuse the same file for the single permitted preflight revision.
 - Planner MUST NOT create additional timestamped sibling files (for example `plan.<timestamp>.md`) during the same planning cycle.
 
-If the provided path does not exist, it may be created once, then reused for all subsequent revisions in that cycle.
+If the provided path does not exist, it may be created once, then reused for the single permitted revision in that cycle.
 
 ## Mode source precedence (Mandatory)
 

package/resources/claude-customizations/.claude/skills/cleanup-merged-worktrees/SKILL.md

@@ -203,9 +203,13 @@ The script emits pipe-delimited, `LC_ALL=C`-ordered records, one per line:
    `.claude/settings.json`) carries no `gh` entry; and `.claude/hooks/enforce-epic-merge-gate.ps1`
    would deny the command with `EPIC_MERGE_GATE_BLOCKED` if it were attempted. At this
    boundary the agent reports the consolidation pull request's URL or number to the
-   operator and stops. The ruleset on `main` sets `strict_required_status_checks_policy`,
-   so the branch must be up to date with `main` before the merge becomes available to the
-   operator; the wait for the merge is unbounded within a session. After the consolidation
+   operator and stops. When `main` uses a merge queue (issue #952), the queue tests the merged
+   result of the pull request and the entries ahead of it against the latest `main`, so the
+   branch need not be up to date with `main`, and the operator adds it to the queue once its
+   checks pass. Without a merge queue, the ruleset on `main` sets
+   `strict_required_status_checks_policy`, so the branch must be up to date with `main` before
+   the merge becomes available to the operator. In either case the wait for the merge is
+   unbounded within a session. After the consolidation
    PR merges, verify it with `git fetch` followed by
    `git merge-base --is-ancestor documentationandmemories main`. Exit 0 confirms every
    consolidated commit is now reachable from `main`; that is the only state that unlocks

package/resources/claude-customizations/.claude/skills/csharp-change-budget-router/SKILL.md

@@ -28,7 +28,7 @@ When routed through `csharp-orchestrator`, small path still requires lifecycle s
 - promote potential item to GitHub issue with `--work-mode minor-audit`,
 - create active feature folder with `--work-mode minor-audit`,
 - delegate minimal-audit plan creation to `atomic_planner` with `DIRECTIVE: MINIMAL-AUDIT PLAN REQUIRED`,
-- require `atomic_executor` preflight until `PREFLIGHT: ALL CLEAR`,
+- require single-pass `atomic_executor` preflight ending in `PREFLIGHT: ALL CLEAR` (at most one return to the planner),
 - execute Phase 0 only via atomic_executor before branching,
 - run reduced small-audit after implementation and QC.
 
@@ -69,7 +69,7 @@ In all modes, per-batch budget remains: at most **3 production files** and **3 t
 When `csharp-typed-engineer` runs in orchestrator handoff mode, it must execute the following delegation chain and must not bypass it with direct implementation:
 
 1. Delegate to `atomic_planner` for an architecture plus testability plan only (no edits).
-2. Require planner output to include final `PREFLIGHT: ALL CLEAR` from the preflight validation loop.
+2. Require planner output to include final `PREFLIGHT: ALL CLEAR` from single-pass preflight (at most one return to the planner).
 3. Delegate plan execution to `atomic_executor`.
 4. Delegate the final QA gate to `atomic_executor` per `csharp-qa-gate`.
 5. Delegate post-implementation review to `feature-review` per `feature-review-workflow`.

package/resources/claude-customizations/.claude/skills/epic-orchestrate/SKILL.md

@@ -126,7 +126,14 @@ function of the DAG.
    `mcp__drm-copilot__collect_pr_context`. `epic-orchestrator` runs the same S9 CI-green
    procedure (`pwsh -NoProfile -File .claude/lib/ci-gate/Invoke-CiGateParser.ps1`) directly against this PR, records
    the result under the epic checkpoint's `epic_merge_pr` object, then executes
-   `gh pr merge --merge` once green, gated by `enforce-epic-merge-gate.ps1`.
+   `gh pr merge --merge` once green, gated by `enforce-epic-merge-gate.ps1`. Under a merge queue
+   on `main`, `gh pr merge` can return before the merge happens, so
+   `epic_merge_pr.merge_commit_sha` is recorded only after the merge is confirmed by polling and
+   ancestry check, using the confirmation procedure of step 3 of
+   `## Per-Item Merge to Main (Merge-on-Green)` in `.claude/skills/parallel-orchestrate/SKILL.md`
+   with `main` as the base branch; each pull-request snapshot is classified with
+   `pwsh -NoProfile -File .claude/lib/ci-gate/Invoke-MergeConfirmationParser.ps1 -PrJson <snapshot-json> -AsJson`
+   (issue #952).
 
 ## Merge-on-Green Kickoff Parameter
 
@@ -138,7 +145,9 @@ the literal epic-mode kickoff line:
 The child's own `orchestrator`, on reading this line, records `epic_mode: true` and
 `epic_context: { epic_feature_folder, integration_branch, epic_checkpoint_path }` at its first
 checkpoint write, and on CI-green (S9 step 6) merges its own PR into the integration branch,
-recording `epic_merge: { merge_commit_sha, target_branch, merged_at }`. Standalone (non-epic)
+recording `epic_merge: { merge_commit_sha, target_branch, merged_at }`. The child records
+`epic_merge` only after the merge is confirmed by polling and ancestry check against
+`origin/<integration_branch>` (S9 step 6). Standalone (non-epic)
 orchestration is unchanged: `epic_mode` absent or `false` makes S9 step 6 a no-op.
 
 The run gates `enforce-orchestration-preimplementation-gate.ps1` and `enforce-epic-wave-barrier.ps1` locate the epic checkpoint by the `integration_branch:` value of this line. They select the live worktree whose `artifacts/orchestration/epic-orchestrator-state.json` records `route_id` `epic` and that integration branch, prefer the worktree that has the branch checked out when more than one records it, and deny the delegation with `TARGET_WORKTREE_NOT_DERIVABLE` or `TARGET_WORKTREE_AMBIGUOUS` when none or more than one remains. A stale copy of the epic checkpoint is moved to `artifacts/orchestration/handoff/` rather than left at a worktree root. The child run's own delegations to implementation agents carry the canonical issue-number line and `branch:` label defined in `.claude/skills/orchestrate/SKILL.md` `## Issue Number Consistency`.
@@ -353,7 +362,7 @@ that same call at the completion gate. The validation is implemented in
 
 1. Every feature in the manifest has `merge_status` in `{merged, worktree_removed}`.
 2. The final integration-to-`main` PR has merged and `epic_merge_pr.merge_commit_sha` is
-   recorded.
+   recorded, and it is recorded only after the merge is confirmed by polling and ancestry check.
 3. `docs/features/epics/<epic-slug>/epic-status.md` reflects the completed state.
 4. The epic checkpoint passes `validate_epic_orchestrator_state_text` with
    `require_complete=True`.