@danmoisan/drm-copilot-mcp 1.1.10 → 1.1.12

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

@@ -234,6 +234,8 @@ There is no final integration pull request and no fan-in path: the epic surface'
 integration-branch lifecycle has no counterpart on this surface, and its absence is structural
 rather than an omission.
 
+**Checkpoint hygiene (issue #673).** The coordinating session never holds a per-feature checkpoint at its own root. Before the first item delegation of a run it moves any `artifacts/orchestration/orchestrator-state.json` at its root to `artifacts/orchestration/handoff/orchestrator-state.issue-<issue-num>.<yyyy-MM-ddTHH-mm>.json`, and writes none there for the rest of the run, because each item's checkpoint lives in that item's worktree. A gated call the coordinator issues on an item's behalf is resolved by the item's issue number and branch, never by the coordinator root.
+
 ## Parallel-Mode Kickoff Parameter
 
 When `parallel-orchestrator` delegates an item to `Agent(orchestrator)`, the delegation prompt
@@ -326,12 +328,43 @@ Procedure, per item:
 
 **Merge-gate authorization.** `.claude/hooks/enforce-epic-merge-gate.ps1` is a project-wide
 `PreToolUse` Bash-matcher hook that denies any `gh pr merge --merge` unless a checkpoint satisfies
-one of its allow conditions; its block reason is `EPIC_MERGE_GATE_BLOCKED`. The gate now authorizes
-a parallel per-item merge when the parallel-orchestrator checkpoint has `route_id == "parallel"`,
-the target item's `merge_status == "ci_green"`, and, when a PR number is named, it matches the
-item's `pr_number`. Step 3 above is therefore permitted for a legitimate parallel merge; a missing,
-unreadable, or invalid parallel checkpoint, a target item whose `merge_status` is not `ci_green`, or
-a PR number that matches no item still fails closed with `EPIC_MERGE_GATE_BLOCKED`.
+one of its allow conditions; its block reason is `EPIC_MERGE_GATE_BLOCKED`. The gate has
+four allow conditions
+which it evaluates in this order: a per-feature checkpoint with `epic_mode == true` and
+`step9_status == "passed"`; an epic checkpoint whose `epic_merge_pr.ci_gate.conclusion` is
+`success` with a matching `pr_number`; the parallel condition described next; and a standalone
+merge authorization record, described after it. The parallel condition authorizes a per-item merge
+when the parallel-orchestrator checkpoint has `route_id == "parallel"`, the target item's
+`merge_status == "ci_green"`, and, when a PR number is named, it matches the item's `pr_number`.
+Step 3 above is therefore permitted for a legitimate parallel merge; a missing, unreadable, or
+invalid parallel checkpoint, a target item whose `merge_status` is not `ci_green`, or a PR number
+that matches no item still fails closed with `EPIC_MERGE_GATE_BLOCKED`.
+
+The standalone condition (issue #670) is the only route for merging a pull request that is not a
+parallel item, such as a standalone fix that unblocks the run. It is evaluated last and never
+overrides the other three. Writer procedure for the coordinating session:
+
+1. Write the record into a top-level `standalone_merge_authorizations` array in the
+   parallel-orchestrator checkpoint (`artifacts/orchestration/parallel-orchestrator-state.json`);
+   the gate also reads the key from the per-feature and epic checkpoints.
+2. Write one entry per authorized pull request, with these fields: `pr_number` (JSON integer),
+   `pr_url` (ending in `/pull/<pr_number>`), `issue_num` (JSON integer), `branch_name`,
+   `authorized_by`, `authorized_at` (ISO 8601 date-time), `session_id`, `basis` (at least 20
+   characters), and optionally `run_slug`.
+3. Set `session_id` to the session id of the coordinating session that will run the merge
+   command. The gate compares it with the live hook envelope and denies on any difference, so a
+   record written by another session or a previous run authorizes nothing.
+4. Name the pull request explicitly in the merge command (`gh pr merge <PR> --merge`); a bare
+   command never satisfies the standalone condition.
+
+A blanket flag is actively rejected: a `standalone_merge_authorizations` value that names no
+specific pull request (for example `true`) denies with
+`STANDALONE_MERGE_AUTHORIZATION_NOT_PR_SPECIFIC`. Other denials carry
+`STANDALONE_MERGE_AUTHORIZATION_ABSENT`, `STANDALONE_MERGE_AUTHORIZATION_PR_MISMATCH`, or
+`STANDALONE_MERGE_AUTHORIZATION_MALFORMED` (naming the failing field) after the
+`EPIC_MERGE_GATE_BLOCKED` token. The record is a policy-level, auditable declaration, not a
+security control; see the Standalone-Merge-Authorization section of
+`.claude/rules/orchestrator-state.md` for the full field rules and the disclosure.
 
 Branch protection on `main` affects only the pacing of step 3, not its ownership: if `main`
 requires branches to be up to date, an automated `gh pr update-branch` plus re-green cycle is
@@ -344,6 +377,29 @@ Remediation is child-owned and parent-initiated. The conflict is always between
 branch and `origin/main`; there is no integration branch and therefore no fan-in conflict path on
 this surface.
 
+Project-file conflicts are resolved by the parent first (issue #643); the numbered steps below are
+the escalation path.
+
+- (a) On a conflicted `gh pr merge --merge`, the parent runs the two commands
+  `git -C <worktree_path> fetch origin main` and
+  `git -C <worktree_path> merge --no-commit origin/main`.
+- (b) The parent then runs
+  `pwsh -NoProfile -File .claude/lib/project-file-merge/Resolve-MergeableConflict.ps1 -Worktree <worktree_path>`
+  and parses its single JSON object. A `result` of `escalate` makes the parent run
+  `git -C <worktree_path> merge --abort`
+  and continue with step 1 below, including `escalate_paths` in the Blocking finding.
+- (c) On `resolved` the parent stages and commits the resolved paths with a message body listing
+  every entry added from each side and every version choice, then runs the three commands
+  `dotnet tool restore --tool-manifest <worktree_path>/.config/dotnet-tools.json`,
+  `dotnet csharpier check <worktree_path>`, and
+  `dotnet build <worktree_path>/<solution>`, each with path arguments rather than `cd`.
+  A failing check reverts with
+  `git -C <worktree_path> reset --hard HEAD~1`
+  and escalates with the tool output as the finding.
+- (d) On success the parent pushes the item branch, records `mergeable_conflicts_resolved` on the
+  item, sets `merge_status: pr_open`, regenerates `parallel-status.md`, and re-enters
+  `## Per-Item Merge to Main (Merge-on-Green)` at the durable `gh pr checks` confirmation step.
+
 1. On a conflicted `gh pr merge --merge`, the parent detects the failure and re-delegates that item's
    child orchestration, passing the conflict signal and the instruction to resolve against
    `origin/main`. The conflict capture and the finding write both belong to the child's
@@ -427,6 +483,14 @@ whose rows appear only once F6 populates that array; section `## Drift Events` p
 `drift_events[]`, which only F8 populates. An empty array renders an empty section rather than an
 omitted one.
 
+The projection's `## Mergeable Conflicts Resolved` heading renders
+`items[].mergeable_conflicts_resolved`: for each entry the path, the `resolved_at` stamp, the
+`merged_against` ref, the `merge_commit_sha`, the entries added from each side, and the version
+resolutions. The same resolution is cited in three further places: the body of the resolution
+commit message, the pull-request body, and an evidence artifact at
+`docs/features/parallel/<slug>/evidence/other/mergeable-conflicts.<yyyy-MM-ddTHH-mm>.md` carrying
+`Timestamp`, `Command`, `EXIT_CODE`, and the script's JSON output verbatim.
+
 Regeneration boundaries — regenerate at each of the following, not only at final completion:
 
 - Run kickoff, seeding the initial projection from the manifest and the seeded cohorts.
@@ -435,6 +499,7 @@ Regeneration boundaries — regenerate at each of the following, not only at fin
 - Every `recolor_generation` increment.
 - Every append to `mutations[]`.
 - Every append to `drift_events[]`.
+- Every append to an item's `mergeable_conflicts_resolved`.
 - Run completion in `closed` mode, or run close in `open` mode.
 
 Defining the `mutations[]` and `drift_events[]` appends as regeneration boundaries here means F6 and
@@ -444,8 +509,10 @@ F8 need no amendment to these projection rules.
 
 This section is consumption documentation only. The checkpoint schema is owned by F3, defined once
 as prose invariants in `.claude/rules/parallel-orchestration.md`, and enforced by
-`scripts/dev_tools/validate_parallel_orchestrator_state.py`. Consume that schema; add no field to it
-and extend no enum in it.
+`scripts/dev_tools/validate_parallel_orchestrator_state.py`. Consume that schema;
+add no field to it that `.claude/rules/parallel-orchestration.md` does not declare,
+and extend no enum in it. `mergeable_conflicts_resolved` is the one declared optional item
+field.
 
 Fields `parallel-orchestrator` writes to `artifacts/orchestration/parallel-orchestrator-state.json`:
 `objective`, `route_id: "parallel"`, `parallel_slug`, `parallel_manifest_path`,

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

@@ -196,6 +196,10 @@ The facade re-exports the five functions this skill needs: `Get-PlanPaths` (port
 call to `Test-BlastRadius` in `@(...)`: it writes its findings to the pipeline, so a zero-element
 result writes nothing and a one-element result writes a single object.
 
+`Test-BlastRadiusConflict` reads the optional `mergeable_paths` list from that truth table and
+contributes no `path_overlap` edge for a path matching it, while the path itself stays in the
+declared radius and is still read by every audit.
+
 The truth table the port reads is `config/blast-radius.json`, which push-down publishes into the
 destination workspace alongside `.claude`.
 
@@ -312,6 +316,8 @@ The library returns the partition; the planner supplies the record fields.
    `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> ..."`.
    Read the verdict from the conflict key of the returned hashtable.
+   `Test-BlastRadiusConflict` contributes no `path_overlap` edge for a path matching the truth
+   table's optional `mergeable_paths` list, and the path stays in the declared radius.
    The hashtable itself is always truthy, so a bare boolean test on the result treats every pair as
    conflicting and serializes the whole run. This is the sibling hazard to the `@(...)` warning
    above for `Test-BlastRadius`: that function writes an `IList`-shaped pipeline result whose

package/resources/claude-customizations/.claude/skills/powershell-orchestration-state-machine/SKILL.md

@@ -42,6 +42,35 @@ For short-path runs, also persist:
 - `phase0_execution_summary`
 - `resume_after_manual_bootstrap` (next step token)
 
+## Portable Prepared-State Projection
+
+When the PowerShell delivery flow resumes from a provider-neutral prepared-state
+handoff, the active destination projection is
+`artifacts/orchestration/orchestrator-state.json`. Validate and retain:
+
+- the destination provider, checkpoint expression, selected projector,
+  `plan-path`, and exact recorded `next_step`;
+- the portable handoff ID, envelope and latest-history SHA-256 values, selected
+  adapter, source validator, identity, repository/workspace/branch binding,
+  exact plan proof, lifecycle, capabilities, and scheduler context;
+- the source checkpoint path/hash/archive facts and opaque historical receipt
+  references without converting them into Claude receipts; and
+- `destination_evidence: { status: "pending_first_delegation", receipts: [] }`
+  until the first new Claude delegation after materialization.
+
+Do not rediscover the plan or rerun any phase listed in
+`portable_handoff.lifecycle.completed_phases`. Resume only the recorded
+transition. Record Claude model, launch, worktree, and receipt evidence through
+Claude-native fields for new work; functional parity does not require copying
+Codex field names or launch representations.
+
+For a scheduled parallel or epic child, validate the run/item, parent
+checkpoint path/hash, scheduler and child owners, return contract, exact plan
+hash, child checkpoint hash, and result hash before returning a result. The
+ordinary child may update only its bounded status/result projection. Cohort or
+wave order, barriers, fan-in, integration, cleanup, worktree lifecycle, and
+parent completion remain owned by the parent scheduler.
+
 ## Update Protocol
 
 - Write checkpoint after every completed orchestration sub-step.
@@ -55,4 +84,3 @@ On invocation:
 2) If incomplete, resume from `next_step` without re-running `completed_steps`.
 3) If missing or completed, start at phase-0 intake.
 4) If user explicitly requests restart, reset checkpoint and start phase-0.
-

package/resources/claude-customizations/.claude/skills/pr-author/SKILL.md

@@ -76,3 +76,18 @@ writes and the `gh pr create` / `gh pr edit --body-file` handoff.
 - Do not treat PR numbers as issues.
 - Auto-close bullets must use exactly `- Closes #NNN` format, sourced only from "Issues to autoclose" or "Author-asserted autoclose issues."
 - If GitHub validation is unavailable/unverified, do not emit `Closes`; use the fallback `None` bullet.
+
+## Required `--head` on `gh pr create` (issue #687)
+
+Every `gh pr create` command this agent issues MUST carry an explicit
+`--head <branch>` naming the branch the pull request is opened from.
+
+This is what makes the call's target derivable. `enforce-pr-author-skill.ps1` resolves the
+worktree the call pertains to from the command text, and validates the orchestrator checkpoint
+belonging to that worktree. Without `--head`, `gh pr create` infers its head branch from the
+current checkout and the command carries no signal at all, so the gate denies with
+`TARGET_WORKTREE_NOT_DERIVABLE` rather than validating against whichever checkpoint occupies the
+session root, which in a parallel or epic topology belongs to a different item.
+
+Pass `--head` even when the branch is the current one: the gate resolves it to the session root
+and behaves exactly as before, and the command stays correct if it is ever replayed elsewhere.

package/resources/claude-customizations/.claude/skills/quota-throttling/SKILL.md

@@ -0,0 +1,221 @@
+---
+name: quota-throttling
+description: 'Quota throttling and account-switching policy for multi-agent orchestration. Use when pacing agent work against five-hour and seven-day usage limits, deciding whether and when to switch accounts, setting concurrency caps, forecasting a rate-limit wall, handling total weekly exhaustion, or designing a usage monitor. Covers account viability, failover-dependent pacing targets, the measured cost model, commit-before-the-wall, and the coordinator/agent division of labour.'
+---
+
+# Quota Throttling and Account-Switching Policy
+
+Policy for keeping long-running, multi-agent orchestration inside account usage limits without
+losing work. Derived from about five days of continuous multi-agent orchestration (TaskMaster runs
+`bugs-2026-09-11` and `bugs-2026-09-17`).
+
+Every figure marked **MEASURED** was observed; figures marked **ESTIMATE** are extrapolations.
+Cost figures are machine- and repository-specific. Re-measure before relying on them elsewhere.
+
+## When to Use This Skill
+
+Use this skill when:
+
+- a coordinating session runs orchestrators, epic runs, or parallel runs that spawn subagents;
+- deciding whether to start, stagger, hold, or stop agent work because of usage limits;
+- choosing whether and when to switch between accounts;
+- a rate-limit wall is forecast, or every account is exhausted;
+- designing a monitor that watches usage or CI state.
+
+## Reading Quota
+
+The coordinator reads usage from the account switcher, for example `cswap list --json`. The
+fields each rule below depends on:
+
+| Field | Meaning |
+|---|---|
+| `accounts[].active` | Whether the account currently supplies credentials. |
+| `accounts[].usageStatus` | Must be `ok`; any other value makes the account non-viable. |
+| `usage.fiveHour.pct` | Five-hour window utilization, an integer percentage. |
+| `usage.fiveHour.resetsAt` | Authoritative ISO-8601 UTC reset time. `null` means the window has not started. |
+| `usage.sevenDay.pct` | Seven-day utilization, an integer percentage. |
+| `usage.sevenDay.resetsAt` | Authoritative ISO-8601 UTC weekly reset time. |
+| `usage.sevenDay.willLastToReset` | The switcher's own projection of whether the weekly budget lasts. |
+| `usage.*.clock`, `usage.*.countdown` | Human-readable display values. `clock` is LOCAL time; do not use it for arithmetic. |
+
+Some switchers switch automatically on the five-hour threshold alone and do not consult the
+seven-day window. Such a switcher can hand over to an account whose five-hour window has reset
+but whose weekly budget is spent. Apply section 1 yourself rather than relying on the switcher.
+
+## 1. Account Viability
+
+An account is a viable target only if BOTH hold:
+
+- seven-day usage < 95%
+- five-hour usage < 90%
+
+The weekly gate dominates. An account at >= 95% weekly is NOT a viable target regardless of its
+five-hour state, and must be excluded from all pacing math.
+
+The binding budget is `min(five-hour headroom to 90%, weekly headroom to 95%)`. Compute both every
+time. Late in a week the weekly headroom is usually the smaller number, and the five-hour window
+is then irrelevant.
+
+## 2. Pacing Target Depends on Whether a Failover Exists
+
+**Two or more viable accounts: front-load.** Target about 90% of the five-hour window in about
+2 hours (about 45% per hour). Reaching 90% triggers a switch, so the unused remainder of the
+window costs nothing.
+
+**Exactly one viable account: spread.** Target about 90% across the WHOLE five-hour window (about
+18% per hour). Front-loading here is wrong: reaching 90% at the 2-hour mark produces a stall of
+about 3 hours with no account to switch to.
+
+These are different policies, not different settings of one policy. Applying the two-account
+target to a one-account situation is the most expensive mistake observed (see section 12,
+item 1).
+
+## 3. Cost Model (MEASURED, Serialized Single Items)
+
+| Activity | Five-hour points | Weekly points | Wall clock |
+|---|---|---|---|
+| Coordination only (API calls, git, checkpoint writes, no agents) | ~3 total | negligible | — |
+| One item, full cycle (child + executor + toolchain + coverage run) | ~17 | ~3 | ~43 min |
+| One plan revision, or a low-cost item | ~4-5 | — | — |
+| Three items entering Phase 0 simultaneously | 96-108 per hour | — | a full five-hour window in 62 min |
+
+Builds and test runs consume wall-clock time but zero quota. A long quiet period at 0% per hour
+with agents alive usually means they are inside a build, not stalled.
+
+Ratio (ESTIMATE, two data points): one full five-hour window is about 14 weekly points.
+
+## 4. Concurrency Control
+
+A concurrency cap governs an orchestrator's DIRECT children. Each child spawns its own
+grandchildren (executors, planners, researchers), and those are the dominant consumers. Always
+express a cap as a budget on TOTAL AGENTS IN THE SUBTREE, and require that it be propagated
+verbatim to every level.
+
+A cap change only restricts NEW starts. It does nothing to work already running. Cutting a cap
+from 6 to 2 mid-flight changed the burn rate by zero, because the cost was in agents already
+alive.
+
+For in-flight burn there are exactly two controls:
+
+- **Commit-and-hold** — finish the current task, commit, start nothing new.
+- **Stopping agents outright** — destructive; use only as a last resort.
+
+**Stagger starts.** The dominant cost driver is not item count; it is simultaneous Phase 0
+cycles. Bring items in one at a time and let each settle before starting the next.
+
+## 5. Measurement Discipline
+
+- The usage percentage is an INTEGER. At 5-minute sampling the computed rate quantizes to
+  multiples of about 12% per hour. Do not react to a single sample; measure over spans of at
+  least 15 minutes.
+- The FIRST sample after an account switch is inflated by batched accounting. Take a second
+  reading before acting on it, but do not dismiss it either; it has been partly real more than
+  once.
+- Reset times: the human-readable `clock` field is LOCAL time. The ISO `resetsAt` field is
+  authoritative. Convert before doing arithmetic; a four-hour error from this changed a plan.
+- Five-hour window elapsed time = 300 − (minutes until reset). The window starts on first use,
+  not on a fixed clock boundary.
+- VERIFY a reset directly before resuming. Never infer it from the clock. A reset timestamp can
+  pass while the counter still reads the old value for a minute or two.
+
+## 6. Approaching a Wall
+
+Commit BEFORE the wall, not at it. A rate-limit error terminates an agent immediately; the agent
+does not wait out the gap and resume. The duration of the outage does not change this risk: even
+a 60-second gap terminates in-flight work.
+
+Sequence when a wall is forecast:
+
+1. Order all in-flight children to COMMIT NOW, in whatever state, without finishing the current
+   task. A committed partial result is recoverable; an uncommitted complete one is not.
+2. Let them keep working until the wall actually arrives.
+3. Set the commit checkpoint with real margin, and recompute it as the rate moves. A checkpoint
+   that lands ON the forecast wall protects nothing.
+
+Git operations are LOCAL and consume no model quota; they succeed on a fully exhausted account.
+If errors start before committing finishes, keep retrying the COMMIT specifically and nothing
+else.
+
+## 7. Total Weekly Exhaustion
+
+When no account is viable:
+
+1. **Serialize** — stop all parallel activity; zero new starts.
+2. **Commit ALL working documents across ALL worktrees** — every item worktree, the plan-home
+   worktree, and every in-flight child, not only the current item.
+3. **Report and hold.**
+
+This differs from a routine pause: the outage may last days, so nothing may be left uncommitted
+on the assumption of a quick return.
+
+## 8. Switching
+
+- Switch at 90% of the five-hour window IF a viable target exists.
+- If no viable target exists, do NOT switch; hold until the earliest reset. Switching onto an
+  exhausted account produces immediate failures.
+- Verify the switch landed (active account, both windows) before releasing work.
+- A mid-flight credential change is transparent to running agents. Instruct them explicitly not
+  to treat the change, or a brief error around it, as a failure signal.
+
+## 9. Usage Credits and Overage
+
+Never spend credits on work. The ONLY sanctioned use is completing a non-destructive
+serialization and commit so that work is not lost. If any path offers to continue past a limit
+by consuming credits, stop and ask the user.
+
+## 10. Reserve Policy
+
+Holding an account's last few points as an emergency commit reserve is correct ONLY while
+something is uncommitted. Verify first: if every branch is pushed and every worktree is clean,
+the reserve protects nothing and should be spent on useful work instead. Check before assuming.
+
+## 11. Monitor Design
+
+Report on thresholds, not on every sample. An idle monitor that fires every ten minutes costs a
+turn each time and hides the signal among routine readings.
+
+**A check for the ABSENCE of a bad state is satisfied by the absence of ALL state.** A CI waiter
+polling for "no pending checks" reported SETTLED during the window between one run being
+superseded and the next registering, when no checks existed at all. Require a POSITIVE assertion
+instead: a conjunction that an empty set cannot satisfy (for example, "at least one required check
+exists AND none is pending").
+
+Alert on:
+
+- threshold crossings;
+- a sustained rate above target;
+- a non-`ok` status;
+- account-viability changes;
+- window rollovers.
+
+Stay silent otherwise.
+
+## 12. Observed Failure Modes
+
+1. Applying the two-account front-load target with only one viable account.
+   Cost: about 95 minutes of idle time.
+2. Cutting a concurrency cap to control burn from work already running.
+   Cost: none directly, but the effective control went unused while the window drained.
+3. Launching multiple items into simultaneous Phase 0.
+   Cost: a full five-hour window in 62 minutes.
+4. Assuming a fallback account was fresh without checking.
+   Cost: about 1 hour, and seven items' preparation output stranded uncommitted when agents were
+   terminated.
+5. Setting a commit checkpoint that landed on the forecast wall instead of before it.
+6. Reacting to single 5-minute samples inside the quantization band, producing cap oscillation
+   that achieved nothing.
+
+## 13. Division of Labour
+
+An orchestrating agent generally CANNOT see quota. Do not ask it to estimate usage. The workable
+split is:
+
+- the **agent** reports its COST PROFILE: how many agents are alive, what kind of work they are
+  doing, and what it is about to start;
+- the **coordinator** supplies the MEASUREMENT and the decision.
+
+Have the agent announce before starting each item, and reply with a live reading.
+
+Corollary: if the coordinator is slow to respond, the agent should proceed on its own rather than
+stall. A four-hour idle period occurred because an agent correctly held for a ruling that was
+never sent. Absorbing a small pacing error is preferable to repeating that.

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

@@ -22,6 +22,13 @@
     ".agents/skills/**",
     "scripts/vscode/**"
   ],
+  "mergeable_paths": [
+    "**/*.csproj",
+    "**/packages.config",
+    "**/app.config",
+    "**/*.vbproj",
+    "**/*.props"
+  ],
   "modules": {
     "config": ["config/**"]
   },

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

@@ -27,12 +27,14 @@
     ".claude/hooks/enforce-discovery-artifact-gate.ps1",
     ".claude/hooks/enforce-epic-invocation-origin.ps1",
     ".claude/hooks/enforce-epic-merge-gate.ps1",
+    ".claude/hooks/enforce-epic-merge-gate-authorization.ps1",
     ".claude/hooks/enforce-epic-wave-barrier.ps1",
     ".claude/hooks/enforce-epic-worktree-removal-gate.ps1",
     ".claude/hooks/enforce-evidence-locations.ps1",
     ".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-epic-scope.ps1",
     ".claude/hooks/enforce-orchestration-preimplementation-gate-helpers.ps1",
     ".claude/hooks/enforce-orchestration-preimplementation-gate-modes.ps1",
     ".claude/hooks/enforce-parallel-abandon-gate.ps1",
@@ -44,8 +46,11 @@
     ".claude/hooks/enforce-pr-author-skill.epic-base-branch.ps1",
     ".claude/hooks/enforce-pr-author-skill.ps1",
     ".claude/hooks/enforce-pr-author-skill-helpers.ps1",
+    ".claude/hooks/enforce-prd-feature-before-planner-helpers.ps1",
     ".claude/hooks/enforce-prd-feature-before-planner.ps1",
     ".claude/hooks/enforce-promotion-mcp-only.ps1",
+    ".claude/hooks/hook-command-invocation.ps1",
+    ".claude/hooks/hook-command-scanner.ps1",
     ".claude/hooks/persist-session-id.ps1",
     ".claude/hooks/validate-bash.ps1",
     ".claude/hooks/validate-discovery-artifact-gate.ps1",
@@ -101,6 +106,7 @@
     ".claude/skills/pr-author/SKILL.md",
     ".claude/skills/pr-base-branch-merge-base/SKILL.md",
     ".claude/skills/pr-context-artifacts/SKILL.md",
+    ".claude/skills/quota-throttling/SKILL.md",
     ".claude/skills/remediation-handoff-atomic-planner/SKILL.md",
     ".claude/skills/research-issue/SKILL.md",
     ".claude/skills/review-epic/SKILL.md",
@@ -134,6 +140,11 @@
     ".claude/lib/blast-radius/BlastRadius.psm1",
     ".claude/lib/blast-radius/BlastRadiusNormalization.psm1",
     ".claude/lib/blast-radius/BlastRadiusTokenShape.psm1",
+    ".claude/lib/cleanup-manifest/CleanupWorktreeManifest.psm1",
+    ".claude/lib/blast-radius/BlastRadiusConflict.psm1",
+    ".claude/lib/project-file-merge/ProjectFileMergeGrammar.psm1",
+    ".claude/lib/project-file-merge/ProjectFileMerge.psm1",
+    ".claude/lib/project-file-merge/Resolve-MergeableConflict.ps1",
     ".claude/rules/parallel-orchestration.md",
     ".claude/rules/shell.md",
     ".claude/lib/bash/compute-cohorts.sh",
@@ -156,6 +167,11 @@
     ".claude/lib/mermaid/MermaidLineScanner.psm1",
     ".claude/lib/mermaid/MermaidMarkdownFences.psm1",
     ".claude/lib/mermaid/MermaidValidation.psm1",
+    ".claude/lib/worktree-resolution/WorktreeResolution.psm1",
+    ".claude/lib/worktree-resolution/WorktreeTargetResolution.psm1",
+    ".claude/lib/worktree-resolution/WorktreeItemResolution.psm1",
+    ".claude/lib/worktree-resolution/EpicScopeResolution.psm1",
+    ".claude/lib/worktree-resolution/EpicScopeReadiness.psm1",
     ".claude/skills/mermaid-diagram/references/flowchart.md",
     ".claude/skills/mermaid-diagram/references/sequence.md",
     ".claude/skills/mermaid-diagram/references/class.md",

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

@@ -16,7 +16,7 @@ agent profile.
 2. Run the canonical topology resolver before choosing a logical agent:
 
    ```powershell
-   poetry run python -m scripts.dev_tools.resolve_codex_topology `
+   pwsh -NoProfile -File .codex/scripts/Resolve-CodexTopology.ps1 `
      --language <python|powershell|csharp|typescript> `
      --production-file-count <count> `
      --test-file-count <count> `
@@ -53,7 +53,7 @@ epic root personas are forced independently of file count.
 5. Run the canonical resolver:
 
    ```powershell
-   poetry run python -m scripts.dev_tools.resolve_codex_deployment `
+   pwsh -NoProfile -File .codex/scripts/Resolve-CodexDeployment.ps1 `
      --logical-agent <agent> `
      --complexity-band <C1|C2|C3|C4> `
      --execution-context <context> `
@@ -96,15 +96,14 @@ incomplete, and request a policy change. Do not silently fall back.
 ## Validation
 
 Before accepting delegated results or reporting completion, validate the
-checkpoint with the Codex routing gate:
-
-```powershell
-poetry run python -m scripts.dev_tools.validate_orchestration_artifacts `
-  orchestrator-state artifacts/orchestration/orchestrator-state.json `
-  --require-codex-topology `
-  --require-codex-model-routing
-```
-
-For epic execution use `epic-orchestrator-state` with the same flag. The MCP
-`validate_orchestration_artifacts` surface is the authoritative completion gate
-when available.
+checkpoint with the Codex routing gate by calling the MCP tool
+`validate_orchestration_artifacts` with these arguments:
+
+- `artifact_type`: `orchestrator-state` (use `epic-orchestrator-state` for epic
+  execution)
+- `artifact_path`: `artifacts/orchestration/orchestrator-state.json`
+- `workspace_root`: the repository root
+- `require_codex_topology`: `true`
+- `require_codex_model_routing`: `true`
+
+The MCP tool is the authoritative completion gate and needs no Python toolchain.

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

@@ -39,6 +39,47 @@ On every invocation, the main session must:
    selected route's required agents, skills, and MCP tools into checkpoint
    state.
 
+## Prepared-State Portable Handoff Intake
+
+Treat a portable prepared-state checkpoint as a resume request, not as a new
+orchestration intake. Before delegation:
+
+1. Validate the portable envelope through the published, workspace-explicit
+   orchestration authority. Require the repository, workspace, branch lineage,
+   issue, feature folder, work mode, scheduler context, capabilities, and exact
+   next transition to match the current checkout. Supply the complete
+   caller-controlled independent expected context on every call to
+   `resolve_orchestration_topology`, `resolve_provider_routing`, and
+   `transition_prepared_orchestration`: `expected_repository_id`,
+   `expected_workspace_root`, `expected_branch`, `expected_source_head_sha`,
+   `allowed_head_relationship`, `expected_issue_number`,
+   `expected_feature_folder`, `expected_work_mode`, `expected_plan_path`, and
+   `expected_plan_sha256`. Derive each value from the destination checkout and
+   the caller's own record. A call that omits a value, or that copies one from
+   the envelope under validation, is rejected before any service invocation.
+2. Prove the plan from the independently expected repository-relative path and
+   raw-byte SHA-256 the caller supplied in `expected_plan_path` and
+   `expected_plan_sha256`. Do not search for another plan, rewrite the path,
+   follow a symlink outside the repository, substitute a newer plan, or read
+   the plan identity from the envelope.
+3. Use `transition_prepared_orchestration` as the only authority permitted to
+   materialize the provider-native destination checkpoint. A dry run may
+   validate and project the destination state but must not archive or replace
+   checkpoint bytes.
+4. Preserve the ordered completed phases and reject any request to replay one
+   of them. Do not rerun promotion, research, feature-document authoring,
+   atomic planning, or preflight when the envelope records them as complete.
+5. Preserve source-provider model, profile, topology, launch, and receipt data
+   as opaque historical evidence. Resolve Codex topology, model routing, and
+   launch evidence only for the first new destination delegation after
+   materialization; never synthesize Codex receipts for source-provider work.
+
+For an ordinary handoff whose recorded next transition is `atomic_execution`,
+resume the exact approved plan through the ordinary Codex atomic-executor path
+at `atomic_execution`. Do not invoke a parent scheduler or rediscover lifecycle
+work. Any contract, authority, plan, replay, or materialization failure returns
+the deterministic blocked result before destination delegation.
+
 ## Epic Entry Boundary
 
 This standalone workflow must not invoke `epic-planner` or `epic-orchestrator`. If intake names

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

@@ -17,6 +17,47 @@ A hardened snapshot from another repository contains a JSON Schema for the orche
 
 This prohibition is specific to the disqualified foreign schema identified by the `drmoisan.github.io/mix-calculator/` `$id`. A schema whose `$id` is repo-local and whose required-field set and `additionalProperties` policy match this repository's checkpoint contract is not the disqualified foreign artifact; even so, the repository's enforcement mechanism remains the Python validator prose-and-logic above, not an imported schema file.
 
+## Portable Handoff Projection Invariants
+
+A provider-native destination checkpoint materialized from the portable handoff
+contract must retain the following linkage:
+
+- `provider`, `checkpoint_expression`, and `destination_projector` identify the
+  destination expression and selected adapter.
+- `plan-path` and `next_step` equal the portable envelope's exact plan path and
+  recorded lifecycle transition. The destination must not rediscover a plan or
+  replace either value from local convention.
+- `portable_handoff` retains the handoff ID, envelope SHA-256, latest history
+  entry SHA-256, adapter identity, source validator, identity and binding
+  fields, source checkpoint/archive facts, exact plan proof, lifecycle,
+  capabilities, and scheduler context.
+- Historical source receipts remain opaque references under
+  `portable_handoff.source.expression.historical_receipts`. They must not be
+  rewritten as destination-provider receipts.
+- `destination_evidence` starts as `pending_first_delegation` with an empty
+  receipt list. Destination routing, topology, model, and receipts may be
+  recorded only for the first new delegation after checkpoint materialization.
+
+The portable lifecycle permits only the registered state transitions:
+`legacy_v1` to migration, `preparation_complete` to
+`prepared_to_atomic_execution`, `validated` to destination materialization,
+`materialized` to `atomic_execution`, and a bounded scheduled-child return from
+an authorized child execution phase. An attempted replay of a completed phase
+is invalid.
+
+A failed contract, binding, capability, authority, plan, replay, dirty-worktree,
+candidate, archive, or replacement check must produce the deterministic blocked
+result and leave the source checkpoint authoritative. A blocked result must
+retain the primary `HANDOFF_*` code and affected paths where applicable; it must
+not record a completed transition or destination delegation.
+
+For parallel and epic children, `return_to_scheduler` accepts only a result
+whose run, item, parent checkpoint path/hash, scheduler owner, child execution
+owner, return contract, plan hash, child checkpoint hash, and result hash match
+the envelope. The child may return that bounded result but may not assume
+cohort or wave ordering, barriers, fan-in, integration, cleanup, or parent
+completion authority.
+
 ## Scope and Backward Compatibility
 
 These invariants apply only when the checkpoint contains a top-level `remediation_loop` with a `cycles` array. A checkpoint with no `remediation_loop` (the existing step-based checkpoint shape) is unaffected: it validates exactly as before and produces no new errors. The invariants are additive.