@danmoisan/drm-copilot-mcp 1.0.23 → 1.0.26

package/resources/claude-customizations/.claude/skills/feature-review-workflow/SKILL.md

@@ -108,10 +108,10 @@ If the branch diff modifies any path matching `.github/workflows/**`, `scripts/b
         - Python: `poetry run pytest --cov` → artifact: `artifacts/python/lcov.info`
         - PowerShell: `mcp__drm-copilot__run_poshqc_test` → artifact: `artifacts/pester/powershell-coverage.xml`
         - C#: `dotnet test --collect:"XPlat Code Coverage"` → artifact: `artifacts/csharp/coverage.xml`
-        - Coverage thresholds (uniform tier rule per quality-tiers.md):
-          - New code files (added in this feature): line coverage >= 85% and branch coverage >= 75%. Flag as FAIL otherwise.
-          - Modified files (changed but previously existing): line coverage >= 85%, branch coverage >= 75%, and no regression on changed lines relative to baseline. Flag as FAIL otherwise.
-          - Repo-wide per language: line coverage >= 85% and branch coverage >= 75%. Flag as FAIL otherwise.
+        - Coverage thresholds (uniform tier rule per quality-tiers.md). The branch threshold applies only to branch-capable languages — TypeScript, Python, and C#. PowerShell is a coverage language and is fully subject to the line threshold and the no-regression requirement, but Pester measures command (instruction) coverage and line coverage only, so no branch percentage exists to evaluate and no branch threshold applies to it (see `.claude/rules/powershell.md`). Do not flag a missing PowerShell branch figure as FAIL:
+          - New code files (added in this feature): line coverage >= 85%, and branch coverage >= 75% for branch-capable languages. Flag as FAIL otherwise.
+          - Modified files (changed but previously existing): line coverage >= 85%, branch coverage >= 75% for branch-capable languages, and no regression on changed lines relative to baseline. Flag as FAIL otherwise.
+          - Repo-wide per language: line coverage >= 85%, and branch coverage >= 75% for branch-capable languages. Flag as FAIL otherwise.
         - If coverage artifacts already exist from the executor run, inspect them instead of re-running.
         - If no coverage artifact exists for a language that has changed files, flag as FAIL — coverage verification is mandatory for all languages with changed files.
    - Run the smallest relevant subset first when the repo policy permits it.

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

@@ -78,16 +78,21 @@ re-derivation is mandatory and is not an optimization to skip when the checkpoin
      current-cohort member, so no cohort assignment needs to change.
    - `DEFER_AND_RECOLOR` — the candidate shares an edge with at least one member of the current
      cohort, pinned or not-yet-launched. Defer it to a future cohort and recolor by calling
-     `recolor_unstarted(unstarted_items, conflict_edges, pinned, current_generation, current_cohort=current_cohort)`.
+     `recolor_unstarted(unstarted_items, conflict_edges, pinned, current_generation, current_cohort=current_cohort, highest_pinned_cohort=highest_pinned_cohort)`.
+     `highest_pinned_cohort` is derived from re-verified durable state: the highest
+     current-generation cohort index occupied by any in-flight item.
      The recolor is a recompute: `recolor_generation` increments by exactly one, and it places every
-     unstarted item at an index at or above `current_cohort`, strictly above it when a pinned
-     conflict exists.
+     unstarted item at an index at or above `current_cohort`, strictly above
+     `highest_pinned_cohort` when a pinned conflict exists.
 
    Derive `current_cohort_members` from the re-verified durable state, not from the cached
    checkpoint: it is the full membership of the current-generation cohort at `current_cohort`,
    INCLUDING its not-yet-launched `scheduled` members. Derive `current_cohort` from that same
-   re-verified state; it is F3's top-level `current_cohort` field and is the index the pinned items
-   occupy. Both matter because `max_concurrency` caps simultaneously in-flight items independently
+   re-verified state; it is F3's top-level `current_cohort` field, the lowest current-generation
+   cohort index still holding a non-terminal item. Under the per-edge barrier an in-flight item is
+   not confined to that index, so derive `highest_pinned_cohort` from the same re-verified state as
+   well: the highest current-generation cohort index occupied by any in-flight item. Both matter
+   because `max_concurrency` caps simultaneously in-flight items independently
    of cohort size and refills each freed slot from the same current cohort — see
    `## Cohort Barrier and Max-Concurrency Slot Filling` in
    `.claude/skills/parallel-orchestrate/SKILL.md` — so the current cohort durably holds `scheduled`

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

@@ -65,7 +65,7 @@ Consumption rules:
   so it does not drift when an item's folder moves from `docs/features/active/` to
   `docs/features/completed/`.
 - Read `mode` (`closed` or `open`, defaulting to `closed`), `max_concurrency` (an integer from 1
-  through 8, defaulting to 4), and each item's identity and state: `feature_folder`, `kind`,
+  through 32, defaulting to 4), and each item's identity and state: `feature_folder`, `kind`,
   `state`, and `blast_radius`.
 - The manifest is read-only to `parallel-orchestrator`. It is static input authored by
   `parallel-planner`: never write it, rewrite it, or back-fill a field into it.
@@ -111,23 +111,58 @@ in order to combine two cohorts or widen a launch batch.
 
 ## Cohort Barrier and Max-Concurrency Slot Filling
 
-Two independent controls govern every launch. The cohort barrier governs when a cohort may start.
-`max_concurrency` governs how many items of a started cohort run at once. Neither substitutes for
+Two independent controls govern every launch. The cohort barrier governs when an individual item
+may start. `max_concurrency` governs how many eligible items run at once. Neither substitutes for
 the other.
 
