@danmoisan/drm-copilot-mcp 1.1.17 → 1.1.19

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

@@ -34,11 +34,11 @@ Write timestamped artifacts into the active feature folder:
 - `policy-audit.<timestamp>.md`
 - `code-review.<timestamp>.md`
 - `feature-audit.<timestamp>.md`
-- `remediation-inputs.<timestamp>.md` when remediation is required
-- `remediation-plan.<timestamp>.md` when remediation is required
+- `remediation-inputs.<timestamp>.md` for every review with at least one blocking finding, including `HALT_NON_REMEDIABLE` and `AWAITING_CI` reviews
+- `remediation-plan.<timestamp>.md` only when the verdict is `REMEDIATION_REQUIRED`
 
 The final review report MUST end with these exact single-line fields:
-- `REVIEW_STATUS: PASS` or `REVIEW_STATUS: REMEDIATION_REQUIRED`
+- `REVIEW_STATUS: PASS`, `REVIEW_STATUS: REMEDIATION_REQUIRED`, `REVIEW_STATUS: HALT_NON_REMEDIABLE`, or `REVIEW_STATUS: AWAITING_CI`
 - `FEATURE_FOLDER: <path>`
 - `POLICY_AUDIT: <path>`
 - `CODE_REVIEW: <path>`
@@ -46,6 +46,28 @@ The final review report MUST end with these exact single-line fields:
 - `REMEDIATION_INPUTS: <path-or-NONE>`
 - `REMEDIATION_PLAN: <path-or-NONE>`
 
+`HALT_NON_REMEDIABLE` and `AWAITING_CI` require `REMEDIATION_PLAN: NONE`.
+
+### Remediability Contract
+
+Every blocking finding receives exactly one remediability class (exact, case-sensitive):
+- `autonomous`: repository remediation can resolve the finding without a human decision. This is the default when a finding block carries no remediability line.
+- `external_dependency`: a system, service, runtime, or published artifact outside the repository is unavailable or mismatched.
+- `policy_hold`: proceeding requires a policy decision, exception, or authorization the orchestrator may not grant.
+- `awaiting_ci`: the finding resolves when a CI result that has not completed becomes available.
+- `human_decision_required`: a human must choose between alternatives or approve a direction.
+
+A published MCP runtime that lags the repository contract is classified `external_dependency`.
+
+The verdict follows from the classes of all blocking findings: no blocking findings is `PASS`; at least one `autonomous` finding is `REMEDIATION_REQUIRED`; otherwise at least one `external_dependency`, `policy_hold`, or `human_decision_required` finding is `HALT_NON_REMEDIABLE`; otherwise every finding is `awaiting_ci` and the verdict is `AWAITING_CI`.
+
+The remediation inputs file carries these line formats:
+- one line `Review-Verdict: <VERDICT>` for the review,
+- inside each blocking finding block, one line `Remediability: <class>`,
+- inside each blocking finding block, one line `Remediability-Evidence: <text>` stating why the class applies.
+
+These lines, including the evidence text, never contain the substrings the orchestrator counts when it counts blocking findings, so their presence does not change the blocking count.
+
 Each required review artifact MUST pass the matching validator command before review can be reported as complete:
 - the `validate_orchestration_artifacts` MCP tool with `artifact_type: "policy-audit"` and `artifact_path: <path>`
 - the `validate_orchestration_artifacts` MCP tool with `artifact_type: "code-review"` and `artifact_path: <path>`
@@ -63,10 +85,12 @@ Each required review artifact MUST pass the matching validator command before re
 5. Create the policy audit, code review, and feature audit.
    - validate each artifact immediately after writing it
 6. Check off passing acceptance criteria in the authoritative requirement sources per `acceptance-criteria-tracking`.
-7. If remediation is required, create remediation inputs first and then hand off plan creation using `remediation-handoff-atomic-planner`.
+7. Classify every blocking finding per the Remediability Contract. Remediation is required only when at least one blocking finding is `autonomous`. If remediation is required, create remediation inputs first and then hand off plan creation using `remediation-handoff-atomic-planner`. When every blocking finding is non-remediable, write the remediation inputs, report `HALT_NON_REMEDIABLE` or `AWAITING_CI` with `REMEDIATION_PLAN: NONE`, create no remediation plan target, and do not hand off to `atomic-planner`.
 8. In the final report:
-   - set `REVIEW_STATUS: PASS` only when no remediation artifact is required,
-   - set `REVIEW_STATUS: REMEDIATION_REQUIRED` when remediation inputs or a remediation plan were required,
+   - set `REVIEW_STATUS: PASS` only when no blocking finding exists,
+   - set `REVIEW_STATUS: REMEDIATION_REQUIRED` when at least one blocking finding is `autonomous`,
+   - set `REVIEW_STATUS: HALT_NON_REMEDIABLE` when no blocking finding is `autonomous` and at least one is `external_dependency`, `policy_hold`, or `human_decision_required`,
+   - set `REVIEW_STATUS: AWAITING_CI` when every blocking finding is `awaiting_ci`,
    - include every required artifact-path field exactly once.
 
 ### Enforced Remediation Handoff Contract

package/resources/codex-and-agents-customizations/.agents/skills/feature-review-workflow/SKILL.md

@@ -63,6 +63,17 @@ Always apply:
   - if the marker is missing or malformed, use `full-feature`
   - if `minor-audit` is selected and `issue.md` lacks `## Acceptance Criteria`, require remediation
 
+## Policy Rules
+
+### modified-workflow-needs-green-run
+
+If the branch diff modifies any path matching `.github/workflows/**`, `scripts/benchmarks/**`, or `.github/actions/**`, the policy audit emits a Blocking finding unless evidence of a green workflow run against the branch head is present in the remediation inputs.
+
+- The rule provides a second, independent line of defense for CI-gate-modifying features, separate from and prior to the orchestrator CI Green Gate (S9).
+- "Green workflow run against the branch head" means a run of the affected workflow whose conclusion is success and which satisfies either (a) or (b): (a) its head SHA equals the current branch head; or (b) all three predecessor-head conditions hold: (1) the run's head SHA is an ancestor of, or equal to, the current branch head and contains the latest commit that changes any path outside the active feature folder (`git merge-base --is-ancestor <commit> <run-sha>`); (2) every commit after the run's head SHA changes only paths inside the active feature folder (`git log <run-sha>..HEAD -- . ":!<feature-folder>"` returns no commits); (3) the policy audit states that the orchestrator CI Green Gate (S9) remains responsible for `ci_gate.conclusion == "success"` with `ci_gate.head_sha` equal to the final PR head before DONE. Condition (b) exists because an in-repo evidence artifact cannot name the SHA of the commit that contains it.
+- A green `workflow_dispatch` run against the branch head also satisfies the rule, not only a PR-context run. This mitigates the chicken-and-egg case where a feature must land its CI gate before the gate can run in PR context (see spec.md Risks & Mitigations).
+- When the rule fires and no qualifying green-run evidence is present, record a Blocking finding classified `awaiting_ci` (the remediation inputs carry `Remediability: awaiting_ci` and a `Remediability-Evidence:` line naming the awaited workflow) and route it to the wait path (`AWAITING_CI` when no other class is present) instead of the remediation handoff.
+
 ## Ordered Procedure
 
 1. **Resolve the base branch**
