@danmoisan/drm-copilot-mcp 1.1.22 → 1.1.23

package/resources/claude-customizations/.claude/lib/worktree-resolution/WorktreeRunRecordPath.psm1

@@ -0,0 +1,185 @@
+<#
+.SYNOPSIS
+    Shared comparison of a recorded worktree_path with a removal target (issue #995).
+
+.DESCRIPTION
+    A run checkpoint records items[].worktree_path or features[].worktree_path either as
+    an absolute path or relative to the main checkout. Every site that compares such a
+    record to the absolute path a command names calls Test-WorktreeRunRecordedPathMatchesTarget,
+    so a relative record is joined to the same base roots everywhere and no site carries
+    its own normalise-and-compare.
+
+    A rooted record is compared to the target with Test-WorktreeRunPathEqual. A relative
+    record is joined to each non-blank base root and compared the same way. A relative
+    record that is blank, is . or .., has a . or .. segment, or contains : matches
+    nothing, so it can never name the main checkout or a path outside it.
+
+.NOTES
+    PowerShell 7+. Exports Test-WorktreeRunPathEqual, Test-WorktreeRunRecordedPathMatchesTarget,
+    Get-WorktreeRunRecordBaseRoot, and Get-WorktreeRunMainCheckoutRoot. The two comparison
+    functions and Get-WorktreeRunRecordBaseRoot are pure. Get-WorktreeRunMainCheckoutRoot
+    reads the filesystem only through its siblings' seams (Get-WorktreeItemLiveRoot and
+    Get-WorktreeResolutionGitEntryKind). Mirrored byte-identically.
+    CONVENTION: this module fails fast at module scope and imports its siblings with -ErrorAction Stop.
+#>
+
+Set-StrictMode -Version Latest
+$ErrorActionPreference = 'Stop'
+
+Import-Module (Join-Path $PSScriptRoot 'WorktreeResolution.psm1') -ErrorAction Stop
+Import-Module (Join-Path $PSScriptRoot 'WorktreeItemResolution.psm1') -ErrorAction Stop
+
+# A drive-rooted, slash-rooted, or // (UNC) path; anything else is relative to some directory.
+# The same pattern as $script:AbsolutePathPattern in WorktreeRunResolution.psm1.
+$script:AbsolutePathPattern = '^([A-Za-z]:(/|$)|/)'
+
+# The administrative entry that is a directory only in the main checkout; a linked
+# worktree carries a .git file instead.
+$script:GitEntryName = '.git'
+
+# Private (moved from WorktreeRunResolution.psm1 for issue #995): compare two worktree
+# paths, insensitive to separator style and trailing slashes, and case-insensitive for
+# drive-letter and UNC (//) paths.
+function Test-WorktreeRunPathEqual {
+    <#
+    .SYNOPSIS
+        Compare two worktree paths for equality.
+    .DESCRIPTION
+        Pure. Insensitive to separator style and trailing slashes; ordinal for single-slash
+        POSIX roots and ordinal-ignore-case for drive-letter and UNC (//) roots. A blank
+        side never matches.
+    .PARAMETER Left
+        One path.
+    .PARAMETER Right
+        The other path.
+    #>
+    [CmdletBinding()]
+    [OutputType([bool])]
+    param(
+        [Parameter(Mandatory = $true)] [AllowNull()] [AllowEmptyString()] [string] $Left,
+        [Parameter(Mandatory = $true)] [AllowNull()] [AllowEmptyString()] [string] $Right
+    )
+
+    if ([string]::IsNullOrWhiteSpace($Left) -or [string]::IsNullOrWhiteSpace($Right)) { return $false }
+    $a = ($Left.Trim() -replace '\\', '/').TrimEnd('/')
+    $b = ($Right.Trim() -replace '\\', '/').TrimEnd('/')
+    $isCaseInsensitivePath = ($a -match '^([A-Za-z]:|//)') -or ($b -match '^([A-Za-z]:|//)')
+    $comparison = if ($isCaseInsensitivePath) { [System.StringComparison]::OrdinalIgnoreCase } else { [System.StringComparison]::Ordinal }
+    return [string]::Equals($a, $b, $comparison)
+}
+
+# Private: whether a relative recorded path (already slash-normalised) is safe to join.
+function Test-WorktreeRunRelativeRecordSafe {
+    [CmdletBinding()]
+    [OutputType([bool])]
+    param(
+        [Parameter(Mandatory = $true)] [AllowEmptyString()] [string] $Path
+    )
+
+    if ([string]::IsNullOrWhiteSpace($Path) -or $Path.Contains(':')) { return $false }
+    foreach ($segment in $Path.TrimEnd('/').Split('/')) {
+        if ($segment -eq '.' -or $segment -eq '..') { return $false }
+    }
+    return ($Path.TrimEnd('/').Length -gt 0)
+}
+
+function Test-WorktreeRunRecordedPathMatchesTarget {
+    <#
+    .SYNOPSIS
+        Report whether a recorded worktree_path names the removal target.
+    .DESCRIPTION
+        Pure. A rooted record (drive-letter, single-slash, or // after backslash-to-slash
+        normalisation) matches when Test-WorktreeRunPathEqual holds against the target. A
+        relative record matches when it is safe and Test-WorktreeRunPathEqual holds for
+        its join to at least one non-blank base root. A relative record that is blank, is
+        . or .., has a . or .. segment, or contains : matches nothing, as does a blank target.
+    .PARAMETER RecordedPath
+        The worktree_path a checkpoint records, absolute or relative.
+    .PARAMETER TargetPath
+        The absolute path the command names.
+    .PARAMETER BaseRoot
+        Optional. The roots a relative record is joined to: the main checkout root and the
+        root that holds the checkpoint. With none, a relative record matches nothing.
+    #>
+    [CmdletBinding()]
+    [OutputType([bool])]
+    param(
+        [Parameter(Mandatory = $true)] [AllowNull()] [AllowEmptyString()] [string] $RecordedPath,
+        [Parameter(Mandatory = $true)] [AllowNull()] [AllowEmptyString()] [string] $TargetPath,
+        [AllowNull()] [AllowEmptyCollection()] [string[]] $BaseRoot = @()
+    )
+
+    if ([string]::IsNullOrWhiteSpace($RecordedPath) -or [string]::IsNullOrWhiteSpace($TargetPath)) { return $false }
+    $recorded = $RecordedPath.Trim() -replace '\\', '/'
+    if ($recorded -match $script:AbsolutePathPattern) {
+        return (Test-WorktreeRunPathEqual -Left $recorded -Right $TargetPath)
+    }
+    if (-not (Test-WorktreeRunRelativeRecordSafe -Path $recorded)) { return $false }
+    foreach ($root in @($BaseRoot)) {
+        if ([string]::IsNullOrWhiteSpace($root)) { continue }
+        $joined = (($root.Trim() -replace '\\', '/').TrimEnd('/')) + '/' + $recorded.TrimEnd('/')
+        if (Test-WorktreeRunPathEqual -Left $joined -Right $TargetPath) { return $true }
+    }
+    return $false
+}
+
+function Get-WorktreeRunRecordBaseRoot {
+    <#
+    .SYNOPSIS
+        Return the base roots a relative recorded worktree_path is joined to.
+    .DESCRIPTION
+        Pure. The main checkout root and the root that holds the checkpoint a read
+        resolved (Read.Target.WorktreeRoot), with blank entries dropped. Every gate
+        passes the result to Test-WorktreeRunRecordedPathMatchesTarget as -BaseRoot.
+    .PARAMETER MainRoot
+        The main checkout root, or $null when none was derived.
+    .PARAMETER Read
+        A run-checkpoint read result carrying Target.WorktreeRoot, or $null.
+    .OUTPUTS
+        System.String[]
+    #>
+    [CmdletBinding()]
+    [OutputType([string[]], [object[]])]
+    param(
+        [AllowNull()][AllowEmptyString()][string] $MainRoot,
+        [AllowNull()] $Read
+    )
+
+    $readRoot = $null
+    if ($null -ne $Read -and @($Read.PSObject.Properties.Name) -contains 'Target' -and $null -ne $Read.Target -and @($Read.Target.PSObject.Properties.Name) -contains 'WorktreeRoot') {
+        $readRoot = [string] $Read.Target.WorktreeRoot
+    }
+    return , [string[]] @(@($MainRoot, $readRoot) | Where-Object { -not [string]::IsNullOrWhiteSpace($_) })
+}
+
+function Get-WorktreeRunMainCheckoutRoot {
+    <#
+    .SYNOPSIS
+        Return the main checkout root reachable from a session path, or $null.
+    .DESCRIPTION
+        The first live root whose .git entry is a directory; a linked worktree's .git entry
+        is a file. Reads the filesystem only through Get-WorktreeItemLiveRoot and
+        Get-WorktreeResolutionGitEntryKind, the seams a test mocks.
+    .PARAMETER SessionRoot
+        The calling process's path, used only to find the repository.
+    #>
+    [CmdletBinding()]
+    [OutputType([string])]
+    param(
+        [Parameter(Mandatory = $true)] [AllowEmptyString()] [string] $SessionRoot
+    )
+
+    $liveRoots = Get-WorktreeItemLiveRoot -SessionRoot $SessionRoot
+    foreach ($root in $liveRoots) {
+        if ([string]::IsNullOrWhiteSpace($root)) { continue }
+        $gitEntry = (($root -replace '\\', '/').TrimEnd('/')) + '/' + $script:GitEntryName
+        if ((Get-WorktreeResolutionGitEntryKind -Path $gitEntry) -eq 'Directory') { return $root }
+    }
+    return $null
+}
+
+Export-ModuleMember -Function `
+    Test-WorktreeRunPathEqual, `
+    Test-WorktreeRunRecordedPathMatchesTarget, `
+    Get-WorktreeRunRecordBaseRoot, `
+    Get-WorktreeRunMainCheckoutRoot

package/resources/claude-customizations/.claude/lib/worktree-resolution/WorktreeRunResolution.psm1

@@ -31,6 +31,7 @@ $ErrorActionPreference = 'Stop'
 Import-Module (Join-Path $PSScriptRoot 'WorktreeResolution.psm1') -ErrorAction Stop
 Import-Module (Join-Path $PSScriptRoot 'WorktreeTargetResolution.psm1') -ErrorAction Stop
 Import-Module (Join-Path $PSScriptRoot 'WorktreeItemResolution.psm1') -ErrorAction Stop
+Import-Module (Join-Path $PSScriptRoot 'WorktreeRunRecordPath.psm1') -ErrorAction Stop
 
 # The run checkpoint locations relative to a worktree root.
 $script:EpicCheckpointRelativePath = 'artifacts/orchestration/epic-orchestrator-state.json'
@@ -339,24 +340,6 @@ function Resolve-WorktreeParallelTarget {
     return (Resolve-WorktreeRunMatch -Matched $matched.ToArray() -SessionRoot $SessionRoot -Description ("parallel_slug '{0}'" -f $ParallelSlug))
 }
 
-# Private: compare two worktree paths, insensitive to separator style and trailing
-# slashes, and case-insensitive for drive-letter and UNC (//) paths.
-function Test-WorktreeRunPathEqual {
-    [CmdletBinding()]
-    [OutputType([bool])]
-    param(
-        [Parameter(Mandatory = $true)] [AllowNull()] [AllowEmptyString()] [string] $Left,
-        [Parameter(Mandatory = $true)] [AllowNull()] [AllowEmptyString()] [string] $Right
-    )
-
-    if ([string]::IsNullOrWhiteSpace($Left) -or [string]::IsNullOrWhiteSpace($Right)) { return $false }
-    $a = ($Left.Trim() -replace '\\', '/').TrimEnd('/')
-    $b = ($Right.Trim() -replace '\\', '/').TrimEnd('/')
-    $isCaseInsensitivePath = ($a -match '^([A-Za-z]:|//)') -or ($b -match '^([A-Za-z]:|//)')
-    $comparison = if ($isCaseInsensitivePath) { [System.StringComparison]::OrdinalIgnoreCase } else { [System.StringComparison]::Ordinal }
-    return [string]::Equals($a, $b, $comparison)
-}
-
 # Private: compare two pull request numbers as integers.
 function Test-WorktreeRunPrNumberEqual {
     [CmdletBinding()]
@@ -373,6 +356,8 @@ function Test-WorktreeRunPrNumberEqual {
 }
 
 # Private: whether a parsed run checkpoint records a pull request number or worktree path.
+# A worktree_path record is compared through the shared matcher, so a relative record is
+# joined to each BaseRoot (issue #995); with no BaseRoot a relative record matches nothing.
 function Test-WorktreeRunCheckpointRecord {
     [CmdletBinding()]
     [OutputType([bool])]
@@ -380,7 +365,8 @@ function Test-WorktreeRunCheckpointRecord {
         [Parameter(Mandatory = $true)] [pscustomobject] $Checkpoint,
         [Parameter(Mandatory = $true)] [ValidateSet('epic', 'parallel')] [string] $Kind,
         [Parameter(Mandatory = $true)] [ValidateSet('pr_number', 'worktree_path')] [string] $RecordField,
-        [Parameter(Mandatory = $true)] [string] $Value
+        [Parameter(Mandatory = $true)] [string] $Value,
+        [AllowNull()] [AllowEmptyCollection()] [string[]] $BaseRoot = @()
     )
 
     $values = [System.Collections.Generic.List[object]]::new()
@@ -397,7 +383,7 @@ function Test-WorktreeRunCheckpointRecord {
         if ($RecordField -eq 'pr_number') {
             if (Test-WorktreeRunPrNumberEqual -Recorded $recorded -Expected ([long] $Value)) { return $true }
         }
-        elseif (Test-WorktreeRunPathEqual -Left ([string] $recorded) -Right $Value) { return $true }
+        elseif (Test-WorktreeRunRecordedPathMatchesTarget -RecordedPath ([string] $recorded) -TargetPath $Value -BaseRoot $BaseRoot) { return $true }
     }
     return $false
 }
@@ -438,11 +424,15 @@ function Resolve-WorktreeRunTargetByRecord {
                 'the command names no usable {0}, so the {1} run it belongs to cannot be identified' -f $RecordField, $Kind))
     }
     $needle = $Value.Trim()