-**Cohort barrier.** Cohort `N+1` branches from `main` only after every cohort-`N` item is `merged`
-or `worktree_removed`. Increment `current_cohort` only on durable confirmation from
-`git worktree list --porcelain`, `git branch`, and
-`gh pr view --json state,mergedAt,headRefOid` — never from an in-memory completion notification. A
-blocked item (`blocked_ci_loop_limit` or `blocked_drift`) is neither `merged` nor
-`worktree_removed`, so a blocked item holds the barrier and cohort `N+1` does not start.
+**Cohort barrier (per-edge).** An item may start only when every conflicting neighbour
+(`conflict_edges[]`) that sits in a strictly prior current-generation cohort has `merge_status` of
+`merged` or `worktree_removed`. `ci_green` does not satisfy the barrier: the pull request is not
+merged, so its work is not on `main`. Same-cohort and later-cohort neighbours do not hold an item
+back, and items with no conflicting prior-cohort neighbour may start regardless of other cohorts'
+progress. The barrier is a predicate over one item's own conflict edges, not a global gate over
+whole cohorts.
+
+Evaluate the predicate only against durable state read from `git worktree list --porcelain`,
+`git branch`, and `gh pr view --json state,mergedAt,headRefOid` — never from an in-memory
+completion notification. A blocked item (`blocked_ci_loop_limit` or `blocked_drift`) is neither
+`merged` nor `worktree_removed`, so it holds every conflicting later-cohort neighbour and,
+transitively, the tail of its own conflict component; items outside that component are unaffected.
+
+**`current_cohort` is a progress indicator, not a gate.** `current_cohort` is the LOWEST
+current-generation cohort index that still contains a non-terminal, non-withdrawn item. It is
+recomputed and written only on durable confirmation from `git worktree list --porcelain`,
+`git branch`, and `gh pr view --json state,mergedAt,headRefOid` — never from an in-memory
+completion notification. It gates nothing: no item's eligibility is decided by comparing it to
+`current_cohort`, because eligibility is the per-edge predicate above. It is reported in the status
+document, is the base index the mutation engine recolors from, and is bounded by rule invariant 14,
+whose text is unchanged. Because the barrier is per-edge, in-flight items are not confined to
+`current_cohort`; the highest current-generation index any pinned item occupies is a separate value
+(`highest_pinned_cohort`, see `## Membership Mutation Protocol (F6)`).
+
+**Safety argument.** An item that starts under the per-edge rule while a non-conflicting
+prior-cohort item is still open branches from a `main` that lacks only non-conflicting merged work.
+That is byte-for-byte the situation the same-cohort merge-order text above already accepts as safe:
+"Items within a cohort are non-conflicting by construction — a cohort is an independent set in the
+conflict graph — so they may branch from the same `main` tip and may merge in any order." The
+per-edge barrier extends that accepted situation across cohort boundaries without weakening it,
+because the only work the starting item can be missing is work it does not conflict with. That
+same-cohort text is unchanged by this rule.
+
+**Availability argument.** Under a global barrier a single `blocked_ci_loop_limit` or
+`blocked_drift` item halts every lane, because no item of the next cohort may start until every
+item of the current one is terminal. Under the per-edge rule the blocked item holds only its own
+conflict component's tail: its conflicting later-cohort neighbours, and transitively theirs.
+Unrelated lanes keep advancing. That is the difference between one stuck item stalling a 13-lane
+run and one stuck item stalling one lane.
 
 **`max_concurrency` slot filling.** `max_concurrency` caps the number of simultaneously in-flight
 items independently of cohort size: a cohort of twelve items executes at most `max_concurrency`
 items at a time. Fill slots in ascending item-key order, keyed on `issue_num`, and refill each
 freed slot with the next unstarted item of the current cohort in that same ascending item-key
-order. A cohort larger than `max_concurrency` therefore launches in several batches from the same
-recorded `main` tip. The batching is a pure function, reached on the destination-runtime path as
+order. A cohort larger than `max_concurrency` therefore launches in several batches, each from the
+`main` tip recorded for that batch. The batching is a pure function, reached on the
+destination-runtime path as
 `bash .claude/lib/bash/compute-concurrency-batches.sh --keys "<k1> <k2> ..." --max-concurrency <n>`.
 It prints a compact JSON array of arrays, returns the batches in order, and sorts the keys itself,
 so determinism does not depend on caller ordering.
@@ -152,11 +187,33 @@ fire per call with no cross-call state visibility.
 Neither layer is shipped by this feature; both are named here so the obligation is legible to an
 operator and to the F7 planner. Until F7 lands, the barrier is enforced by this procedure alone.
 
+**The two layers fail closed differently, and the difference is deliberate.** Do not read either
+layer's silence as permission.
+
+- Layer 1 is PROSPECTIVE and evaluated per launch, so it denies fail-closed on every condition that
+  leaves the target's own eligibility unknowable: a missing or unparseable checkpoint, an unresolved
+  feature-folder token, a missing `items[]` record for the target, a target with no
+  current-generation cohort assignment, a missing neighbour record, and a missing neighbour
+  `merge_status`. Its one permissive case is neighbour-side: a NEIGHBOUR that carries no
+  current-generation cohort assignment is skipped rather than denied, because such a neighbour sits
+  in no prior cohort and therefore constrains nothing.
+- Layer 2 is RETROSPECTIVE and evaluated per edge, so it is deliberately silent on an edge it cannot
+  judge; a malformed edge is invariant 15's to report, not the barrier's. It applies three readings
+  of the same edge. The STRUCTURAL reading rejects two conflicting items colored into the same
+  current-generation cohort outright — a violation Layer 1 has no counterpart for, because Layer 1
+  only ever asks about strictly prior cohorts. The STATUS reading is the retrospective
+  contrapositive of the per-edge launch rule. The TEMPORAL reading rejects
+  `merged_at(earlier) > worktree_created_at(later)`, and degrades to the status reading alone when
+  either timestamp is absent or is not a string.
+
 ## Per-Item Branch and Worktree Lifecycle
 