@@ -97,10 +108,7 @@ Always apply:
         - Python: `poetry run pytest --cov` → artifact: `artifacts/python/lcov.info`
         - PowerShell: `mcp__drm-copilot__run_poshqc_test` → artifact: `artifacts/pester/powershell-coverage.xml`
         - C#: `vstest.console.exe <test-assembly-paths> /EnableCodeCoverage` → artifact: `artifacts/csharp/coverage.xml`
-        - Coverage thresholds:
-          - New code files (added in this feature): line coverage must be >= 90%. Flag as FAIL otherwise.
-          - Modified files (changed but previously existing): line coverage must show no regression relative to baseline and must remain >= 80%. Flag as FAIL otherwise.
-          - Repo-wide line coverage must remain >= 80% per language. Flag as FAIL otherwise.
+        - Coverage thresholds: when the repository's root `CLAUDE.md` states a line or branch coverage threshold, that threshold governs; otherwise the defaults govern (line 85%, branch 75% for branch-capable languages). Each metric falls back independently. New files and modified files must meet the governing line threshold (and the branch threshold where measured); modified files must also show no regression on changed lines. Repo-wide coverage per language must meet the governing thresholds. 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.
@@ -134,8 +142,10 @@ Always apply:
      - toolchain checks fail
      - the code review contains blockers
      - required acceptance criteria are FAIL or PARTIAL
-     - coverage regression below policy threshold (< 80% repo-wide per language, < 80% or regression for modified files, or < 90% for new files)
+     - coverage below the governing thresholds defined in step 5 (repo-wide per language, modified files including any regression on changed lines, or new files)
      - coverage artifact absent for any language that has changed files
+   - Classify each blocking finding before triggering remediation: every blocking finding receives one `Remediability` class (`autonomous`, `external_dependency`, `policy_hold`, `awaiting_ci`, or `human_decision_required`; `autonomous` when no class is stated).
+   - Trigger remediation only for `autonomous` findings. When no blocking finding is `autonomous`, write the remediation inputs, report `HALT_NON_REMEDIABLE` (at least one `external_dependency`, `policy_hold`, or `human_decision_required` finding) or `AWAITING_CI` (every finding `awaiting_ci`) with `REMEDIATION_PLAN: NONE`, create no remediation plan target, and do not hand off to `atomic-planner`.
    - Create `remediation-inputs.<timestamp>.md` first.
    - Create the target remediation plan file from the canonical plan template.
    - Hand off plan creation through `remediation-handoff-atomic-planner`.
@@ -145,7 +155,7 @@ Always apply:
    - Verify every reported artifact exists on disk before reporting completion.
    - Report artifact paths and a concise go/no-go recommendation for PR readiness.
    - End the final report with these exact single-line fields:
-     - `REVIEW_STATUS: PASS` or `REVIEW_STATUS: REMEDIATION_REQUIRED`
+     - `REVIEW_STATUS: PASS`, `REVIEW_STATUS: REMEDIATION_REQUIRED`, `REVIEW_STATUS: HALT_NON_REMEDIABLE`, or `REVIEW_STATUS: AWAITING_CI`
      - `FEATURE_FOLDER: <path>`
      - `POLICY_AUDIT: <path>`
      - `CODE_REVIEW: <path>`

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

@@ -29,7 +29,7 @@ Apply these priorities in order when designing or changing code:
 
 ## Module Rigor Tiers
 
-Module rigor tiers (T1–T4) and the uniform-versus-tier-dependent gate matrix are defined in `.agents/skills/quality-tiers.md`. Every project must be classified in `quality-tiers.yml` at repo root.
+Module rigor tiers (T1–T4) and the uniform-versus-tier-dependent gate matrix are defined in `.agents/skills/quality-tiers/SKILL.md` and apply only when `quality-tiers.yml` exists at the repository root; in that case every project must be classified in it. A repository without `quality-tiers.yml` has not adopted tiers, and the tier requirements do not apply.
 
 ## Mandatory Toolchain Loop
 

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

@@ -23,10 +23,11 @@ Every unit test must satisfy all five of these properties:
 
 ## Coverage Requirements
 
+- Threshold precedence: when the repository's root `AGENTS.md` states line or branch coverage thresholds, those thresholds govern; when `AGENTS.md` states none, thresholds stated in the repository's root `CLAUDE.md` govern. The 85% line and 75% branch figures are defaults that apply only when neither root `AGENTS.md` nor root `CLAUDE.md` states thresholds. This precedence applies to every restatement of these figures in other skills, agents, and rule files. Each metric falls back independently: when a root file states only a line threshold or only a branch threshold, that threshold governs its metric and the next source in this order, ending with the default, governs the other.
 - **Line coverage must remain >= 85% 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.
+- Tier-specific lower coverage thresholds are not used. See `.agents/skills/quality-tiers/SKILL.md` for the full tier system, which applies only when `quality-tiers.yml` exists at the repository root.
 - Coverage is a supporting metric, not the sole quality gate. Untested critical behavior is not acceptable even if the overall percentage looks good.
 - Configure coverage tooling to exclude test files (e.g., `tests/`) so metrics reflect application code, not tests.
 - Type-only / interface-only modules with no executable behavior may be omitted from coverage measurement. Examples: Python `Protocol`-only modules consumed only under `TYPE_CHECKING`, TypeScript interface/type-only files, and C# interface-only files. Such modules legitimately report 0% executable coverage and may be excluded from measurement. This is a clarification only; it does not lower any coverage threshold.
@@ -89,7 +90,7 @@ Colocation — placing test files alongside production source files in `src/` or
 
 ## Test Categories
 