+    # A relative worktree_path record is joined to the main checkout root and to the root
+    # holding the checkpoint (issue #995); the main root is derived once, and only for paths.
+    $mainRoot = if ($RecordField -eq 'worktree_path') { Get-WorktreeRunMainCheckoutRoot -SessionRoot $SessionRoot } else { $null }
     $matched = [System.Collections.Generic.List[string]]::new()
     foreach ($root in (Get-WorktreeRunLiveRoot -SessionRoot $SessionRoot)) {
         $checkpoint = Get-WorktreeRunCheckpoint -Kind $Kind -WorktreeRoot $root
         if ($null -eq $checkpoint) { continue }
-        if (Test-WorktreeRunCheckpointRecord -Checkpoint $checkpoint -Kind $Kind -RecordField $RecordField -Value $needle) { $matched.Add($root) }
+        $baseRoot = [string[]] @(@($mainRoot, $root) | Where-Object { -not [string]::IsNullOrWhiteSpace($_) })
+        if (Test-WorktreeRunCheckpointRecord -Checkpoint $checkpoint -Kind $Kind -RecordField $RecordField -Value $needle -BaseRoot $baseRoot) { $matched.Add($root) }
     }
     return (Resolve-WorktreeRunMatch -Matched $matched.ToArray() -SessionRoot $SessionRoot -Description $description)
 }