-1. Run one `git fetch origin main` immediately before each cohort launch, so every item in that
-   cohort branches from the same current remote `main` tip rather than from a stale local ref.
-   Record the fetched tip.
+1. Run one `git fetch origin main` immediately before each launch batch, so every item in that
+   batch branches from the same current remote `main` tip rather than from a stale local ref.
+   The unit is the launch batch, not the cohort: under the per-edge barrier a cohort's items
+   become eligible at different times, and a cohort larger than `max_concurrency` launches in
+   several batches, so a per-cohort fetch would leave later batches on a stale tip. Record the
+   fetched tip for each batch.
 2. Each item's worktree is created by that item's delegation spawn,
    `Agent(orchestrator, isolation: "worktree", run_in_background: true)`, branched from
    `origin/main`. Do not create or check out item worktrees by hand.
@@ -310,8 +367,11 @@ this surface.
    feature.
 5. On loop exhaustion, the parent records the terminal `merge_status: blocked_ci_loop_limit` for the
    item; the child's own checkpoint retains its precise blocked status. A blocked item is neither
-   `merged` nor `worktree_removed`, so it holds the cohort barrier defined in
-   `## Cohort Barrier and Max-Concurrency Slot Filling`.
+   `merged` nor `worktree_removed`, so under the per-edge barrier defined in
+   `## Cohort Barrier and Max-Concurrency Slot Filling` it holds back exactly its own conflicting
+   later-cohort neighbours — and, transitively, the tail of its own conflict component. Every item
+   outside that component, including every item of a later cohort that shares no conflict edge with
+   it, remains eligible and continues to launch.
 
 Boundary with F8: a merge conflict between two same-cohort items is evidence that the declared
 blast radius under-reported, and this feature records the child's blocked or remediated outcome
@@ -469,23 +529,29 @@ integers (`items[].issue_num`) everywhere on this surface.
 ### Pinning invariant
 
 **In-flight items are pinned. Scheduling is recomputed only over the not-yet-started subgraph, and
-recoloring is a pure function of `(remaining subgraph, pinned set, pinned cohort index)`.**
+recoloring is a pure function of `(remaining subgraph, pinned set, pinned cohort indices)`.**
 
 The recolor function takes the induced subgraph of unstarted items (states `proposed`, `admitted`,
-`prepared`, `scheduled`), the pinned set (state `in_flight`), the current generation, and — as a
-third scheduling input — the current cohort index `current_cohort` that the pinned items occupy. It
-returns cohort assignments for unstarted items ONLY: the returned mapping's key set equals the
-unstarted set exactly and contains no pinned key. A pinned item is therefore absent from the result
-rather than reassigned, and that absence IS the guarantee that a mutation never moves work already
-running.
+`prepared`, `scheduled`), the pinned set (state `in_flight`), the current generation, and — as two
+further scheduling inputs — `current_cohort` and `highest_pinned_cohort`, the highest
+current-generation cohort index occupied by any pinned item. Both are derived from re-verified
+durable state. Two inputs are required because the per-edge barrier does not confine in-flight items
+to one index: an item starts as soon as its own conflicting prior-cohort neighbours are terminal, so
+the pinned frontier can span several cohorts. It returns cohort assignments for unstarted items
+ONLY: the returned mapping's key set equals the unstarted set exactly and contains no pinned key. A
+pinned item is therefore absent from the result rather than reassigned, and that absence IS the
+guarantee that a mutation never moves work already running.
 
 **Pinned-barrier offset.** The returned indices are ABSOLUTE checkpoint cohort indices at or above
-`current_cohort`, and strictly above `current_cohort` whenever any conflict edge joins an unstarted
-item to a pinned item. When no such edge exists the lowest returned index equals `current_cohort`
-exactly, so unstarted items may share the running cohort and `max_concurrency` slot filling is
-preserved. The offset is a single uniform shift applied to every color class, so F2's distinct color
-classes remain distinct cohort indices and independence within the unstarted set is preserved
-exactly.
+`current_cohort`, and strictly above `highest_pinned_cohort` whenever any conflict edge joins an
+unstarted item to a pinned item. When no such edge exists the lowest returned index equals
+`current_cohort` exactly, so unstarted items may share the running cohort and `max_concurrency` slot
+filling is preserved. Shifting above the highest pinned index — rather than above `current_cohort`
+alone — is what keeps a deferred candidate off the index of any pinned item it conflicts with when
+the pinned frontier spans more than one cohort. The offset is a single uniform shift applied to
+every color class, so F2's distinct color classes remain distinct cohort indices and independence
+within the unstarted set is preserved exactly. When every pinned item sits at `current_cohort` the
+two inputs coincide and the offset is identical to the earlier single-frontier rule.
 
 Write the returned indices VERBATIM into `cohorts[].index`; never re-base them to zero. `cohorts[]`
 carries exactly ONE current-generation entry per index, so returned keys landing on index
@@ -506,8 +572,14 @@ freed slot from the same current cohort — see
 `## Cohort Barrier and Max-Concurrency Slot Filling` — so the current cohort durably holds
 not-yet-launched `scheduled` members that a candidate can contend with. Recoloring previously
 dropped the candidate-to-pinned edges together with the pinned vertices, which discarded the pinned
-CONSTRAINT as well as the pinned VERTICES and returned a deferred candidate to cohort 0, the current
-cohort, whenever the cohort barrier held `current_cohort` at 0.
+CONSTRAINT as well as the pinned VERTICES and returned a deferred candidate to the current cohort,
+undoing the deferral.
+
+**Third design correction (per-edge barrier).** The offset previously shifted to
+`current_cohort + 1`, which was sound only while the documented barrier was global and every pinned
+item therefore sat at `current_cohort`. Under the per-edge barrier the pinned frontier can span
+several indices, so the offset now shifts above `highest_pinned_cohort`. Where the frontier is a
+single index the two expressions agree, so no reachable earlier recoloring changed.
 
 ### Recompute boundary
 
@@ -613,9 +685,11 @@ engine's `build_requeue_entry` constructor and the recolor through `recolor_unst
   `new_state: blocked`, `disposition: null`, and `recolor_generation` equal to `g` + 1 — the requeue
   is a recompute.
 - The recolor runs over the unstarted subgraph only, so no other in-flight item moves. Its call