-The following test categories apply across the repository, with tier-dependent obligations per `.agents/skills/quality-tiers.md`:
+The following test categories apply across the repository, with tier-dependent obligations per `.agents/skills/quality-tiers/SKILL.md`; those tier-dependent obligations apply only when `quality-tiers.yml` exists at the repository root:
 
 - **Unit tests** — required for all tiers (T1–T4). Cover single units of behavior in isolation.
 - **Property-based tests** — required for T1 and T2 modules: at least one property test per pure function. Use `fast-check` (TypeScript) or `hypothesis` (Python) where applicable.

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

@@ -128,6 +128,11 @@ route.
   `not-applicable`, and `blocked_reason: "none"`.
 - Do not edit production code, execute the plan, author or edit a PR, run feature review, monitor
   CI, set `next_step: "complete"`, record `S12_complete`, or claim feature completion.
+- Premise-falsified halt: use `blocked_reason: "premise_falsified"` when every delegation and
+  validator succeeded but evidence gathered during execution falsified the plan's premise. Still
+  record the evidence path in free-form checkpoint keys; `blocked_reason` carries only the
+  classification. The preparation terminal checkpoint above still sets `blocked_reason: "none"`.
+  The full `blocked_reason` vocabulary and its partition are in `.claude/rules/orchestrator-state.md`.
 
 Only the literal JSON Boolean `false` in the route configuration disables the CI requirement.
 Missing, malformed, string-valued, or unknown route data fails closed. The preparation mutation
@@ -290,10 +295,12 @@ skill use. The checkpoint must include:
 - `required_mcp_tools`: exactly the selected route's `required_mcp_tools`
 - `delegation_receipts`: one receipt for each required agent
 - `skill_receipts`: one required receipt for each required skill, with evidence
-- `mcp_call_receipts`: one successful receipt for each required MCP tool
+- `mcp_call_receipts`: one successful receipt for each required MCP tool unless a valid `issue_adoption` record waives it
 - `local_execution_overrides`: an empty list at completion
 - `delegation_bypasses`: an empty list at completion
 - `lifecycle_operations`: any lifecycle operation must record `surface: "mcp"`
+- `ci_gate`: the CI result object defined in `## CI Green Gate`, with keys `conclusion`, `head_sha`, and `verified_at`
+- `pr_gate`: the pull-request object defined in `## CI Green Gate`, with keys `pr_number`, `pr_url`, `head_branch`, and `head_sha`
 
 If any required handoff, skill receipt, MCP receipt, or empty bypass list is
 missing, `validate_orchestration_artifacts --require-complete` fails and the
@@ -405,22 +412,32 @@ The review subagent compares against a base branch; uncommitted changes are invi
 After each `feature-reviewer` delegation returns:
 
 1. Read the exact terminal status lines from the review result.
-2. If the result does not include `REVIEW_STATUS: PASS` or `REVIEW_STATUS: REMEDIATION_REQUIRED`, stop and record blocked state.
-3. If the result is `REVIEW_STATUS: PASS`, advance to the PR creation gate.
-4. If the result is `REVIEW_STATUS: REMEDIATION_REQUIRED`, require both `REMEDIATION_INPUTS: <path>` and `REMEDIATION_PLAN: <path>` and then enter the remediation loop.
+2. If the result does not include `REVIEW_STATUS: PASS`, `REVIEW_STATUS: REMEDIATION_REQUIRED`, `REVIEW_STATUS: HALT_NON_REMEDIABLE`, or `REVIEW_STATUS: AWAITING_CI`, stop and record blocked state.
+3. When the remediation inputs carry a `Review-Verdict:` line, recompute the verdict from the finding classes (a blocking finding block without a remediability line counts as `autonomous`). A mismatch between the declared and recomputed verdicts is a reviewer contract error: record it under `artifact_errors`, re-request the review once, and halt with `blocked_reason: "delegate_contract_incomplete"` if it persists.
+4. Append a `remediation_loop.review_outcomes[]` entry (`verdict` plus one `findings[]` object with `remediability` per blocking finding) for every review, including `PASS`.
+5. If the result is `REVIEW_STATUS: PASS`, advance to the PR creation gate.
+6. If the result is `REVIEW_STATUS: REMEDIATION_REQUIRED`, require both `REMEDIATION_INPUTS: <path>` and `REMEDIATION_PLAN: <path>` and then enter the remediation loop with the plan scoped to the `autonomous` findings; non-remediable findings carry forward unchanged.
+7. If the result is `REVIEW_STATUS: HALT_NON_REMEDIABLE`, require `REMEDIATION_PLAN: NONE` and halt: set `blocked_reason` to the highest-precedence halt class present, append one `human_interaction.requirements[]` entry with `response: "halt"` for each halt class present (`external_dependency`, `policy_hold`, `human_decision_required`) describing the human action needed, leave `remediation_loop.completed_attempts` unchanged, write no cycle, create no remediation plan, and stop. The precedence is:
+
+   Halt precedence: human_decision_required > policy_hold > external_dependency
+
+8. If the result is `REVIEW_STATUS: AWAITING_CI`, require `REMEDIATION_PLAN: NONE` and wait: set `blocked_reason: "awaiting_ci"`, set `next_step` to the step that re-checks (`S7_feature_review` for a review-time wait, `S9_ci_green` for a CI poll timeout), record no `human_interaction.requirements[]` entry for the wait, write no cycle, and create no remediation plan. Poll within the existing bounded CI interval and timeout; when the bound is exhausted, persist and stop. On resume, set `blocked_reason: "none"` and re-run the named step. For a review-time wait, the awaited workflow is named in the finding's `Remediability-Evidence:` line.
+9. A CI Green Gate poll timeout is recorded as a finding with `Remediability: awaiting_ci` and follows the wait path; a failed check stays `autonomous` and enters the remediation loop.
 
 ## Remediation Loop (R1–R5)
 