package/resources/claude-customizations/.claude/rules/general-code-change.md

@@ -46,7 +46,10 @@ Mutation testing and golden tests run in pre-merge or nightly pipelines, not the
 
 ## File Size Limit
 
-- No production code, test code, or reusable script file may exceed **500 lines**.
+- File size follows three tiers for production code, test code, and reusable script files, counted in logical lines (a trailing line terminator does not add a line):
+  - **500 lines (guidance):** look for a logical way to divide the file into multiple files, provided the parts can be separated logically. No gate fails at this tier.
+  - **700 lines (advisory):** look for a split more aggressively. Reviewers and `feature-review` report a non-blocking Warning for a file at or above 700 lines. No gate fails at this tier.
+  - **Above 800 lines (hard block):** split the file regardless of logical separability. The repository CI check and the PreToolUse hook block a file of 801 lines or more; a file of exactly 800 lines passes. Legacy files above 800 lines are listed in `config/file-size-baseline.json` and may shrink (with the entry tightened) or stay the same size, but may not grow.
 - Exceptions: temporary throwaway scripts created and deleted within an agent session; raw text fixtures for language-processing test data; Markdown documentation files.
 
 ## Error Handling and Logging

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,7 @@ 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`.

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

@@ -686,5 +686,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"

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

@@ -571,8 +571,8 @@ and is prohibited by this skill, which is the term the residual rests on.
 - `.claude/skills/pr-context-artifacts/SKILL.md` — how the PR-context bundle is collected
   and the base-branch resolution rules.
 - `.claude/rules/shell.md` — the bash toolchain (shfmt/shellcheck/bats/kcov), the
-  500-line cap, the no-temp-files test policy, and the `CLEANUP_WT_GIT_BIN` seam
-  convention.
+  reference to the tiered file-size policy, the no-temp-files test policy, and the
+  `CLEANUP_WT_GIT_BIN` seam convention.
 - `.claude/skills/feature-promotion-lifecycle/SKILL.md` — the potential-entry-to-issue
   promotion path used by the Dirty Worktree Triage Procedure's step 9 for `PRESERVE`
   findings that describe unresolved product scope.

package/resources/claude-customizations/.claude/skills/execution-environment/SKILL.md

@@ -122,7 +122,7 @@ These pass every validator rule and are found only by reading the plan against t
 - Python: measure a module with `--cov=<dotted.module>`, `--cov-branch`, `--cov-report=term-missing`, and `--cov-report=json:<path>`; read branch figures from the JSON report.
 - TypeScript: a new production file needs its own entry in the `coverageThreshold` map of `extensions/drm-copilot/jest.config.cjs`; Jest runs through `node run-jest.cjs` in `extensions/drm-copilot/`.
 - PowerShell: per-file line coverage is read from `artifacts/pester/powershell-coverage.xml` written by the self-hosted PoshQC module.
-- No production, test, or reusable script file exceeds 500 physical lines; Markdown is exempt. Files at or near the limit are not extended; new logic goes into a new module and a new test file.
+- File size follows three tiers for production, test, and reusable script files, counted in logical lines (a trailing terminator adds no line): at 500 lines look for a logical split (guidance); at 700 lines split more aggressively, and reviewers report a non-blocking Warning (advisory); above 800 lines a split is enforced regardless of logical separability (hard limit; exactly 800 passes). The hard limit is enforced by `tests/scripts/ci/FileSizePolicy.RepoGate.Tests.ps1` in the existing PowerShell shards against `config/file-size-baseline.json`, where legacy files above 800 may shrink (with the entry tightened) or stay equal but may not grow, and by the PreToolUse hook `.claude/hooks/enforce-file-size-limit.ps1` (`.codex/hooks/enforce-file-size-limit.ps1`). New logic in a file near a tier goes into a new module and a new test file. Markdown is exempt.
 
 ## Test Isolation Checks
 

package/resources/claude-customizations/.claude/skills/feature-promotion-lifecycle/SKILL.md

@@ -47,6 +47,7 @@ When the GitHub issue already exists (it was transferred, filed before orchestra
 1. Verify the issue read-only with `gh issue view`, a `gh api` GET request, or a GitHub MCP issue read, and use its number as `${issue-num}`.
 2. Record a top-level `issue_adoption` object in the orchestrator checkpoint (`issue_num`, `issue_url`, `origin`, `verified_via`, `verified_at`, `evidence`, `waived_tools`, and, when a promotion-entry tool is waived, `potential_record`). For that waiver `potential_record` is required when `origin` is `epic_decomposition`, optional when `origin` is `transferred` or `filed_before_orchestration`, and validated whenever it is present. A valid record waives the `potential_to_issue` receipt requirement at completion.
 3. `delegation_receipts.promotion.issue` may be omitted, because no promotion receipt exists for an adopted issue.
+4. When the item's feature folder was already created and committed before this run, do not call `new_active_feature_folder` a second time. Confirm the folder read-only (`git cat-file -t HEAD:<feature-folder>` prints `tree`), list `new_active_feature_folder` in `waived_tools`, and record `issue_adoption.feature_folder_record` with `path` equal to the checkpoint `feature-folder`, `verified_via` (`git_cat_file_head` or `git_ls_tree_head`), `verified_at`, and `evidence`. The Claude stop hook re-checks that `HEAD` holds the folder.
 
 The field rules, the closed set of waivable tools, and the fail-closed behavior are defined in `.claude/rules/orchestrator-state.md` under `## Invariants (issue_adoption object)`.
 

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