-  shape is the five-argument form
-  `recolor_unstarted(unstarted_items, conflict_edges, pinned, current_generation, current_cohort=current_cohort)`,
-  where `current_cohort` is required and keyword-only.
+  shape is the six-argument form
+  `recolor_unstarted(unstarted_items, conflict_edges, pinned, current_generation, current_cohort=current_cohort, highest_pinned_cohort=highest_pinned_cohort)`,
+  where `current_cohort` and `highest_pinned_cohort` are both required and keyword-only.
+  `highest_pinned_cohort` is derived from re-verified durable state: the highest
+  current-generation cohort index occupied by any in-flight item.
 
 The drift event itself is recorded in `drift_events[]`, which this protocol does not write. See
 `## Radius Drift Detection (F8)`.

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

@@ -62,9 +62,42 @@ Intake proceeds directly to preparation fan-out.
 ## Preparation Fan-Out
 
 One preparation-mode `Agent(orchestrator)` run per item. Preparation produces documents and plans
-rather than code, and items carry no ordering constraint, so launch ALL item preparations
-concurrently: one message, N `Agent` calls, each `isolation: "worktree"` and
-`run_in_background: true`. Create each preparation worktree's branch from `origin/main`.
+rather than code, and items carry no ordering constraint, so preparations may run concurrently —
+but they are BOUNDED, not unbounded.
+
+**Launch preparations in waves of at most `max_concurrency`.** Compute the waves with the same
+deterministic chunker the execution phase uses:
+
+```
+bash .claude/lib/bash/compute-concurrency-batches.sh --keys "<all item keys>" --max-concurrency <n>
+```
+
+(already granted to this agent at `.claude/agents/parallel-planner.md:18`). It prints a compact
+JSON array of arrays, returns the batches in order, and sorts the keys itself, so wave membership
+does not depend on caller ordering. Launch wave *k* as one message carrying that wave's `Agent`
+calls, each `isolation: "worktree"` and `run_in_background: true`.
+Create each preparation worktree's branch from `origin/main`.
+Launch wave *k+1* only after every child of wave *k* has TERMINATED — not merely reported
+progress. All of this happens inside a single `/parallel-plan` invocation with no operator action
+between waves.
+
+The bound is `max_concurrency` itself, and no new knob is introduced. A preparation child and an
+execution child are the same workload class — one background orchestrator per item — so the
+operator's declared appetite for concurrent children applies to both phases. At the motivating
+scale, `max_concurrency: 13` over 69 items runs `ceil(69 / 13) = 6` waves.
+
+**A `max_preparation_concurrency` manifest key was considered and is explicitly NOT adopted now.**
+Such a key would carry the same `1..32` bounds and the same boolean rejection as M4 and would
+default to `max_concurrency`. It is deferred because no evidence yet shows the two phases need
+different caps, and adding a second knob would force every operator to reason about two numbers
+where one suffices. Revisit it only if a real run shows preparation and execution have materially
+different concurrency profiles.
+
+**`/parallel-add` is NOT the intake path.** It performs incremental admission into an
+already-running open-mode queue: exactly one item per invocation, with a single sequential
+preparation child. Preparing 69 items through it would take 57 or more separate operator
+invocations after the initial plan. Use `/parallel-plan` for intake and `/parallel-add` only to
+admit an item into a run that is already in flight.
 
 Each delegation prompt includes this literal kickoff line, followed by the model-budget marker
 line:
@@ -250,10 +283,27 @@ The library returns the partition; the planner supplies the record fields.
    item is `prepared` and radius-validated. Derive the conflict edge set by applying
    `Test-BlastRadiusConflict` to every unordered pair of `declared` radii, then pass the pairs as
    `--edges "<a>:<b> ..."` and the item keys as `--keys "<k1> <k2> ..."`.