-A bounded loop consisting of five steps. The loop variable `remediation_pass` starts at 1 and increments at R5 before returning to R1.
+A bounded loop consisting of five steps. The attempt count is `remediation_loop.completed_attempts`, and `remediation_pass` equals `remediation_loop.completed_attempts`. The active cycle number is `completed_attempts + 1`; `remediation_loop.current_cycle` is a record position in `cycles[]`, not a count. A halt or wait verdict never opens a cycle, and every cycle opened from a review records `opened_by_review`, the zero-based index of that `review_outcomes[]` entry.
+
+Cycle accounting: a remediation attempt is complete when R3 execution finished (`execution_status: "complete"`) and the pre-R4 commit recorded a non-empty change set; only then set `candidate_applied: true` on that cycle and increment `completed_attempts`. A cycle that ends without a candidate (execution not started, execution failed, or an empty staged change set) records `candidate_applied: false` and consumes no number. It is followed by at most one re-plan under the same number when the executor output identifies an autonomous plan defect; otherwise reclassify the blocker (typically `external_dependency`) and halt. Two consecutive no-candidate cycles halt with `step6_status: "blocked_remediation_loop_limit"`.
 
 - **R1 — Remediation plan of record:** Use the exact `REMEDIATION_PLAN: <path>` returned by the review as the starting plan of record for the loop.
 - **R2 — Preflight clearance:** Delegate to `atomic-executor` for precondition validation only (no implementation). If the executor does not return `PREFLIGHT: ALL CLEAR`, return to R1 by re-delegating to `atomic-planner` against the same remediation-plan path with the required-changes output from the executor. Only after `PREFLIGHT: ALL CLEAR` may the orchestrator advance to R3.
 - **R3 — Remediation execution:** Delegate to `atomic-executor` with full execution authorization. Each task's toolchain loop (format → lint → type-check → test) is mandatory; no skipping.
 - **Pre-R4 commit:** Stage all changes (`git add -A`), run MCP tool `collect_commit_context`, delegate to `commit_steward` using the resulting artifact, and commit with the generated message. Advance to R4 only after a successful commit.
 - **R4 — Re-audit:** Refresh PR context via MCP tool `collect_pr_context`, then delegate to `feature-reviewer` with the same inputs as the original review (resolved base branch, feature folder, refreshed PR context artifacts, acceptance-criteria source). No scope narrowing. The canonical issue number line must be included.
-- **R5 — Loop-exit decision:** If the re-audit returns `REVIEW_STATUS: PASS`, exit the loop and advance to the PR creation gate. Otherwise, record `remediation_pass` increment in the checkpoint and return to R1.
+- **R5 — Loop-exit decision:** Evaluate the re-audit per Post-Review Outcome Evaluation. If it returns `REVIEW_STATUS: PASS`, exit the loop and advance to the PR creation gate. If it returns `REVIEW_STATUS: HALT_NON_REMEDIABLE` or `REVIEW_STATUS: AWAITING_CI`, follow the halt or wait branch instead of opening the next cycle. Otherwise, record the cycle's `candidate_applied` value and the resulting `completed_attempts` in the checkpoint and return to R1.
 
-**Termination guard:** If `remediation_pass` reaches 3 without resolution, the orchestrator records `step6_status: "blocked_remediation_loop_limit"` in the checkpoint and halts. No further automation is attempted.
+**Termination guard:** Halt after three completed attempts: when `remediation_loop.completed_attempts` equals 3 and the latest verdict is not `PASS`, the orchestrator records `step6_status: "blocked_remediation_loop_limit"` in the checkpoint and halts. No further automation is attempted.
 
 ## Issue Number Consistency
 
@@ -436,9 +453,24 @@ If a subagent artifact references a different issue number, the orchestrator rej
 ## CI Green Gate
 
 Before PR/DONE completion, the orchestrator must observe the live PR head SHA
-and required GitHub checks through `gh`. The checkpoint must record the checked
-head SHA and CI result. DONE is blocked unless the required checks pass for the
-current PR head SHA.
+and every GitHub check on that head SHA through `gh`. The checkpoint must record
+the checked head SHA and CI result. DONE is blocked unless every check on the
+current PR head SHA passed or was skipped.
+
+Gate procedure:
+
+1. Resolve the live PR head SHA and the PR base branch with `gh pr view --json headRefOid,baseRefName`.
+2. Invoke `gh pr checks --json bucket,name,state,link,workflow` against that head SHA. The query covers every check on the head SHA for every PR, whether or not branch protection marks the check as required.
+3. Parse the JSON by running `pwsh -NoProfile -File .claude/lib/ci-gate/Invoke-CiGateParser.ps1 -ChecksJson <checks-json> -HeadSha <head-sha>`, appending `-RequireWorkflow CI` when the PR base branch is an `epic/<slug>-integration` branch. The parser derives `ci_gate.conclusion` over every queried check: `success` when every check passed or was skipped, `failure` when any check failed or was cancelled, and `pending` when any check is still in progress.
+4. Epic-child rule: when the PR base branch is an `epic/<slug>-integration` branch, an empty check list is not accepted as green. Every check returned by the unfiltered query counts: a failing or cancelled non-`CI` check fails the gate, and a pending one keeps it pending. With `-RequireWorkflow CI`, the parser never returns `success` until at least one passing `CI` check is observed.
+5. No-checks rule: when `gh pr checks` fails with a `no checks reported` error, that error is never treated as green for any PR. On an epic child, the parser runs with `-ChecksJson '[]'` and `-RequireWorkflow CI`, which returns `pending`; on any other PR the gate stays `pending` within the bounded poll.
+6. Parser-absent rule: when `.claude/lib/ci-gate/Invoke-CiGateParser.ps1` does not exist in the repository, the orchestrator does not derive `success` by hand; it must stop and persist blocked state before PR/DONE completion.
+
+The checkpoint records the CI result in a top-level `ci_gate` object with the required keys `conclusion`, `head_sha`, and `verified_at`. `conclusion` is one of `success`, `failure`, or `pending`; `head_sha` is the PR head SHA the queried checks were observed against; `verified_at` is the ISO-8601 time at which this gate (S9) recorded the result. DONE requires `ci_gate.conclusion` equal to `success` and `ci_gate.head_sha` equal to the current PR head SHA. The key set is defined by `CI_GATE_KEYS` in `scripts/dev_tools/validate_orchestrator_state.py`, and the TypeScript MCP validator used by the Codex runtime requires the same keys.
+
+The checkpoint records the pull request in a top-level `pr_gate` object with the keys `pr_number`, `pr_url`, `head_branch`, and `head_sha`. The key set is defined by `PR_GATE_KEYS` in `scripts/dev_tools/_orchestrator_state_routing.py`.
+
+CI-dependent acceptance criteria are criteria whose verification requires the result of CI on the PR head. The item's own orchestrator run owns their check-off. After `ci_gate.conclusion` is `success`, check off each CI-dependent criterion in the item's own worktree, commit, push to the PR branch, and re-run this gate against the new head SHA, so that `ci_gate.head_sha` equals the final PR head before DONE. A failed re-run enters the Remediation Loop (R1–R5) as a blocking finding; the shared `remediation_loop.completed_attempts` count and its halt after three completed attempts are unchanged. A parent or coordinating session never commits these check-offs from its own root.
 
 ## PR Creation Gate
 
