@danmoisan/drm-copilot-mcp 1.1.0 → 1.1.2

package/resources/claude-customizations/.claude/lib/blast-radius/BlastRadiusExtraction.psm1

@@ -44,6 +44,16 @@ Set-StrictMode -Version Latest
 # imports no sibling.
 Import-Module (Join-Path -Path $PSScriptRoot -ChildPath 'BlastRadiusGlob.psm1') -Force
 
+# Test-MultipleFeatureFolderSpan moved to BlastRadiusTokenShape.psm1, joining the
+# new Test-PlaceholderMarker predicate that could not be added here: this module
+# had two lines of headroom against the 500-line limit (issue #502). Both
+# predicates are context-free shape tests, so they form one cohesive leaf. The
+# import keeps every pre-existing call site and test source-compatible and
+# introduces no cycle, because the TokenShape module imports no sibling. This
+# follows the same re-import-and-re-export pattern used above for the relocated
+# ordinal-sort helper.
+Import-Module (Join-Path -Path $PSScriptRoot -ChildPath 'BlastRadiusTokenShape.psm1') -Force
+
 # Plan-structure patterns. The regex text mirrors the Python constants so radius
 # derivation and the plan validator can never disagree about which lines are
 # phase headings and which are tasks.
@@ -71,12 +81,6 @@ $script:KnownTopLevelSegment = @(
 # acceptance its unanchored form has; the token itself is recorded verbatim.
 $script:LineSuffixPattern = [regex]::new(':\d+$')
 
-# Documentation-corpus root and the index, counted after that prefix, of the
-# segment that names one feature folder. A glob whose wildcard reaches this
-# segment or any earlier one claims every feature folder in the corpus.
-$script:FeatureCorpusPrefix = 'docs/features/'
-$script:FeatureFolderSegmentIndex = 1
-
 # Fallback acceptance rule: a token shaped <segment>/.../<name>.<ext> counts as a
 # repository path when its final component carries one of these extensions.
 $script:RecognizedPathExtension = [System.Collections.Generic.HashSet[string]]::new(
@@ -233,60 +237,6 @@ function Get-InlineCodeToken {
     return @($token.ToArray())
 }
 
-function Test-MultipleFeatureFolderSpan {
-    <#
-    .SYNOPSIS
-        Report whether a glob claims more than one documentation feature folder.
-
-    .DESCRIPTION
-        Port of spans_multiple_feature_folders. The documentation corpus is laid
-        out as docs/features/<bucket>/<feature-folder>/..., so a glob whose
-        wildcard occupies or truncates the feature-folder segment claims every
-        feature folder in the corpus. That made two unrelated work items contend
-        purely because both wrote documentation (issue #489). A glob carrying a
-        complete, wildcard-free feature-folder segment claims one folder and is
-        retained.
-
-    .PARAMETER Token
-        A wildcard-bearing token already accepted by the shape rules of
-        Get-PathTokenKind.
-
-    .OUTPUTS
-        System.Boolean. True when the token is rooted in the documentation corpus
-        and its wildcard reaches the feature-folder segment or any earlier one.
-    #>
-    [CmdletBinding()]
-    [OutputType([bool])]
-    param(
-        [Parameter(Mandatory = $true)]
-        [AllowEmptyString()]
-        [string] $Token
-    )
-
-    if (-not $Token.StartsWith($script:FeatureCorpusPrefix,
-            [System.StringComparison]::Ordinal)) {
-        return $false
-    }
-
-    $segment = @($Token.Substring($script:FeatureCorpusPrefix.Length) -split '/')
-
-    # A token that stops at or before the feature-folder segment has had that
-    # segment truncated away by the wildcard, so it spans the whole corpus.
-    if ($segment.Count -le $script:FeatureFolderSegmentIndex) {
-        return $true
-    }
-
-    # Every segment up to and including the feature-folder name must be a literal
-    # for the claim to resolve to exactly one folder.
-    for ($index = 0; $index -le $script:FeatureFolderSegmentIndex; $index++) {
-        if ($segment[$index].IndexOf('*') -ge 0) {
-            return $true
-        }
-    }
-
-    return $false
-}
-
 function Get-PathTokenKind {
     <#
     .SYNOPSIS
@@ -300,6 +250,13 @@ function Get-PathTokenKind {
         drive. Acceptance then requires one of the two documented shape rules, a
         known top-level segment or a recognized final extension.
 
+        A token carrying any configured placeholder or interpolation marker is
+        rejected wherever the marker sits, because it documents a shape rather
+        than naming a file (issue #502). The rejection is silent and returns the
+        same null value the sibling rejections return: there is no diagnostic
+        channel and no finding rule, because a shape citation is not an error on
+        the author's part and reporting one would fire on almost every plan.
+
     .PARAMETER Token
         A single whitespace-free inline-code token.
 
@@ -337,6 +294,22 @@ function Get-PathTokenKind {
         }
     }
 
+    # A token carrying a placeholder or interpolation marker documents a shape
+    # rather than naming a file, so it is not a write claim (issue #502).
+    #
+    # Ordering, both directions. This runs AFTER the root-surface loop because
+    # that loop is exact ordinal equality against a configured surface name: a
+    # configured surface cannot contain a marker, so the two tests can never
+    # disagree, and putting the cheaper marker scan first would only add work to
+    # the common accepted case. It runs BEFORE the separator guard because a
+    # marker-bearing token frequently does carry a separator and would otherwise
+    # sail past that guard and reach the extension rule, which accepts it: the
+    # dominant corpus shape is an angle-bracketed leading segment followed by a
+    # real .md tail, and that is exactly the token this guard exists to reject.
+    if (Test-PlaceholderMarker -Token $Token) {
+        return $null
+    }
+
     $separatorIndex = $Token.IndexOf('/')
     if ($separatorIndex -lt 0 -or $separatorIndex -eq 0) {
         return $null
@@ -492,6 +465,7 @@ Export-ModuleMember -Function `
     ConvertTo-NormalizedLine, `
     Get-PlanLineScan, `
     Get-InlineCodeToken, `
+    Test-PlaceholderMarker, `
     Test-MultipleFeatureFolderSpan, `
     Get-PathTokenKind, `
     Get-PathFromLine, `

package/resources/claude-customizations/.claude/lib/blast-radius/BlastRadiusTokenShape.psm1

@@ -0,0 +1,187 @@
+<#
+.SYNOPSIS
+    Blast-radius token-shape predicates, ported from the Python reference.
+
+.DESCRIPTION
+    Destination-runtime PowerShell port of
+    scripts/dev_tools/_blast_radius_token_shapes.py. Holds the pure,
+    context-free shape tests that reject an inline-code token before
+    Get-PathTokenKind can record it as a repository path. A token can look like
+    a path and still name no file: a placeholder or interpolation marker makes it
+    a command or artifact shape, and a corpus-wide documentation glob makes it a
+    cross-corpus claim. Neither is evidence that a work item will write anything.
+
+    Test-PlaceholderMarker is new in issue #502.
+    Test-MultipleFeatureFolderSpan was relocated here from
+    BlastRadiusExtraction.psm1 in the same change, and the two module-scoped
+    documentation-corpus variables it reads travelled with it because $script:
+    scope is per module. The relocation exists because the extraction module had
+    two lines of headroom against the 500-line limit when the marker guard was
+    added, so an in-place guard was arithmetically impossible.
+
+    The Python module remains the authoritative reference implementation. This
+    module is a LEAF: it imports no sibling blast-radius module, so the
+    extraction module can import it with no possibility of a cycle. That
+    constraint is why the predicate does not live in BlastRadiusNormalization.psm1,
+    which already imports the extraction module.
+
+    Every function is pure: no filesystem, subprocess, network, or wall-clock
+    access, and no input is mutated.
+
+    Parity notes for maintainers:
+      - The marker array is character-identical to PLACEHOLDER_MARKERS in
+        scripts/dev_tools/_blast_radius_token_shapes.py and to the tuple of the
+        same name in scripts/dev_tools/plan_gate_coverage.py, whose origin is
+        the checkable-literal placeholder guard recorded in
+        .claude/rules/plan-acceptance-gates.md. The marker set is a module
+        constant, not a truth-table key: it describes what a path can never
+        contain rather than a policy a repository could tune.
+      - Every marker literal is single-quoted, and the two dollar forms are
+        built by character concatenation. A double-quoted PowerShell string
+        expands the subexpression form and the delimited-variable form, so a
+        double-quoted marker literal would silently define a DIFFERENT
+        vocabulary than the Python reference and the parity would fail on
+        exactly the two members that matter most.
+      - Substring search uses [System.StringComparison]::Ordinal so the result
+        is culture-independent and matches Python's byte-wise 'in' operator.
+      - Both predicates are total on every string, including the empty string, a
+        token consisting only of a marker, and a bare bracket pair. Neither
+        throws for any input, because the classifier that calls them runs over
+        every inline-code span in a document and a throw would abort an entire
+        derivation over one stray span.
+#>
+
+Set-StrictMode -Version Latest
+
+# Placeholder and interpolation markers. A token carrying any of these was
+# written to document a shape, not to name a file, so it can never be a write
+# claim.
+#
+# The angle brackets are the dominant corpus shape and are also the strongest
+# case: Windows forbids both characters in a filename outright, so an
+# angle-bracketed token cannot name a file on the platform this repository is
+# developed on. The two dollar forms are shell and PowerShell interpolation, and
+# the percent form is the Windows shell's environment-variable syntax; each
+# resolves at run time to text that is not in the token.
+#
+# The two dollar forms are assembled from single characters deliberately. Written
+# as one single-quoted literal they would be correct, but assembling them makes
+# the intent explicit at the definition site and removes any question of what a
+# future edit to the quoting style would do.
+$script:PlaceholderMarker = [string[]]@(
+    '<',
+    '>',
+    '$' + '{',
+    '$' + '(',
+    '%'
+)
+
+# Documentation-corpus root and the index, counted after that prefix, of the
+# segment that names one feature folder. A glob whose wildcard reaches this
+# segment or any earlier one claims every feature folder in the corpus.
+$script:FeatureCorpusPrefix = 'docs/features/'
+$script:FeatureFolderSegmentIndex = 1
+
+function Test-PlaceholderMarker {
+    <#
+    .SYNOPSIS
+        Report whether a token carries a placeholder or interpolation marker.
+
+    .DESCRIPTION
+        Port of contains_placeholder_marker. A marker-bearing token documents a
+        shape rather than naming a file. Two work items that cite the same
+        mandated artifact shape therefore acquired a path-level conflict edge on
+        a string that resolves to nothing, which made thematically unrelated
+        items contend and serialized runs that had no reason to serialize
+        (issue #502).
+
+        The test is a plain substring scan over a fixed vocabulary, deliberately
+        context-free: it needs no repository lookup, no configuration, and no
+        knowledge of which segment the marker sits in. A marker anywhere in the
+        token is disqualifying, including in the filename position, because an
+        interpolated filename is as unresolvable as an interpolated directory.
+
+    .PARAMETER Token
+        A single whitespace-free inline-code token. The empty string is accepted
+        and reports false.
+
+    .OUTPUTS
+        System.Boolean. True when any configured marker appears anywhere in the
+        token, otherwise false.
+    #>
+    [CmdletBinding()]
+    [OutputType([bool])]
+    param(
+        [Parameter(Mandatory = $true)]
+        [AllowEmptyString()]
+        [string] $Token
+    )
+
+    # Ordinal comparison keeps the result culture-independent and byte-wise, so
+    # it agrees with Python's 'in' operator on every input.
+    foreach ($marker in $script:PlaceholderMarker) {
+        if ($Token.IndexOf($marker, [System.StringComparison]::Ordinal) -ge 0) {
+            return $true
+        }
+    }
+
+    return $false
+}
+
+function Test-MultipleFeatureFolderSpan {
+    <#
+    .SYNOPSIS
+        Report whether a glob claims more than one documentation feature folder.
+
+    .DESCRIPTION
+        Port of spans_multiple_feature_folders. The documentation corpus is laid
+        out as docs/features/<bucket>/<feature-folder>/..., so a glob whose
+        wildcard occupies or truncates the feature-folder segment claims every
+        feature folder in the corpus. That made two unrelated work items contend
+        purely because both wrote documentation (issue #489). A glob carrying a
+        complete, wildcard-free feature-folder segment claims one folder and is
+        retained.
+
+    .PARAMETER Token
+        A wildcard-bearing token already accepted by the shape rules of
+        Get-PathTokenKind.
+
+    .OUTPUTS
+        System.Boolean. True when the token is rooted in the documentation corpus
+        and its wildcard reaches the feature-folder segment or any earlier one.
+    #>
+    [CmdletBinding()]
+    [OutputType([bool])]
+    param(
+        [Parameter(Mandatory = $true)]
+        [AllowEmptyString()]
+        [string] $Token
+    )
+
+    if (-not $Token.StartsWith($script:FeatureCorpusPrefix,
+            [System.StringComparison]::Ordinal)) {
+        return $false
+    }
+
+    $segment = @($Token.Substring($script:FeatureCorpusPrefix.Length) -split '/')
+
+    # A token that stops at or before the feature-folder segment has had that
+    # segment truncated away by the wildcard, so it spans the whole corpus.
+    if ($segment.Count -le $script:FeatureFolderSegmentIndex) {
+        return $true
+    }
+
+    # Every segment up to and including the feature-folder name must be a literal
+    # for the claim to resolve to exactly one folder.
+    for ($index = 0; $index -le $script:FeatureFolderSegmentIndex; $index++) {
+        if ($segment[$index].IndexOf('*') -ge 0) {
+            return $true
+        }
+    }
+
+    return $false
+}
+
+Export-ModuleMember -Function `
+    Test-PlaceholderMarker, `
+    Test-MultipleFeatureFolderSpan

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

@@ -82,6 +82,22 @@ These invariants apply only when a caller passes `require_model_routing=True` an
 
 The completion hook (`.claude/hooks/validate-orchestrator-output.ps1`) passes `--require-model-routing` alongside `--require-complete` and surfaces a gate failure as the `MODEL_ROUTING_BLOCKED:` block reason. The PreToolUse deterrent (`.claude/hooks/enforce-model-routing-receipt.ps1`) performs presence-only gating before a delegation. The MCP TypeScript surface performs the existence check only (delegated-agent set ⊆ routing-receipt-agent set); the Python validator remains authoritative for per-receipt correctness.
 
+## Epic Launch-Binding Activation Scope
+
+This section governs when the epic child launch-binding gate runs. It exists because the gate admitted the generic `require_complete` flag into an otherwise Codex-specific activation set, which made Codex-only launch evidence a universal completion requirement (issue #524).
+
+The evidence the gate demands — `launch_receipt_path`, `launch_status_path`, `delegation_receipt`, and `model_routing_receipt` on each feature — has exactly one production writer, `.codex/scripts/launch-epic-child-wave.ps1`, on the Codex runtime. No Claude-runtime producer writes it, so an epic executed on the Claude runtime could never satisfy an unconditional gate.
+
+1. **Unconditional under the two Codex enforcement flags.** When a caller passes `require_codex_model_routing` or `require_codex_topology`, launch-binding validation runs for every feature exactly as before, including the existing `skip_not_started` filter. Behaviour under either Codex flag is unchanged.
+
+2. **Key-gated per feature under `require_complete` alone.** When `require_complete` is the only flag passed, the gate validates a feature only when that feature carries `launch_receipt_path` or `launch_status_path`. A feature carrying neither key is skipped and contributes zero errors.
+
+3. **The presence test is deliberately either-key, so a partial binding still fails.** Presence means key membership, not value truthiness: a key present with an empty or null value still arms the gate. A feature carrying one launch path key and not the other is therefore validated, and the absent key produces its error. The test is never "both keys"; that spelling would let a half-written binding pass unexamined, and the partial-binding failure is the property that distinguishes this scope rule from deleting the gate.
+
+The rest of the completion gate is unchanged. An epic whose feature is not merged, or whose `epic_merge_pr.merge_commit_sha` is missing or empty, still fails under `require_complete`.
+
+Enforcement is validator logic plus this prose, never an imported JSON Schema. The activation scope lives in `scripts/dev_tools/_epic_orchestrator_state_launch_binding.py`, and the TypeScript parity port at `extensions/drm-copilot/src/lib/validate/epic-orchestrator-state-launch-binding.ts` reproduces it with byte-identical error strings. No schema file is authored, imported, or read for it.
+
 ## Enforcement
 
 - `scripts/dev_tools/validate_orchestrator_state.py` appends one error per violated invariant when a `remediation_loop` is present, using the existing validator message style (literal, checkpoint-context prefixed). The validator returns a list of error strings and does not mutate its input.

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

@@ -233,11 +233,69 @@ Three constraints bound the mandate-read exclusion:
    detection compares the declared radius against the paths a diff actually touched, so an item that
    wrote an excluded path is caught against observed evidence rather than against prose.
 
-The extractor additionally rejects three token shapes that were never write claims: a wildcard-free
+The extractor additionally rejects four token shapes that were never write claims: a wildcard-free
 token whose final component names a directory rather than a file, a `docs/features/` glob whose
-wildcard occupies or truncates the feature-folder segment, and a contract token carrying no ASCII
-letter. `artifacts/` is not a known top-level segment, so a bare `artifacts/**` subtree claim no
-longer satisfies the shape rules.
+wildcard occupies or truncates the feature-folder segment, a contract token carrying no ASCII
+letter, and a token containing a placeholder or interpolation marker. `artifacts/` is not a known
+top-level segment, so a bare `artifacts/**` subtree claim no longer satisfies the shape rules.
+
+### Placeholder-shape rejection (issue #502)
+
+The fourth shape is a token containing any member of the marker set
+
+```text
+<    >    ${    $(    %
+```
+
+The set is not a configuration key and is not read from `config/blast-radius.json`. It originates in
+the checkable-literal placeholder guard defined in `.claude/rules/plan-acceptance-gates.md`, which
+uses the identical five markers to decide that a plan operand documents a command *shape* rather
+than stating a real assertion. Both subsystems answer the same question about the same text, so the
+two vocabularies are pinned equal by test rather than left to convention.
+
+**A marker-bearing token never matches a tracked path.** A placeholder or interpolation form
+resolves at run time to text that is not in the token, so the token as written names nothing. For
+the two angle brackets the claim is stronger than a heuristic: Windows forbids both characters in a
+filename outright, so an angle-bracketed token cannot name a file on the platform this repository is
+developed on. Admitting such a token recorded a `paths` entry that no diff could ever touch, and two
+items citing the identical shape then acquired a `path_overlap` edge on a string that resolves to
+nothing.
+
+**The dominant token is a mandated artifact shape, which is why the exposure was corpus-wide rather
+than incidental.** Every agent in this repository is instructed to write its evidence to the
+canonical scheme defined in `.claude/skills/evidence-and-timestamp-conventions/SKILL.md`, and that
+scheme is non-overridable, so a well-formed plan quotes the same feature-relative artifact shape
+that every other well-formed plan quotes. The shape is therefore the most widely shared token in the
+corpus, and admitting it made compliance with the evidence-path scheme a source of contention. The
+same reasoning applies to the feature-document shapes and to the session-keyed state-file shape.
+
+**The planner remains obliged to enumerate a genuine write explicitly.** This rejection describes a
+plan that documents a shape, not a permanent ban on the paths a shape resembles. When an item's plan
+will actually write a path it expressed as a shape, the planner appends that exact concrete path to
+the declared radius after normalization. This is the same obligation constraint 1 of the
+mandate-read exclusion imposes, and `detect_escaped_paths` is the same backstop: drift detection
+compares the declared radius against the paths a diff actually touched, so an item that wrote a path
+it expressed only as a shape is caught against observed evidence rather than against prose.
+
+**Accepted fail-open trade.** The rejection runs inside the classifier, upstream of shared-surface
+resolution, so a marker-bearing token whose shape matches a configured `shared_surface_globs`
+pattern is dropped before it can be reported as a touched shared surface. The trade is inherent to
+that placement: a guard downstream of surface resolution would leave the token in `paths` and
+reintroduce the path-level false edge it exists to remove. Corpus exposure was measured empty — no
+plan in the 58-plan corpus examined for issue #502 cited a marker-bearing token whose shape matched a
+configured shared-surface glob — and the planner obligation above is what keeps a genuine write
+visible. A later change that widens the marker set must re-take that measurement.
+
+**Known residual: the whitespace split.** Extraction harvests whitespace-free inline-code tokens, so
+a placeholder form written with internal whitespace is split into fragments before the marker test
+ever runs. Each fragment is then judged on its own shape and is normally rejected for an unrelated
+reason, most often for carrying no separator. The residual is therefore benign in the accepting
+direction but is recorded here because it means the rejection is not a complete guard against every
+way a shape can be written; it is a guard against the whitespace-free forms the extractor actually
+admits.
+
+Enforcement of this rejection is prose plus validator logic, exactly as for the three shapes above.
+No JSON Schema is authored, imported, or read for it, and `config/blast-radius.json` gains no key.
 
 ### Module-map granularity criterion
 

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

@@ -173,6 +173,33 @@ integration-to-main PR.
 The `## Invocation Prompt` section is the exact text the user replays (from the main session,
 never from an `orchestrator` agent) to launch execution.
 
+### Integration Commit Form (issue #539)
+
+The epic planner's own version-control operations — committing the epic manifest, the fanned-in
+child feature folders and approved plans, and the durable kickoff copy — are orchestration
+bookkeeping, not implementation. The preimplementation gate
+(`.claude/hooks/enforce-orchestration-preimplementation-gate.ps1`) exempts them only when the
+invocation is **pathspec-bearing**: every staging or integration invocation must name at least one
+explicit path operand, and every operand must resolve inside one of the five exempt
+orchestration-bookkeeping trees:
+
+- `docs/features/epics/`
+- `docs/features/parallel/`
+- `docs/features/active/`
+- `docs/features/potential/`
+- `artifacts/orchestration/`
+
+Use one of the two pathspec-bearing spellings:
+
+- the message option followed by a double-dash separator and then the exempt path operands, or
+- the exempt path operands named directly before the message option.
+
+A pathless integration invocation — a message option with no path operand — is denied (D4 row 4),
+as are whole-tree operands, tree-wide flags, pathspec-from-file options, history-rewriting or
+content-widening options, and any operand that resolves outside the five exempt trees. Mixing one
+exempt operand with one production operand denies the whole invocation. Name each exempt path
+explicitly; the exemption is allow-side only and every parse ambiguity denies.
+
 ## Checkpoint Handling
 
 Persist `artifacts/orchestration/epic-planner-state.json` after every completed step with the

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

@@ -522,6 +522,34 @@ Validate the artifact through `mcp__drm-copilot__validate_orchestration_artifact
 `artifact_type: "parallel-kickoff"`. That artifact type dispatches to
 `scripts/dev_tools/parallel_kickoff_contract.py`, which this feature delivers.
 
+### Integration Commit Form (issue #539)
+
+The parallel planner's own version-control operations — committing the run manifest
+`docs/features/parallel/<slug>/parallel.md`, each item's prepared feature folder and approved
+plan-path, and the durable kickoff copy `docs/features/parallel/<slug>/parallel-kickoff.md` — are
+orchestration bookkeeping, not implementation. The preimplementation gate
+(`.claude/hooks/enforce-orchestration-preimplementation-gate.ps1`) exempts them only when the
+invocation is **pathspec-bearing**: every staging or integration invocation must name at least one
+explicit path operand, and every operand must resolve inside one of the five exempt
+orchestration-bookkeeping trees:
+
+- `docs/features/epics/`
+- `docs/features/parallel/`
+- `docs/features/active/`
+- `docs/features/potential/`
+- `artifacts/orchestration/`
+
+Use one of the two pathspec-bearing spellings:
+
+- the message option followed by a double-dash separator and then the exempt path operands, or
+- the exempt path operands named directly before the message option.
+
+A pathless integration invocation — a message option with no path operand — is denied (D4 row 4),
+as are whole-tree operands, tree-wide flags, pathspec-from-file options, history-rewriting or
+content-widening options, and any operand that resolves outside the five exempt trees. Mixing one
+exempt operand with one production operand denies the whole invocation. Name each exempt path
+explicitly; the exemption is allow-side only and every parse ambiguity denies.
+
 ## Completion Report
 
 The final report to the operator must include:

package/resources/claude-customizations/config/orchestration-routing.json

@@ -210,7 +210,7 @@
   },
   "model_budget": {
     "description": "Session-level model budget. fable_policy is a three-way switch controlling whether the fable tier is disabled (removed and clamped to opus), available (used as-is), or preferred (applies the preferred_overlay).",
-    "fable_policy": "preferred"
+    "fable_policy": "available"
   },
   "codex_topology_policy": {
     "description": "Codex-native production-file-count routing. This axis selects the initial implementation topology independently from C1-C4 model selection.",

package/resources/claude-customizations/pack-manifests/core.json

@@ -33,6 +33,7 @@
     ".claude/hooks/enforce-feature-folder-order.ps1",
     ".claude/hooks/enforce-model-routing-receipt.ps1",
     ".claude/hooks/enforce-orchestration-preimplementation-gate.ps1",
+    ".claude/hooks/enforce-orchestration-preimplementation-gate-helpers.ps1",
     ".claude/hooks/enforce-parallel-abandon-gate.ps1",
     ".claude/hooks/enforce-parallel-cohort-barrier.ps1",
     ".claude/hooks/enforce-parallel-cohort-barrier-helpers.ps1",
@@ -129,6 +130,7 @@
     ".claude/lib/blast-radius/BlastRadiusValidation.psm1",
     ".claude/lib/blast-radius/BlastRadius.psm1",
     ".claude/lib/blast-radius/BlastRadiusNormalization.psm1",
+    ".claude/lib/blast-radius/BlastRadiusTokenShape.psm1",
     ".claude/rules/parallel-orchestration.md",
     ".claude/rules/shell.md",
     ".claude/lib/bash/compute-cohorts.sh",

package/resources/codex-and-agents-customizations/.agents/skills/architecture-boundaries/SKILL.md

@@ -1,9 +1,6 @@
 ---
 name: architecture-boundaries
 description: Architecture boundary enforcement rules for the No-COM architecture.
-paths:
-  - "**/*.ts"
-  - "**/*.cs"
 ---
 
 # Converted rule

package/resources/codex-and-agents-customizations/.agents/skills/csharp/SKILL.md

@@ -1,8 +1,5 @@
 ---
 name: csharp
-paths:
-  - "**/*.cs"
-  - "**/*.csproj"
 description: C#-specific toolchain and coding standards.
 ---
 

package/resources/codex-and-agents-customizations/.agents/skills/csharp-change-budget-router/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: csharp-change-budget-router
-description: Budget-first routing contract for C# work: estimate production-file scope, choose small vs large path, enforce orchestration-first routing for larger changes, and use the VS Code extension command surface for promotion lifecycle steps when available.
+description: 'Budget-first routing contract for C# work: estimate production-file scope, choose small vs large path, enforce orchestration-first routing for larger changes, and use the VS Code extension command surface for promotion lifecycle steps when available.'
 ---
 
 # C# Change Budget Router

package/resources/codex-and-agents-customizations/.agents/skills/csharp-qa-gate/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: csharp-qa-gate
-description: Final QA gate for C# changes. Executes the full CSharpier -> .NET Analyzers -> Nullable Analysis -> MSTest toolchain, compares against a captured baseline, enforces zero-regression deltas, and produces the required reporting block before the agent declares the change complete.
+description: Final QA gate for C# changes. Runs CSharpier, .NET analyzers, nullable analysis, and MSTest; compares a captured baseline, enforces zero-regression deltas, and produces the required reporting block before completion.
 ---
 
 # C# QA Gate

package/resources/codex-and-agents-customizations/.agents/skills/epic-plan/SKILL.md

@@ -161,7 +161,7 @@ As each preparation finishes:
 3. Backfill `issue_num` and `feature_folder` in `epic.md`.
 4. Record `preparation_status: "prepared"`, `research_path`, `plan_path`,
    `preflight_evidence_path`, and `preflight_status: "PREFLIGHT: ALL CLEAR"` in the planner
-   checkpoint. `research_path` must be under `artifacts/research/` or inside the feature folder.
+   checkpoint. `research_path` must be under `docs/features/<feature>/research/` inside the feature folder.
    Each child references its immutable receipt and the shared `wave.<wave_id>.status.json` path.
 5. Remove the worktree only after its preparation branch is merged.
 

package/resources/codex-and-agents-customizations/.agents/skills/evidence-and-timestamp-conventions/SKILL.md

@@ -31,7 +31,8 @@ The following sub-paths under `artifacts/` are FORBIDDEN for evidence output:
 
 Allowed `artifacts/` sub-paths (non-evidence orchestration use only):
 - `artifacts/orchestration/`
-- `artifacts/research/`
+
+Research output is not an `artifacts/` sub-path. Use `docs/features/<feature>/research/` for feature-associated research or `docs/research/` for one-off research.
 
 No delegation prompt, plan task, or upstream agent instruction may override this scheme. If a caller supplies a non-canonical path, the receiving agent MUST reject it, substitute the canonical path, and record `EVIDENCE_LOCATION_OVERRIDE_REJECTED: <supplied path> replaced with <canonical path>`.
 

package/resources/codex-and-agents-customizations/.agents/skills/general-code-change/SKILL.md

@@ -1,8 +1,6 @@
 ---
 name: general-code-change
 description: Cross-language code change policy for all files.
-paths:
-  - "**"
 ---
 
 # Converted rule

package/resources/codex-and-agents-customizations/.agents/skills/general-unit-test/SKILL.md

@@ -1,8 +1,6 @@
 ---
 name: general-unit-test
 description: Cross-language unit test policy for all files.
-paths:
-  - "**"
 ---
 
 # Converted rule

package/resources/codex-and-agents-customizations/.agents/skills/invoke-csharp-engineer/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: invoke-csharp-engineer
-description: Invoke the csharp-typed-engineer worker to design, implement, and verify C# changes within typed repository boundaries. Applies CSharpier -> .NET Analyzers -> Nullable Analysis -> MSTest toolchain, the 1-3 production-file small-path budget, and zero-regression quality gates.
+description: Invoke the csharp-typed-engineer worker to design, implement, and verify C# changes within typed repository boundaries. Applies CSharpier, .NET analyzers, nullable analysis, and MSTest with the one-to-three production-file small-path budget and zero-regression quality gates.
 ---
 
 # Implement C# Skill

package/resources/codex-and-agents-customizations/.agents/skills/invoke-powershell-engineer/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: invoke-powershell-engineer
-description: Invoke the powershell-typed-engineer worker to design, implement, and verify PowerShell changes within typed repository boundaries. Applies PoshQC format -> analyze -> test toolchain, the 1-2 production-file direct-mode budget, the 3-production + 3-test per-batch cap, and zero-regression quality gates.
+description: Invoke the powershell-typed-engineer worker to design, implement, and verify PowerShell changes within typed repository boundaries. Applies PoshQC formatting, analysis, and testing with a one-to-two production-file direct-mode budget, a three-production plus three-test batch cap, and zero-regression quality gates.
 ---
 
 # Implement PowerShell Skill

package/resources/codex-and-agents-customizations/.agents/skills/invoke-python-engineer/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: invoke-python-engineer
-description: Invoke the python-typed-engineer worker to design, implement, and verify Python changes within typed repository boundaries. Applies Black -> Ruff -> Pyright -> Pytest toolchain, the 3-production + 3-test per-batch budget, and zero-regression quality gates.
+description: Invoke the python-typed-engineer worker to design, implement, and verify Python changes within typed repository boundaries. Applies Black, Ruff, Pyright, and Pytest with a three-production plus three-test per-batch budget and zero-regression quality gates.
 ---
 
 # Implement Python Skill