-2. Record `cohorts[]` at `generation: 0`, each cohort's `item_keys[]` sorted ascending.
-3. Record `conflict_edges[]` as `{a, b, reason}` entries for auditability.
-4. Record `recolor_generation: 0` and `current_cohort: 0`.
-5. Record `max_concurrency` — default 4, bounded 1 through 8 by the F3 schema — without enforcing
+2. Immediately after the conflict-edge set is derived and before anything consumes it, run the
+   lane-assertion diagnostic:
+   `poetry run python -m scripts.dev_tools.parallel_lane_assertion --manifest docs/features/parallel/<slug>/parallel.md --edges "<a>:<b> ..."`
+   (covered by the planner's existing `Bash(poetry run *)` grant). It compares the manifest's
+   optional `expected_conflict_components` assertion (invariant M8) against the connected
+   components of the DERIVED conflict graph and prints one `ADVISORY` line per finding in four
+   classes: expected-together-but-derived-apart, expected-apart-but-derived-together, a member
+   naming no manifest item, and — informational only — a manifest item covered by no expected
+   component.
+   **The diagnostic is ADVISORY ONLY.** It never blocks the run, never modifies or suppresses a
+   derived edge, never feeds `compute_cohorts`, and never influences scheduling. It always exits 0,
+   including when it reports disagreements. A disagreement is a signal to re-examine the blast
+   radii; it is never a licence to narrow a radius to suppress an edge, which stays prohibited.
+   When the manifest carries no `expected_conflict_components` key the diagnostic still runs and
+   reports every item as uncovered, which is the expected output for a run with no assertion.
+   Recording the diagnostic's result in the planner checkpoint is a tolerated extra field, not a
+   validated one; no validator changes for it.
+3. Record `cohorts[]` at `generation: 0`, each cohort's `item_keys[]` sorted ascending.
+4. Record `conflict_edges[]` as `{a, b, reason}` entries for auditability.
+5. Record `recolor_generation: 0` and `current_cohort: 0`.
+6. Record `max_concurrency` — default 4, bounded 1 through 32 by the F3 schema — without enforcing
    it. Enforcement is F5's, through
    `bash .claude/lib/bash/compute-concurrency-batches.sh --keys "<k1> ..." --max-concurrency <n>`
    (the bash port of `compute_concurrency_batches(cohort_item_keys, max_concurrency)`), which fills
@@ -281,16 +331,23 @@ No production module is added for this check; it is a re-invocation of the lande
 ## Manifest Authoring
 
 Write `docs/features/parallel/<slug>/parallel.md` conforming to the F3-owned frontmatter schema
-recorded in `.claude/rules/parallel-orchestration.md` (manifest invariants M1-M7):
+recorded in `.claude/rules/parallel-orchestration.md` (manifest invariants M1-M8):
 
 - `parallel` — the run slug, a non-empty string.
 - `mode` — `closed` or `open`; defaults to `closed` when absent.
-- `max_concurrency` — an integer from 1 through 8; defaults to `4` when absent.
+- `max_concurrency` — an integer from 1 through 32; defaults to `4` when absent.
 - `created_at` — a non-empty ISO-8601 string.
 - `items[]` — one entry per item, each carrying `issue_num` (a positive integer, unique across
   items), `feature_folder` (a non-empty string), `kind` (`feature` or `bug`), `state`, and
   `blast_radius` carrying `paths`, `modules`, `shared_surfaces`, `contracts`, `source: "declared"`,
   and `computed_at`.
+- `expected_conflict_components[]` — OPTIONAL (invariant M8). A block sequence of objects, each
+  carrying a required non-empty `members` list of positive `issue_num` integers that resolve to
+  declared items, with no item in two components, plus an optional non-empty-string `name` used as
+  a diagnostic label only. A flow-style value (`members: [101, 102]`) is outside the bash YAML
+  subset and must not be authored. The field is an ASSERTION consumed by the advisory lane
+  diagnostic in `### Seeding procedure`: it never overrides a derived edge, never feeds
+  `compute_cohorts`, and never influences scheduling.
 
 The manifest carries no `depends_on` field at any level and no top-level `integration_branch`
 field; both are prohibited-key rejections in the schema. Commit it to `parallel/<slug>-plan` in
@@ -454,6 +511,11 @@ The final report to the operator must include:
 - Per item: one `plan-path:` line, the branch name, the preflight status, and the
   radius-validation result, including any V3 Advisory findings.
 - The cohort table at `generation 0`, together with the result of the recomputation-parity check.
+- The lane-assertion diagnostic's result: the derived conflict-component count, the disagreement
+  count, and every `ADVISORY` line it emitted. This line-item is REQUIRED and is reported even when
+  the manifest carries no `expected_conflict_components` assertion and even when the diagnostic
+  found nothing, so its silence is never ambiguous. Report it as advisory information: it does not
+  gate the report, does not change the cohort table, and no finding is escalated to Blocking.
 - Both kickoff artifact paths: `artifacts/orchestration/parallel-kickoff-<slug>.md` and
   `docs/features/parallel/<slug>/parallel-kickoff.md`.
 

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

@@ -79,13 +79,17 @@ Do not record a partial removal, and do not record the rejection itself in `muta
 
 3. **Unstarted removal (recompute).** Set the item's state to `withdrawn`, drop its vertex, and
    recolor by calling `recolor_unstarted(unstarted_items, conflict_edges, pinned,
-   current_generation, current_cohort=current_cohort)`. Write
+   current_generation, current_cohort=current_cohort,
+   highest_pinned_cohort=highest_pinned_cohort)`. Write
    `RecolorResult.cohort_assignments` into `cohorts[]` and set the top-level `recolor_generation`
    to `RecolorResult.generation`; the generation increments by exactly one. The result names no
    pinned key, so no in-flight item moves.
 
-   `current_cohort` is F3's top-level field, read from the re-verified durable state, and is the
-   index the pinned items occupy. The returned indices are ABSOLUTE and are written VERBATIM into
+   `current_cohort` is F3's top-level field, read from the re-verified durable state: the lowest
+   current-generation cohort index still holding a non-terminal item. Under the per-edge barrier an
+   in-flight item is not confined to that index, so `highest_pinned_cohort` — the highest
+   current-generation cohort index occupied by any in-flight item — is read from the same
+   re-verified state. The returned indices are ABSOLUTE and are written VERBATIM into
    `cohorts[].index`, never re-based to zero. Returned keys whose index equals `current_cohort` are
    MERGED into the single existing current-generation cohort entry at that index alongside its
    pinned members, never written as a second entry carrying the same `index`, which F3 invariant 13

package/resources/claude-customizations/.claude/skills/powershell-qa-gate/SKILL.md

@@ -42,7 +42,7 @@ Compare the final results to the Phase A baseline. All of the following must hol
 - **Pester delta**: 0 new failing tests.
 - **Per-file coverage delta**: coverage for every touched file is greater than or equal to the baseline for that file.
 - **Overall coverage delta** (when the repo enforces it): overall coverage is greater than or equal to the baseline.
-- **New modules, classes, or methods**: line coverage >= 85% and branch coverage >= 75% per the uniform tier rule (`.claude/rules/quality-tiers.md`). No tier-specific lower thresholds. No regression on changed lines.
+- **New modules, classes, or methods**: line coverage >= 85% per the uniform tier rule (`.claude/rules/quality-tiers.md`). No tier-specific lower thresholds. No regression on changed lines. Pester measures command (instruction) coverage and line coverage only; branch coverage is not measurable for PowerShell, so no branch-coverage gate applies here (see `.claude/rules/powershell.md`). Command coverage is informational and carries no threshold.
 
 If any delta check fails, the agent must revert or fix immediately and rerun the full toolchain. Do not proceed to reporting until all deltas are clean.
 

package/resources/claude-customizations/.claude-variants/csharp-legacy/rules/csharp.md

@@ -11,9 +11,9 @@ This rule file summarizes the C#-specific policies for this repository.
 
 ## Toolchain
 
-1. **Formatting — CSharpier**: All C# source files must be formatted with CSharpier. Do not use `dotnet format`. Command: `dotnet tool run csharpier .` or `csharpier .`
-2. **Linting — .NET Analyzers**: C# code must pass Roslyn/.NET analyzer diagnostics. Command: `msbuild <solution>.sln /t:Build /p:Configuration=Debug /p:Platform="Any CPU" /p:EnableNETAnalyzers=true /p:EnforceCodeStyleInBuild=true`
-3. **Type Checking — Nullable Analysis**: Enable nullable reference types and fail on warnings. Command: `msbuild <solution>.sln /t:Build /p:Configuration=Debug /p:Platform="Any CPU" /p:Nullable=enable /p:TreatWarningsAsErrors=true`
+1. **Formatting — CSharpier**: All C# source files must be formatted with CSharpier. Do not use `dotnet format`. Run `dotnet tool restore` first when the manifest tool has not been restored. Apply formatting with `dotnet tool run csharpier format .` and verify read-only with `dotnet tool run csharpier check .`. Always invoke through `dotnet tool run` so the manifest-pinned CSharpier version is used.
+2. **Linting — .NET Analyzers**: C# code must pass Roslyn/.NET analyzer diagnostics. Command: `msbuild <solution>.sln /t:Rebuild /m /p:Configuration=Debug "/p:Platform=Any CPU" /p:EnableNETAnalyzers=true /p:EnforceCodeStyleInBuild=true`. `/t:Rebuild` is intentional for a warm local worktree: `/t:Build` can skip `CoreCompile` through MSBuild incrementality and exit 0 without running analyzers. CI may retain `/t:Build` on a cold checkout.
+3. **Type Checking — Nullable Analysis**: Compiler and nullable-flow diagnostics must pass with warnings as errors. Command: `msbuild <solution>.sln /t:Rebuild /m /p:Configuration=Debug "/p:Platform=Any CPU" /p:TreatWarningsAsErrors=true`. `/t:Rebuild` is required locally so compiler and nullable-flow diagnostics actually run. Projects opt into nullable per file with `#nullable enable`; do not pass `/p:Nullable=enable`, which opts every unannotated file in at once.
 4. **Testing — MSTest + Moq + FluentAssertions**: Run tests with: `vstest.console.exe <test-assembly-paths> /EnableCodeCoverage`
 
 Run the toolchain in order: format → lint → type-check → test. Restart from step 1 if any step fails or changes files.
@@ -80,7 +80,7 @@ This repository adopts a fixed set of FIVE static-analysis packages, wired into
 
 ### Severity-first ordering invariant
 
-All new analyzer rule severities are configured in `.editorconfig` at `severity = suggestion` (never `warning`/`error`) BEFORE any `<Analyzer Include>` item is wired into a project. This is required because the type-check toolchain step runs `msbuild ... /p:Nullable=enable /p:TreatWarningsAsErrors=true`, which promotes any `warning`-severity analyzer diagnostic to a build error. Keeping new analyzer diagnostics at `suggestion` (message level) prevents the analyzer adoption from breaking the protected nullable gate.
+All new analyzer rule severities are configured in `.editorconfig` at `severity = suggestion` (never `warning`/`error`) BEFORE any `<Analyzer Include>` item is wired into a project. This is required because the type-check toolchain step runs `msbuild ... /p:TreatWarningsAsErrors=true`, which promotes any `warning`-severity analyzer diagnostic to a build error. Keeping new analyzer diagnostics at `suggestion` (message level) prevents the analyzer adoption from breaking the protected nullable gate.
 
 ### Deferred analyzer — SecurityCodeScan.VS2019
 

package/resources/claude-customizations/.claude-variants/csharp-legacy/skills/csharp-qa-gate/SKILL.md

@@ -27,11 +27,13 @@ Before invoking this gate, the agent must have:
 
 Run the full toolchain in this exact order. If any step fails or modifies files, fix the issue and restart from step 1. Do not stop the loop until all four steps complete without errors in a single pass.
 
-1. `dotnet tool run csharpier .`
-2. `msbuild <solution>.sln /t:Build /p:Configuration=Debug /p:Platform="Any CPU" /p:EnableNETAnalyzers=true /p:EnforceCodeStyleInBuild=true`
-3. `msbuild <solution>.sln /t:Build /p:Configuration=Debug /p:Platform="Any CPU" /p:Nullable=enable /p:TreatWarningsAsErrors=true`
+1. `dotnet tool restore` (when the manifest tool has not been restored), then `dotnet tool run csharpier format .` to apply formatting and `dotnet tool run csharpier check .` to verify read-only.
+2. `msbuild <solution>.sln /t:Rebuild /m /p:Configuration=Debug "/p:Platform=Any CPU" /p:EnableNETAnalyzers=true /p:EnforceCodeStyleInBuild=true`
+3. `msbuild <solution>.sln /t:Rebuild /m /p:Configuration=Debug "/p:Platform=Any CPU" /p:TreatWarningsAsErrors=true`
 4. `vstest.console.exe <test-assembly-paths> /EnableCodeCoverage`
 
+`/t:Rebuild /m` is intentional for the local gate: on a warm worktree `/t:Build` can skip `CoreCompile` through MSBuild incrementality and exit 0 without running analyzers or the compiler. CI may retain `/t:Build` on a cold checkout. Projects opt into nullable per file with `#nullable enable`; do not pass `/p:Nullable=enable`.
+
 If the environment prevents running any tool, stop and report the change as **unverified**. Do not declare completion.
 
 ## Delta Requirements (Zero-Regression Hard Gate)

package/resources/claude-customizations/config/blast-radius.json

@@ -8,9 +8,7 @@
   "shared_surface_globs": [],
   "modules": {
     "claude-runtime": [".claude/**"],
-    "config": ["config/**"],
-    "docs": ["docs/**"],
-    "tests": ["tests/**"]
+    "config": ["config/**"]
   },
   "over_breadth_fraction": 0.25
 }

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