@@ -450,7 +482,7 @@ The orchestrator must not create a PR, push a branch for PR purposes, or report
 2. The AC verification artifact (`p14-acceptance-criteria-checkoff.md` or equivalent) confirms all acceptance criteria pass.
 3. The mandatory toolchain passed in its most recent run on the branch (no linting/type-check/test failures).
 4. The checkpoint `next_step` is `S8_create_pr`.
-5. The required CI checks pass for the current PR head SHA.
+5. Every check on the current PR head SHA passed or was skipped (`ci_gate.conclusion` is `success`).
 
 This gate is non-negotiable. Each condition is independently verified before PR creation proceeds.
 

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

@@ -9,7 +9,7 @@ Source: legacy Claude rule `orchestrator-state`.
 
 # Orchestrator-State Remediation-Cycle and Human-Interaction Invariants
 
-This rule governs remediation-cycle records and the optional `human_interaction` block in the orchestrator-state checkpoint at `artifacts/orchestration/orchestrator-state.json`. It documents three invariants that must hold for each remediation cycle, plus three invariants for the `human_interaction` block, so that resume and review workflows do not depend on a structurally invalid checkpoint.
+This rule governs remediation-cycle records and the optional `human_interaction` block in the orchestrator-state checkpoint at `artifacts/orchestration/orchestrator-state.json`. It documents the invariants that must hold for each remediation cycle and for the remediation-loop review outcomes and attempt count, plus three invariants for the `human_interaction` block, so that resume and review workflows do not depend on a structurally invalid checkpoint.
 
 ## Foreign Schema Warning (do not copy verbatim)
 
@@ -60,7 +60,7 @@ 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.
+These invariants apply only when the checkpoint contains a top-level `remediation_loop`; the per-cycle invariants apply when it has a `cycles` array, and the review-outcome and attempt-count invariants apply when their keys are present. 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.
 
 ## Invariants (per remediation cycle)
 