@@ -194,7 +194,7 @@ The mandatory sequence is:
 
 1. The orchestrator first refreshes the PR-context artifact via `mcp__drm-copilot__collect_pr_context` (or the equivalent context-collection mechanism), which writes `artifacts/pr_context.summary.txt`.
 2. The orchestrator runs the orchestrator-state validator (`mcp__drm-copilot__validate_orchestration_artifacts` or the equivalent repository-local validator CLI documented in `.claude/rules/orchestrator-state.md`) against `artifacts/orchestration/orchestrator-state.json --require-pr-creation-ready` and records the pass/fail result under a new `pr_author_preflight` field in the checkpoint, alongside `pr_author_receipt`: `{status ("pass"|"fail"), checked_at (ISO-8601 UTC), checkpoint_path, validator_command, output_summary}`. The orchestrator must not delegate to `Agent(pr-author)` when this preflight fails. The validator's full-lifecycle completion flag (`ci_gate`/`pr_gate`/routing-contract receipts) remains reserved for the post-PR/CI completion context (Step S9 / PR Creation Gate condition 6), not this pre-PR-creation preflight, because those values cannot exist before the first `gh pr create` of a branch.
-3. The orchestrator then delegates PR creation and any PR body edits to `Agent(pr-author)`. The `pr-author` agent runs the `pr-author` skill to author the body, writes the body file `artifacts/pr_body_<N>.md` and the sibling receipt `artifacts/pr_body_<N>.receipt.json` with the shape `{skill, pr_body_path, number, sha256 (lowercase hex of the body bytes), context_summary_path, created_at (ISO-8601 UTC, strictly newer than `artifacts/pr_context.summary.txt` last-write)}`, issues `gh pr create --body-file artifacts/pr_body_<N>.md` (or `gh pr edit --body-file ...`), and reports the resulting PR URL or PR number.
+3. The orchestrator then delegates PR creation and any PR body edits to `Agent(pr-author)`. The `pr-author` agent runs the `pr-author` skill to author the body, writes the body file `artifacts/pr_body_<N>.md` and the sibling receipt `artifacts/pr_body_<N>.receipt.json` with the shape `{skill, pr_body_path, number, sha256 (lowercase hex of the body bytes), context_summary_path, created_at (ISO-8601 UTC, strictly newer than `artifacts/pr_context.summary.txt` last-write)}`, issues `gh pr create --body-file artifacts/pr_body_<N>.md` (or `gh pr edit --body-file ...`), and reports the resulting PR URL or PR number. The delegation prompt MUST carry, on its own line, `Author-asserted autoclose issues: #<issue-num>`, where `<issue-num>` is the checkpoint `issue-num`, so the PR body emits `- Closes #<issue-num>` and the issue closes on merge. The line is omitted only when the checkpoint records no `issue-num`, or when `epic_mode` is true (an epic child whose integration PR owns the closing keyword). In every other case the `enforce-model-routing-receipt.ps1` Agent PreToolUse hook denies the `Agent(pr-author)` delegation with `MODEL_ROUTING_RECEIPT_BLOCKED: AUTHOR_ASSERTED_AUTOCLOSE_MISSING`.
 4. The orchestrator records `pr_author_receipt` in the checkpoint, citing the body-file path and the receipt path that were verified.
 
 When the pr-author agent runs outside the item worktree (its process directory is not the worktree that holds the item's `artifacts/` tree), it passes the absolute canonical path `<item worktree>/artifacts/pr_body_<N>.md` to `--body-file`. The `enforce-pr-author-skill.ps1` hook resolves the item worktree from `--head` and reads the PR context summary, the body, and the receipt beneath it; in that topology it denies a relative `--body-file` with `PR_BODY_PATH_NONCANONICAL`, because `gh` would read the relative path from its own process directory.
@@ -312,6 +312,7 @@ S9 procedure:
 4. Poll with a bounded interval and a documented total timeout while `conclusion == "pending"`. When the timeout is exhausted, record the timeout as a finding with `Remediability: awaiting_ci` in `remediation-inputs.<timestamp>.md` and follow the wait branch in Post-Review Outcome Evaluation (`blocked_reason: "awaiting_ci"`, `next_step: "S9_ci_green"`); `step9_status` stays `pending`. A poll timeout does not enter the remediation loop.
 5. Write the `ci_gate` object and `last_verified_ci_sha` to the checkpoint, and set `step9_status` to `passed` only when `ci_gate.conclusion == "success"` AND `ci_gate.head_sha` equals the current PR head SHA.
 6. If the checkpoint's `epic_mode` is `true`, execute `gh pr merge --merge <PR>` merging the feature branch into `epic_context.integration_branch` (already the PR's base branch per the epic-mode `--base` override applied at S8). On success, record `epic_merge: { merge_commit_sha, target_branch, merged_at }` in the checkpoint. On failure due to merge conflict (non-mergeable PR), do not retry blindly: convert the conflict into a synthetic Blocking finding per "Merge-Conflict Remediation" below and re-enter the standard R1–R5 remediation loop; do not proceed to DONE. Merge confirmation (issue #952): a zero exit from `gh pr merge` does not prove a merge when the base branch uses a merge queue, so `epic_merge.merge_commit_sha` is recorded only after the merge is confirmed by polling and ancestry check. Read the pull-request state every 30 seconds, for at most 90 minutes, with the `gh api graphql` query and `.claude/lib/ci-gate/Invoke-MergeConfirmationParser.ps1` exactly as step 3 of `## Per-Item Merge to Main (Merge-on-Green)` in `.claude/skills/parallel-orchestrate/SKILL.md` defines them; on `merged`, run `git fetch origin <integration_branch>` and confirm that `git merge-base --is-ancestor <merge-commit-oid> origin/<integration_branch>` exits 0 before recording `epic_merge`. When the 90 minutes are exhausted, record a finding naming `awaiting_merge_queue` with `Remediability: awaiting_ci` in `remediation-inputs.<timestamp>.md` and follow the wait branch (`blocked_reason: "awaiting_ci"`, `next_step: "S9_ci_green"`). A `not_queued` outcome whose `mergeable` value is `CONFLICTING` follows "Merge-Conflict Remediation"; any other `not_queued` outcome enters `## Remediation Loop — CI-Failure Handling`; a `closed` outcome halts the run with a failure. `gh pr merge` is never re-issued in a loop after `not_queued`.
+7. Standalone merge-on-green (issue #997). This step applies only when the checkpoint's `epic_mode` is absent or `false`, no `Parallel mode: true` marker was supplied in the kickoff, the route requires S9 (the `preparation` route never merges), and the PR base branch is `main`. After step 5 records `step9_status: "passed"` and after every CI-dependent acceptance criterion is checked off and S9 has re-run against the final head, execute `gh pr merge --merge <PR> --match-head-commit <ci_gate.head_sha>`. The merge gate (`.claude/hooks/enforce-epic-merge-gate.ps1`) allows this command through its green-CI branch only when the checkpoint records `pr_gate.pr_number` equal to `<PR>` and the live PR head equals `ci_gate.head_sha`. A zero exit does not prove a merge: confirm it with the step 3 procedure of `## Per-Item Merge to Main (Merge-on-Green)` in `.claude/skills/parallel-orchestrate/SKILL.md` (the `gh api graphql` query and `.claude/lib/ci-gate/Invoke-MergeConfirmationParser.ps1` every 30 seconds for at most 90 minutes; on `merged`, `git fetch origin main` and `git merge-base --is-ancestor <merge-commit-oid> origin/main` exiting 0). Record `pr_merge: { merge_commit_sha, target_branch, merged_at }` in the checkpoint only after that confirmation. Exhausted polling, `not_queued`, and `closed` outcomes are handled as in step 6, and `gh pr merge` is never re-issued in a loop after `not_queued`. A parallel item never merges itself: the parallel parent performs every item merge, and the child records `parallel_mode: true` so the gate declines. The merge gate's parallel exclusion is best-effort, because the `Parallel mode: true` marker is not visible to a Bash hook, so this step relies on the kickoff marker as well as on the gate.
 
 CI-dependent acceptance criteria: when the item has acceptance criteria whose verification requires the result of CI on the PR head, the item's own orchestrator run owns their check-off, and a parent or coordinating session never commits them from its own root. After step 5 records `ci_gate.conclusion == "success"`, check off each CI-dependent criterion in the item's own worktree, commit, push to the PR branch, and re-run S9 from step 1 against the new head SHA, so that `ci_gate.head_sha` equals the final PR head before DONE. In epic mode this completes before step 6 merges. A failed re-run enters `## Remediation Loop — CI-Failure Handling` below; the shared `remediation_loop.completed_attempts` count and its halt after three completed attempts are unchanged.
 
@@ -333,6 +334,12 @@ The orchestrator checkpoint (`artifacts/orchestration/orchestrator-state.json`)
   - `merge_commit_sha` — the merge commit SHA produced by merging the feature branch into `epic_context.integration_branch`.
   - `target_branch` — the integration branch the feature branch was merged into.
   - `merged_at` — ISO-8601 timestamp of when S9 step 6 recorded the merge.
+- a top-level `pr_merge` object (populated only by a standalone S9 step 7 merge, issue #997) containing:
+  - `merge_commit_sha` — the merge commit SHA confirmed on `main`.
+  - `target_branch` — the base branch the pull request merged into (`main`).
+  - `merged_at` — ISO-8601 timestamp of when S9 step 7 recorded the confirmed merge.
+
+  Like `epic_merge`, `pr_merge` is not read by any validator; it is an unvalidated record.
 
 Illustrative shape:
 
@@ -376,9 +383,9 @@ The orchestrator must not create a PR, push a branch for PR purposes, or report
 4. The checkpoint `next_step` is `S8_create_pr` (precondition to entering S9).
 5. PR body produced via the pr-author handoff: `artifacts/pr_body_<N>.md` exists with a matching `artifacts/pr_body_<N>.receipt.json`, created with `--body-file`.
 6. `ci_gate.conclusion == "success"` AND `ci_gate.head_sha == current head SHA of the PR branch`. DONE is not written while either sub-condition is false.
-7. `epic_mode` is `false`, OR (`epic_mode` is `true` AND the integration-branch merge (`gh pr merge --merge`) has completed and `epic_merge.merge_commit_sha` is recorded in the checkpoint). `epic_merge.merge_commit_sha` is recorded only after the merge is confirmed by polling and ancestry check (S9 step 6).
+7. `epic_mode` is `false`, OR (`epic_mode` is `true` AND the integration-branch merge (`gh pr merge --merge`) has completed and `epic_merge.merge_commit_sha` is recorded in the checkpoint). `epic_merge.merge_commit_sha` is recorded only after the merge is confirmed by polling and ancestry check (S9 step 6). In a standalone run whose route requires S9 (issue #997), DONE additionally requires `pr_merge.merge_commit_sha`, recorded only after the S9 step 7 merge is confirmed; the `preparation` route never merges.
 
-This gate is non-negotiable. Each condition is independently verified before PR creation proceeds. Conditions 1-4 are unchanged from the prior contract; conditions 5-7 (receipt handoff, CI-green gate, and epic-mode merge-on-green gate) are additive.
+This gate is non-negotiable. Each condition is independently verified before PR creation proceeds. Conditions 1-4 are unchanged from the prior contract; conditions 5-7 (receipt handoff, CI-green gate, and epic-mode merge-on-green gate, with the standalone merge of S9 step 7 for a standalone run) are additive.
 
 ## Step 6 Delegation — Prohibited Prompt Language
 
@@ -459,6 +466,6 @@ Example:
 
 The validator counts an MCP receipt as successful only when `tool` is a non-empty string, `ok` is exactly `true`, and `evidence` is a non-empty string. Every `required_mcp_tools` entry must have such a receipt unless a valid `issue_adoption` record waives it.
 
-When the GitHub issue already exists before orchestration starts (transferred, filed by hand, or created by epic decomposition) and has been verified read-only (`gh issue view`, a `gh api` GET, or a GitHub MCP issue read), do not call `potential_to_issue`. Record a top-level `issue_adoption` object in the checkpoint instead of a `potential_to_issue` receipt. It may waive only `potential_to_issue` and the checkpoint's promotion-entry tool (`new_potential_entry`, or `new_potential_bug_entry` for a bug-type checkpoint); `potential_to_issue` must always be listed. For a promotion-entry waiver, `potential_record` (a markdown path under `docs/features/potential/`) is required when `origin` is `epic_decomposition`, optional when `origin` is `transferred` or `filed_before_orchestration`, and validated whenever it is present. Every other required tool still needs a successful receipt. Any adoption error waives nothing. The field rules, the closed waivable set, and the error placement are defined in `.claude/rules/orchestrator-state.md` under `## Invariants (issue_adoption object)`.
+When the GitHub issue already exists before orchestration starts (transferred, filed by hand, or created by epic decomposition) and has been verified read-only (`gh issue view`, a `gh api` GET, or a GitHub MCP issue read), do not call `potential_to_issue`. Record a top-level `issue_adoption` object in the checkpoint instead of a `potential_to_issue` receipt. It may waive only `potential_to_issue`, the checkpoint's promotion-entry tool (`new_potential_entry`, or `new_potential_bug_entry` for a bug-type checkpoint), and `new_active_feature_folder` with a valid `feature_folder_record` when the feature folder was already created and committed before this run (for example by a preparation child or an earlier session); `potential_to_issue` must always be listed. For a promotion-entry waiver, `potential_record` (a markdown path under `docs/features/potential/`) is required when `origin` is `epic_decomposition`, optional when `origin` is `transferred` or `filed_before_orchestration`, and validated whenever it is present. Every other required tool still needs a successful receipt. Any adoption error waives nothing. The field rules, the closed waivable set, and the error placement are defined in `.claude/rules/orchestrator-state.md` under `## Invariants (issue_adoption object)`.
 
 These three receipt arrays, populated with the retained required names of the selected route, are what allow the routing-contract validation under `require_complete: true` to pass.

package/resources/claude-customizations/.claude/skills/parallel-add/SKILL.md

@@ -70,7 +70,10 @@ re-derivation is mandatory and is not an optimization to skip when the checkpoin
    the issue was transferred), waiving potential_to_issue and the promotion-entry tool for the
    checkpoint's promotion-type. When a lifecycle record for the item exists under
    docs/features/potential/promoted/, cite it as potential_record.` The line is omitted for a
-   potential-entry item, whose child promotes it.
+   potential-entry item, whose child promotes it. The preparation child creates and commits the
+   item's feature folder, so the item's later execution child records `feature_folder_record` for
+   that committed folder instead of calling `new_active_feature_folder` again, per
+   `/parallel-orchestrate` kickoff element 4.
 
 3. **Compute conflict edges over ALL items, including in-flight ones.** Invoke the scheduling
    entry point Get-BlastRadiusConflictEdge from the destination-runtime PowerShell port