@@ -107,6 +107,18 @@
     ".claude/lib/model-routing/ModelRouting.psm1",
     ".claude/lib/orchestrator-state/OrchestratorState.psm1",
     ".claude/lib/orchestrator-state/OrchestratorStateCompletion.psm1",
+    ".claude/lib/orchestrator-state/OrchestratorStateCheckpointValue.psm1",
+    ".claude/lib/orchestrator-state/OrchestratorStateReceipts.psm1",
+    ".claude/lib/orchestrator-state/OrchestratorStateModelReceipts.psm1",
+    ".claude/lib/orchestrator-state/OrchestratorStateCodexModelReceipts.psm1",
+    ".claude/lib/orchestrator-state/OrchestratorStateCodexTopologyReceipts.psm1",
+    ".claude/lib/orchestrator-state/OrchestratorStateRoutingMatrix.psm1",
+    ".claude/lib/orchestrator-state/OrchestratorStateCompletionChecks.psm1",
+    ".claude/lib/orchestrator-state/OrchestratorStateRoutingContract.psm1",
+    ".claude/lib/orchestrator-state/OrchestratorStateUnconditional.psm1",
+    ".claude/lib/discovery-validation/DiscoveryValidation.psm1",
+    ".claude/lib/codex-routing/CodexDeployment.psm1",
+    ".claude/lib/codex-routing/CodexTopology.psm1",
     ".claude/lib/blast-radius/BlastRadiusExtraction.psm1",
     ".claude/lib/blast-radius/BlastRadiusGlob.psm1",
     ".claude/lib/blast-radius/BlastRadiusConfig.psm1",

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