@@ -70,6 +70,45 @@ These invariants apply only when the checkpoint contains a top-level `remediatio
 
 3. **Exit gate requires zero blocking findings.** When a cycle's `exit_condition_met == true`, its `blocking_count` must be `0`. A non-zero `blocking_count` with `exit_condition_met == true` is a malformed cycle (the exit gate was marked satisfied while blocking findings remained).
 
+4. **`candidate_applied` is a boolean (R5).** When a cycle object carries `candidate_applied`, its value must be a JSON boolean, and any other value is a malformed cycle.
+
+5. **A completed attempt requires completed execution (R6).** A cycle whose `candidate_applied == true` must have `execution_status == "complete"`, and `candidate_applied == true` with any other execution status is a malformed cycle.
+
+6. **`opened_by_review` references a remediation review (R11).** When a cycle object carries `opened_by_review`, its value must be a non-negative integer (not a boolean) that indexes an object entry of the `remediation_loop.review_outcomes` list whose `verdict` is `REMEDIATION_REQUIRED`, and a value that is not such an integer, is out of range, or references an outcome with any other verdict is a malformed cycle.
+
+7. **`completed_attempts` counts completed attempts (R7).** When `remediation_loop.completed_attempts` is present, it must be a non-negative integer (not a boolean) equal to the number of object cycles whose `candidate_applied` is `true` (zero when `cycles` is absent or not a list), and any other value is a malformed loop.
+
+## Invariants (remediation_loop.review_outcomes)
+
+These invariants apply only when `remediation_loop` contains a `review_outcomes` key. The orchestrator appends one entry per review, including a `PASS` review, in the shape `{"verdict": <verdict>, "findings": [{"remediability": <class>}, ...]}`, where `findings` lists the review's blocking findings only. A halt or wait verdict records no remediation cycle.
+
+Review verdicts (exact, case-sensitive):
+
+| Verdict | Condition over the classes of the review's blocking findings |
+|---|---|
+| `PASS` | No blocking findings. |
+| `REMEDIATION_REQUIRED` | At least one `autonomous` finding. |
+| `HALT_NON_REMEDIABLE` | No `autonomous` finding, and at least one `external_dependency`, `policy_hold`, or `human_decision_required` finding. |
+| `AWAITING_CI` | At least one finding, and every finding is `awaiting_ci`. |
+
+Remediability classes (exact, case-sensitive) and the `blocked_reason` member (#523) that a halt or wait records for each class:
+
+| Class | Meaning | `blocked_reason` member |
+|---|---|---|
+| `autonomous` | Repository remediation can resolve the finding without a human decision. | none (remediation loop) |
+| `external_dependency` | A system, service, runtime, or published artifact outside the repository is unavailable or mismatched. | `external_dependency` |
+| `policy_hold` | Proceeding requires a policy decision, exception, or authorization that the orchestrator may not grant. | `policy_hold` |
+| `awaiting_ci` | The finding resolves when a CI result that has not completed becomes available. | `awaiting_ci` |
+| `human_decision_required` | A human must choose between alternatives or approve a direction. | `human_decision_required` |
+
+Derivation order. The verdict is a pure function of the findings' classes, evaluated in this order: no findings yields `PASS`; any `autonomous` finding yields `REMEDIATION_REQUIRED`; any `external_dependency`, `policy_hold`, or `human_decision_required` finding yields `HALT_NON_REMEDIABLE`; otherwise the verdict is `AWAITING_CI`.
+
+1. **`review_outcomes` is a list of objects (R8).** `review_outcomes` must be a list, and each entry must be an object. A non-list value or a non-object entry is malformed.
+
+2. **Verdict and class membership (R9).** Each outcome's `verdict` must be a string among the four verdicts, its `findings` must be a list (a missing key is not a list), and each finding must be an object whose `remediability` is a string among the five classes. Comparisons are case-sensitive, so a case variant such as `Pass` or `Autonomous` is malformed.
+
+3. **Verdict matches its findings (R10).** When an outcome passes the membership checks, its `verdict` must equal the verdict that the derivation order yields for its findings' classes. A mismatch is a malformed outcome.
+
 ## Human-Interaction Scope and Backward Compatibility
 
 These invariants apply only when the checkpoint contains a top-level `human_interaction` block. A checkpoint with no `human_interaction` key (the existing checkpoint shape) is unaffected: it validates exactly as before and produces no new errors. The invariants are additive and support the autonomous-execution mandate documented in `.agents/skills/orchestrate/SKILL.md`.

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

@@ -157,6 +157,13 @@ Blocked-reason enum:
   - `commit_context_missing`
   - `no_staged_changes`
   - `pre_implementation_gate_violation`
+  - `premise_falsified` — Every delegation and validator succeeded, but evidence gathered during execution falsified the premise on which the plan was built, so continuing would implement an invalid plan.
+  - `external_dependency` — The run cannot proceed because a system, service, runtime, or artifact outside the repository's control is unavailable or mismatched, and no in-repository remediation can resolve it.
+  - `policy_hold` — The run is stopped because proceeding requires a policy decision, exception, or authorization that the orchestrator is not permitted to grant autonomously.
+  - `awaiting_ci` — The run is waiting for a CI result that has not yet completed, and no remediation is warranted until that result is available.
+  - `human_decision_required` — The run requires a human to choose between alternatives or approve a direction before it can continue.
+
+Blocked-reason partition: `none` (or JSON `null`) means the run is not blocked. The six validator-enforced members `spawn_agent_unavailable`, `delegation_launch_failed`, `delegate_no_receipt`, `delegate_contract_incomplete`, `validator_failed`, and `user_requested_stop` form the mechanical partition. The five members `premise_falsified`, `external_dependency`, `policy_hold`, `awaiting_ci`, and `human_decision_required` form the non-mechanical partition. The full vocabulary is published in `.claude/rules/orchestrator-state.md`.
 
 Pre-implementation violation schema:
 - `pre-implementation-violation` MUST be either `null` or an object with:
@@ -198,7 +205,8 @@ Completion-state invariants:
 - every required skill MUST have a matching required `skill_receipts[].skill`
   with non-empty evidence.
 - every required MCP tool MUST have a successful `mcp_call_receipts[].tool`
-  receipt with non-empty evidence.
+  receipt with non-empty evidence, unless a valid `issue_adoption` record
+  waives the tool.
 - `local_execution_overrides` and `delegation_bypasses` MUST be empty lists at
   completion.
 - every recorded `lifecycle_operations[]` item MUST use `surface: "mcp"`.
@@ -228,6 +236,8 @@ Do not advance on summaries alone when an exact result signal is required.
 - feature review result:
   - `REVIEW_STATUS: PASS`
   - `REVIEW_STATUS: REMEDIATION_REQUIRED`
+  - `REVIEW_STATUS: HALT_NON_REMEDIABLE`
+  - `REVIEW_STATUS: AWAITING_CI`
   - `FEATURE_FOLDER: <path>`
   - `POLICY_AUDIT: <path>`
   - `CODE_REVIEW: <path>`
@@ -382,18 +392,23 @@ Required behavior:
 
 Apply this loop after any required review returns `REVIEW_STATUS: REMEDIATION_REQUIRED`.
 
+Attempt accounting: `remediation-pass` equals `remediation_loop.completed_attempts`, the number of cycles whose `candidate_applied` is `true`. A cycle records `candidate_applied: true` only when remediation execution completed and the remediation commit recorded a non-empty change set. The active cycle number is `completed_attempts + 1`, and a cycle without a candidate consumes no number. Cap: halt after three completed attempts, that is, when `completed_attempts` equals 3 and the latest review is not `REVIEW_STATUS: PASS`, with `step6_status: "blocked_remediation_loop_limit"`.
+
+Halt and wait branches: a review that returns `REVIEW_STATUS: HALT_NON_REMEDIABLE` or `REVIEW_STATUS: AWAITING_CI` never enters or continues this loop and opens no cycle. On `HALT_NON_REMEDIABLE`, set `blocked_reason` to the highest-precedence halt class present (`human_decision_required`, then `policy_hold`, then `external_dependency`), append one `human_interaction.requirements[]` entry with `response: "halt"` per halt class present, and stop. On `AWAITING_CI`, set `blocked_reason: "awaiting_ci"`, set `next_step` to the step that re-checks, persist, and stop; on resume, set `blocked_reason: "none"` and re-run that step.
+
 1. Persist `review-status`, `remediation-inputs-path`, `remediation-plan-path`, and `remediation-pass` in the checkpoint.
 2. Delegate `atomic-executor` in validation-only mode against the exact `remediation-plan-path`.
 3. If the executor returns `PREFLIGHT: REVISIONS REQUIRED`, delegate `atomic-planner` to update the same `remediation-plan-path` in place and then repeat preflight clearance.
 4. Only after `PREFLIGHT: ALL CLEAR`, delegate `atomic-executor` to execute the remediation plan exactly as written.
 5. Stage all files with `git add -A`.
 6. If staging is empty after execution, set `blocked_reason` to `no_staged_changes` and stop.
+   - Record `candidate_applied: false` for that cycle; it consumes no attempt number.
 7. Use `repo-automation-adapter` to run MCP tool `collect_commit_context`, capture the returned on-disk artifact path as `commit-context-path`, and stop with `blocked_reason: commit_context_missing` if that path is unavailable.
 8. Delegate `commit-steward` using `commit-context-path` as the authoritative staged-change input.
 9. Commit the staged work with the exact message returned by `commit-steward`.
 10. Use `repo-automation-adapter` to refresh PR-context artifacts through MCP tool `collect_pr_context` with the resolved base branch.
 11. Delegate `feature-reviewer` again with the refreshed PR context.
-12. If the new review still returns `REVIEW_STATUS: REMEDIATION_REQUIRED`, increment `remediation-pass` and repeat the loop. Exit only when the latest review returns `REVIEW_STATUS: PASS`.
+12. Record `candidate_applied: true` for the cycle and set `remediation_loop.completed_attempts` and `remediation-pass` to the new count. If the new review still returns `REVIEW_STATUS: REMEDIATION_REQUIRED`, repeat the loop under the cap. Exit only when the latest review returns `REVIEW_STATUS: PASS`, or follow the halt or wait branch.
 
 ## Completion Gates
 
@@ -404,7 +419,7 @@ Do not claim mission completion until all of the following are true:
 - small-path implementation has a receipt from the exact language-specific generated
   typed-engineer deployment profile
 - all required skills have `skill_receipts` with evidence
-- all required MCP tools have successful `mcp_call_receipts`
+- all required MCP tools have successful `mcp_call_receipts`, unless a valid `issue_adoption` record waives the tool
 - no local execution override or delegation bypass is recorded
 - the checkpoint is updated with the final state
 - the canonical checkpoint path was used without sidecar replacement or backup substitution
@@ -421,7 +436,7 @@ Do not claim mission completion until all of the following are true:
 - any required remediation loop run also includes a remediation execution receipt, a remediation commit receipt, and a final `REVIEW_STATUS: PASS`
 - validator-backed checks for the approved plan, policy audit, code review, feature audit, and checkpoint state pass
 - the canonical checkpoint passes `validate_orchestration_artifacts` with `artifact_type: "orchestrator-state"`, `require_complete: true`, `require_codex_topology: true`, and `require_codex_model_routing: true`
-- required GitHub checks pass for the current PR head SHA before PR/DONE completion
+- every GitHub check on the current PR head SHA passed or was skipped before PR/DONE completion
 
 ## Hard Constraints
 

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

@@ -9,19 +9,21 @@ Source: legacy Claude rule `quality-tiers`.
 
 # Module Rigor Tiers
 
-This rule defines the T1–T4 module rigor tier system used by all CI gates in this repository. The tier system source of truth is `docs/ci.research.md` section 1; the file `quality-tiers.yml` at the repository root maps every project to a tier. Adding a project without a tier classification fails CI.
+Applicability: this skill (`.agents/skills/quality-tiers/SKILL.md`) applies only when `quality-tiers.yml` exists at the repository root, which indicates that the repository has adopted module rigor tiers. When that file is absent, there is no tier classification requirement, no `tier-classification` CI stage, and no tier-dependent gate (the escape-hatch limits, property-test density, mutation score, contract-bump rule, determinism retry rate, golden tests, and E2E suite scope in the Tier-dependent table below), and the absence of `quality-tiers.yml` is not a defect. The coverage defaults listed under Uniform across all tiers do not depend on tier adoption; their precedence is stated in that section.
+
+When `quality-tiers.yml` exists, this skill defines the T1–T4 module rigor tier system used by the repository's CI gates, and the tier definitions and gate matrix in this document are the tier system's source of truth.
 
 ## Tiers
 
-- **T1 — Critical.** Behavior bugs cause silent data loss, model drift, or security holes. Examples (No-COM architecture): classifier engines (SpamBayes, Triage), ToDo ID allocator and hierarchy operations, Graph extended-properties adapter, auth/token handling, host-agnostic command bus.
-- **T2 — Core.** Bugs cause feature regressions but not data loss. Examples: `TaskMaster.Domain`, `TaskMaster.Application`, mail-item DTOs, settings store abstraction, schema definitions.
-- **T3 — Adapters & UI.** Glue around APIs the team does not own. Examples: Outlook task pane UI, Office.js wrappers, Microsoft Graph SDK wrappers, persistence I/O.
+- **T1 — Critical.** Behavior bugs cause silent data loss, model drift, or security holes. Examples: classifier and scoring engines, identifier allocators and hierarchy operations, adapters that write to an external system of record, authentication and token handling, command dispatch.
+- **T2 — Core.** Bugs cause feature regressions but not data loss. Examples: domain and application layers, data-transfer objects, settings store abstractions, schema definitions.
+- **T3 — Adapters & UI.** Glue around APIs the team does not own. Examples: user-interface surfaces, host-platform API wrappers, third-party API and SDK wrappers, persistence I/O.
 - **T4 — Scaffolding.** Examples: DI wiring, bootstrap, build scripts, dev tooling, generated code, manifests.
 
 ## Source of Truth
 
-- `quality-tiers.yml` at repo root maps every project to one tier.
-- The CI pipeline's `tier-classification` stage validates that every project entry has a tier and that no unclassified project exists. Adding a project without a tier classification fails CI.
+- When `quality-tiers.yml` exists at the repository root, it maps every project to one tier.
+- In a repository that runs a `tier-classification` CI stage, that stage validates that every project entry has a tier and that no unclassified project exists, and it fails CI for an unclassified project.
 
 ## Uniform-vs-Tier-Dependent Gate Matrix
 
@@ -29,6 +31,8 @@ Per Authoritative Decision #2, line and branch coverage thresholds are uniform a
 
 ### Uniform across all tiers (T1–T4)
 
+Threshold precedence: when the repository's root `AGENTS.md` states line or branch coverage thresholds, those thresholds govern; when `AGENTS.md` states none, thresholds stated in the repository's root `CLAUDE.md` govern. The 85% line and 75% branch figures are defaults that apply only when neither root `AGENTS.md` nor root `CLAUDE.md` states thresholds. This precedence applies to every restatement of these figures in other skills, agents, and rule files. Each metric falls back independently: when a root file states only a line threshold or only a branch threshold, that threshold governs its metric and the next source in this order, ending with the default, governs the other.
+
 - Format check: 100% pass.
 - Lint errors: 0.
 - Type errors: 0.
@@ -51,4 +55,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% 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`.
+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. These figures are defaults under the threshold precedence stated above: a root `AGENTS.md` or root `CLAUDE.md` that states coverage thresholds overrides them. Each metric falls back independently, so a root file that states only one of the two thresholds overrides only that one. 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/skills/remediation-handoff-atomic-planner/SKILL.md