@@ -26,7 +26,7 @@ Every unit test must satisfy all five of these properties:
 ## Coverage Requirements
 
 - **Line coverage must remain >= 85% across all tiers (T1–T4).**
-- **Branch coverage must remain >= 75% across all tiers (T1–T4).**
+- **Branch coverage must remain >= 75% across all tiers (T1–T4) for languages whose coverage tooling measures branch coverage.** PowerShell (Pester) and bash (kcov) are the exceptions: neither tool measures branch coverage in any output format, so only the line threshold applies to them and there is no branch-coverage gate. This is a threshold exemption only; PowerShell and bash production files remain in the coverage denominator under the Coverage Exclusion Policy below.
 - Code changes or refactors must not reduce coverage for the lines that were changed.
 - Tier-specific lower coverage thresholds are not used in this repository. See `.agents/skills/quality-tiers.md` for the full tier system.
 - Coverage is a supporting metric, not the sole quality gate. Untested critical behavior is not acceptable even if the overall percentage looks good.

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

@@ -27,7 +27,7 @@ This rule defines the T1–T4 module rigor tier system used by all CI gates in t
 
 ## Uniform-vs-Tier-Dependent Gate Matrix
 
-Per Authoritative Decision #2, line and branch coverage thresholds are uniform across all tiers. Other gates remain tier-dependent.
+Per Authoritative Decision #2, line and branch coverage thresholds are uniform across all tiers. The line threshold applies to every coverage language; the branch threshold applies to languages whose coverage tooling measures branch coverage. Other gates remain tier-dependent.
 
 ### Uniform across all tiers (T1–T4)
 
@@ -36,7 +36,7 @@ Per Authoritative Decision #2, line and branch coverage thresholds are uniform a
 - Type errors: 0.
 - Architecture violations: 0.
 - Line coverage: >= 85%.
-- Branch coverage: >= 75%.
+- Branch coverage: >= 75% for languages whose coverage tooling measures branch coverage. PowerShell (Pester) and bash (kcov) are exempt from this threshold because neither tool measures branch coverage; no branch-coverage gate applies to them.
 - No regression on changed lines.
 
 ### Tier-dependent
@@ -53,4 +53,4 @@ Per Authoritative Decision #2, line and branch coverage thresholds are uniform a
 
 ## Rationale (uniform coverage thresholds)
 
-High test coverage is a fundamental quality-control design choice that enables autonomous agentic development and trust in the work product. For that reason, line coverage >= 85% and branch coverage >= 75% apply uniformly across T1–T4; tier-specific lower coverage floors are not used in this repository.
+High test coverage is a fundamental quality-control design choice that enables autonomous agentic development and trust in the work product. For that reason, line coverage >= 85% applies uniformly across T1–T4 to every coverage language, and branch coverage >= 75% applies uniformly across T1–T4 to every language whose coverage tooling measures branch coverage; tier-specific lower coverage floors are not used in this repository. The branch threshold is not applied to PowerShell or bash because Pester and kcov do not measure branch coverage. That exemption is a capability limit on an unevaluable threshold, not a licence to exclude files from measurement: PowerShell and bash production files remain in the coverage denominator under the Coverage Exclusion Policy in `.agents/skills/general-unit-test/SKILL.md`.

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

@@ -14,9 +14,9 @@ This rule file summarizes the C#-specific policies for this repository.
 
 ## Toolchain
 
-1. **Formatting — CSharpier**: All C# source files must be formatted with CSharpier. Do not use `dotnet format`. Command: `dotnet tool run csharpier .` or `csharpier .`
-2. **Linting — .NET Analyzers**: C# code must pass Roslyn/.NET analyzer diagnostics. Command: `msbuild TaskMaster.sln /t:Build /p:Configuration=Debug /p:Platform="Any CPU" /p:EnableNETAnalyzers=true /p:EnforceCodeStyleInBuild=true`
-3. **Type Checking — Nullable Analysis**: Enable nullable reference types and fail on warnings. Command: `msbuild TaskMaster.sln /t:Build /p:Configuration=Debug /p:Platform="Any CPU" /p:Nullable=enable /p:TreatWarningsAsErrors=true`
+1. **Formatting — CSharpier**: All C# source files must be formatted with CSharpier. Do not use `dotnet format`. Run `dotnet tool restore` first when the manifest tool has not been restored. Apply formatting with `dotnet tool run csharpier format .` and verify read-only with `dotnet tool run csharpier check .`. Always invoke through `dotnet tool run` so the manifest-pinned CSharpier version is used.
+2. **Linting — .NET Analyzers**: C# code must pass Roslyn/.NET analyzer diagnostics. Command: `msbuild TaskMaster.sln /t:Rebuild /m /p:Configuration=Debug "/p:Platform=Any CPU" /p:EnableNETAnalyzers=true /p:EnforceCodeStyleInBuild=true`. `/t:Rebuild` is intentional for a warm local worktree: `/t:Build` can skip `CoreCompile` through MSBuild incrementality and exit 0 without running analyzers. CI may retain `/t:Build` on a cold checkout.
+3. **Type Checking — Nullable Analysis**: Compiler and nullable-flow diagnostics must pass with warnings as errors. Command: `msbuild TaskMaster.sln /t:Rebuild /m /p:Configuration=Debug "/p:Platform=Any CPU" /p:TreatWarningsAsErrors=true`. `/t:Rebuild` is required locally so compiler and nullable-flow diagnostics actually run. Projects opt into nullable per file with `#nullable enable`; do not pass `/p:Nullable=enable`, which opts every unannotated file in at once.
 4. **Testing — MSTest + Moq + FluentAssertions**: Run tests with: `vstest.console.exe <test-assembly-paths> /EnableCodeCoverage`
 
 Run the toolchain in order: format → lint → type-check → test. Restart from step 1 if any step fails or changes files.

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

@@ -29,11 +29,13 @@ Before invoking this gate, the agent must have:
 
 Run the full toolchain in this exact order. If any step fails or modifies files, fix the issue and restart from step 1. Do not stop the loop until all four steps complete without errors in a single pass.
 
-1. `dotnet tool run csharpier .`
-2. `msbuild TaskMaster.sln /t:Build /p:Configuration=Debug /p:Platform="Any CPU" /p:EnableNETAnalyzers=true /p:EnforceCodeStyleInBuild=true`
-3. `msbuild TaskMaster.sln /t:Build /p:Configuration=Debug /p:Platform="Any CPU" /p:Nullable=enable /p:TreatWarningsAsErrors=true`
+1. `dotnet tool restore` (when the manifest tool has not been restored), then `dotnet tool run csharpier format .` to apply formatting and `dotnet tool run csharpier check .` to verify read-only.
+2. `msbuild TaskMaster.sln /t:Rebuild /m /p:Configuration=Debug "/p:Platform=Any CPU" /p:EnableNETAnalyzers=true /p:EnforceCodeStyleInBuild=true`
+3. `msbuild TaskMaster.sln /t:Rebuild /m /p:Configuration=Debug "/p:Platform=Any CPU" /p:TreatWarningsAsErrors=true`
 4. `vstest.console.exe <test-assembly-paths> /EnableCodeCoverage`
 
+`/t:Rebuild /m` is intentional for the local gate: on a warm worktree `/t:Build` can skip `CoreCompile` through MSBuild incrementality and exit 0 without running analyzers or the compiler. CI may retain `/t:Build` on a cold checkout. Projects opt into nullable per file with `#nullable enable`; do not pass `/p:Nullable=enable`.
+
 If the environment prevents running any tool, stop and report the change as **unverified**. Do not declare completion.
 
 ## Delta Requirements (Zero-Regression Hard Gate)

package/resources/codex-and-agents-customizations/.codex/config.toml

@@ -2,7 +2,7 @@ default_permissions = ":danger-full-access"
 
 [mcp_servers.drm-copilot]
 command = "npx"
-args = ["-y", "@danmoisan/drm-copilot-mcp@1.0.23"]
+args = ["-y", "@danmoisan/drm-copilot-mcp@1.0.26"]
 required = true
 enabled_tools = [
     "collect_commit_context",

package/resources/powershell/PoshQC/settings/pester.runsettings.psd1

@@ -90,6 +90,27 @@
             # coverage.
             '.claude/hooks/enforce-discovery-artifact-gate.ps1'
             '.claude/hooks/validate-discovery-artifact-gate.ps1'
+            # Issue #475 added the portable discovery-validation module so both discovery
+            # hooks stop invoking a Python interpreter; measured here so the new production
+            # module is not excluded from coverage.
+            '.claude/lib/discovery-validation/DiscoveryValidation.psm1'
+            # Issue #475 added the portable orchestrator-state parity modules so the
+            # completion hook validates the checkpoint without a Python interpreter;
+            # measured here so the new production modules are not excluded from coverage.
+            '.claude/lib/orchestrator-state/OrchestratorStateCheckpointValue.psm1'
+            '.claude/lib/orchestrator-state/OrchestratorStateReceipts.psm1'
+            '.claude/lib/orchestrator-state/OrchestratorStateModelReceipts.psm1'
+            # Issue #475 added the portable Codex routing resolvers so the U6.X and U6.T
+            # checkpoint checks resolve deployments and topologies without a Python
+            # interpreter; measured here so the new production modules are not excluded.
+            '.claude/lib/codex-routing/CodexDeployment.psm1'
+            '.claude/lib/codex-routing/CodexTopology.psm1'
+            '.claude/lib/orchestrator-state/OrchestratorStateCodexModelReceipts.psm1'
+            '.claude/lib/orchestrator-state/OrchestratorStateCodexTopologyReceipts.psm1'
+            '.claude/lib/orchestrator-state/OrchestratorStateRoutingMatrix.psm1'
+            '.claude/lib/orchestrator-state/OrchestratorStateCompletionChecks.psm1'
+            '.claude/lib/orchestrator-state/OrchestratorStateRoutingContract.psm1'
+            '.claude/lib/orchestrator-state/OrchestratorStateUnconditional.psm1'
             # Issue #392 changed the Invoke-PoshQCTest default seams ($EnsureModule -Global
             # import and the global-session-state $InvokePester trampoline) so the bundled
             # entry path hosts the Pester run in the global session state; measured here so