@@ -20,6 +20,8 @@ Trigger remediation when any of these are true:
 - Toolchain checks fail.
 - Acceptance criteria are not met.
 
+Remediation triggers only on blocking findings classified `autonomous`. Each blocking finding carries one remediability class (`autonomous`, `external_dependency`, `policy_hold`, `awaiting_ci`, or `human_decision_required`). Non-remediable findings halt (`HALT_NON_REMEDIABLE`) or wait (`AWAITING_CI`): they receive remediation inputs but no remediation plan target and no `atomic_planner` handoff.
+
 ## Required Remediation Inputs
 
 Create `remediation/<timestamp>/remediation-inputs.md` (one timestamped `remediation/` folder per cycle; reaudit artifacts from a triggering or exit review live under the sibling `audit/<timestamp>/` folder, per the canonical pattern documented in the Claude-side `remediation-handoff-atomic-planner` skill) with:

package/resources/codex-and-agents-customizations/.agents/skills/translate-claude-to-codex/SKILL.md

@@ -282,7 +282,7 @@ Every completion response must include:
 | `.claude/agents/<name>.md` | `.codex/agents/<name>.toml` | model + sandbox OS-enforced; tools allowlist re-grounded |
 | `.claude/settings.json` `permissions` | `[permissions.<name>]` in `config.toml` | OS-enforced via sandbox; more expressive than Claude |
 | `.claude/hooks/*.ps1` (PreToolUse) | `[hooks] PreToolUse` + script | direct equivalent; exit 2 / permissionDecision deny |
-| `.claude/hooks/*.ps1` (SubagentStop, exit 1) | `[hooks] SubagentStop` + required CI check | degraded; CI status check is the hard gate |
+| `.claude/hooks/*.ps1` (SubagentStop, exit 2) | `[hooks] SubagentStop` + required CI check | degraded; CI status check is the hard gate |
 | `permissions.deny` (secrets) | `[permissions.<name>.filesystem]` deny | OS-enforced |
 
 ## Invocation Examples

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

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

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

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

package/resources/codex-and-agents-customizations/.codex/agents/atomic-executor-c1.toml

@@ -93,6 +93,17 @@ Use the scoped tool patterns for quality gates:
 
 Run toolchain in order: format, lint, type-check, test. Restart from step 1 if any step fails or changes files.
 
+## Scratch Location
+
+Concurrent child runs in one session share one session scratchpad, so every scratch file a run writes lives in a directory unique to the child.
+
+- `SCRATCH` resolves to `<session scratchpad>/issue-<issue-num>/`, where `<issue-num>` is the plan's canonical issue number.
+- Every scratch file, helper script, staged copy, and coverage report a plan names lives under `SCRATCH`. Subdirectories such as `SCRATCH/stage/` are permitted.
+- Create `SCRATCH` before the first scratch write. Never write a scratch file to the scratchpad root or to a fixed shared name outside `SCRATCH`.
+- When a plan written before this rule defines `SCRATCH` as the bare session scratchpad, treat that definition as `<session scratchpad>/issue-<issue-num>/`. This is a mechanical micro-action, not replanning.
+- Plans and evidence artifacts record the literal token `SCRATCH`, never a host path.
+- If two runs for the same issue can execute at once, the run-unique form `issue-<issue-num>-<yyyy-MM-ddTHH-mm>` replaces `issue-<issue-num>`.
+
 ## Preflight Validation
 
 When receiving a plan with directive `DIRECTIVE: PREFLIGHT VALIDATION ONLY`, perform validation only and return exactly one of `PREFLIGHT: ALL CLEAR` or `PREFLIGHT: REVISIONS REQUIRED`.

package/resources/codex-and-agents-customizations/.codex/agents/atomic-executor-c2.toml

@@ -93,6 +93,17 @@ Use the scoped tool patterns for quality gates:
 
 Run toolchain in order: format, lint, type-check, test. Restart from step 1 if any step fails or changes files.
 
+## Scratch Location
+
+Concurrent child runs in one session share one session scratchpad, so every scratch file a run writes lives in a directory unique to the child.
+
+- `SCRATCH` resolves to `<session scratchpad>/issue-<issue-num>/`, where `<issue-num>` is the plan's canonical issue number.
+- Every scratch file, helper script, staged copy, and coverage report a plan names lives under `SCRATCH`. Subdirectories such as `SCRATCH/stage/` are permitted.
+- Create `SCRATCH` before the first scratch write. Never write a scratch file to the scratchpad root or to a fixed shared name outside `SCRATCH`.
+- When a plan written before this rule defines `SCRATCH` as the bare session scratchpad, treat that definition as `<session scratchpad>/issue-<issue-num>/`. This is a mechanical micro-action, not replanning.
+- Plans and evidence artifacts record the literal token `SCRATCH`, never a host path.
+- If two runs for the same issue can execute at once, the run-unique form `issue-<issue-num>-<yyyy-MM-ddTHH-mm>` replaces `issue-<issue-num>`.
+
 ## Preflight Validation
 
 When receiving a plan with directive `DIRECTIVE: PREFLIGHT VALIDATION ONLY`, perform validation only and return exactly one of `PREFLIGHT: ALL CLEAR` or `PREFLIGHT: REVISIONS REQUIRED`.

package/resources/codex-and-agents-customizations/.codex/agents/atomic-executor-c3-elevated.toml

@@ -93,6 +93,17 @@ Use the scoped tool patterns for quality gates:
 
 Run toolchain in order: format, lint, type-check, test. Restart from step 1 if any step fails or changes files.
 
+## Scratch Location
+
+Concurrent child runs in one session share one session scratchpad, so every scratch file a run writes lives in a directory unique to the child.
+
+- `SCRATCH` resolves to `<session scratchpad>/issue-<issue-num>/`, where `<issue-num>` is the plan's canonical issue number.
+- Every scratch file, helper script, staged copy, and coverage report a plan names lives under `SCRATCH`. Subdirectories such as `SCRATCH/stage/` are permitted.
+- Create `SCRATCH` before the first scratch write. Never write a scratch file to the scratchpad root or to a fixed shared name outside `SCRATCH`.
+- When a plan written before this rule defines `SCRATCH` as the bare session scratchpad, treat that definition as `<session scratchpad>/issue-<issue-num>/`. This is a mechanical micro-action, not replanning.
+- Plans and evidence artifacts record the literal token `SCRATCH`, never a host path.
+- If two runs for the same issue can execute at once, the run-unique form `issue-<issue-num>-<yyyy-MM-ddTHH-mm>` replaces `issue-<issue-num>`.
+
 ## Preflight Validation
 
 When receiving a plan with directive `DIRECTIVE: PREFLIGHT VALIDATION ONLY`, perform validation only and return exactly one of `PREFLIGHT: ALL CLEAR` or `PREFLIGHT: REVISIONS REQUIRED`.

package/resources/codex-and-agents-customizations/.codex/agents/atomic-executor-c3.toml

@@ -93,6 +93,17 @@ Use the scoped tool patterns for quality gates:
 
 Run toolchain in order: format, lint, type-check, test. Restart from step 1 if any step fails or changes files.
 
+## Scratch Location
+
+Concurrent child runs in one session share one session scratchpad, so every scratch file a run writes lives in a directory unique to the child.
+
+- `SCRATCH` resolves to `<session scratchpad>/issue-<issue-num>/`, where `<issue-num>` is the plan's canonical issue number.
+- Every scratch file, helper script, staged copy, and coverage report a plan names lives under `SCRATCH`. Subdirectories such as `SCRATCH/stage/` are permitted.
+- Create `SCRATCH` before the first scratch write. Never write a scratch file to the scratchpad root or to a fixed shared name outside `SCRATCH`.
+- When a plan written before this rule defines `SCRATCH` as the bare session scratchpad, treat that definition as `<session scratchpad>/issue-<issue-num>/`. This is a mechanical micro-action, not replanning.
+- Plans and evidence artifacts record the literal token `SCRATCH`, never a host path.
+- If two runs for the same issue can execute at once, the run-unique form `issue-<issue-num>-<yyyy-MM-ddTHH-mm>` replaces `issue-<issue-num>`.
+
 ## Preflight Validation
 
 When receiving a plan with directive `DIRECTIVE: PREFLIGHT VALIDATION ONLY`, perform validation only and return exactly one of `PREFLIGHT: ALL CLEAR` or `PREFLIGHT: REVISIONS REQUIRED`.