@danmoisan/drm-copilot-mcp 1.1.18 → 1.1.19

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

@@ -73,17 +73,28 @@ Do not record a partial removal, and do not record the rejection itself in `muta
 
 1. Re-derive durable state as above and resolve the item key against `items[]`.
 
-2. Decide the removal by calling `decide_removal(item_key, items, disposition)` from
-   `scripts/dev_tools/parallel_mutation_protocol.py`. The engine raises the dedicated rejection
-   exception for every rejected row; surface its message and stop.
+2. Decide the removal through the bundled entry point:
+
+   ```shell
+   bash .claude/lib/bash/remove-parallel-item.sh decide --item <key> --state <state> --removal-disposition <detach|abandon>
+   ```
+
+   `--state` is the state re-derived in step 1; omit it when the key resolves to no `items[]`
+   entry. Pass the caller's disposition as `--removal-disposition`, and omit the option when none
+   was supplied. Exit 0 prints the decision object (`item_key`, `prior_state`, `new_state`,
+   `disposition`, `triggers_recompute`) as one JSON line on stdout. Exit 1 is a rejected row:
+   surface its single stderr line and stop. Exit 2 is a usage error in the invocation itself.
 
 3. **Unstarted removal (recompute).** Set the item's state to `withdrawn`, drop its vertex, and
-   recolor by calling `recolor_unstarted(unstarted_items, conflict_edges, pinned,
-   current_generation, current_cohort=current_cohort,
-   highest_pinned_cohort=highest_pinned_cohort)`. Write
-   `RecolorResult.cohort_assignments` into `cohorts[]` and set the top-level `recolor_generation`
-   to `RecolorResult.generation`; the generation increments by exactly one. The result names no
-   pinned key, so no in-flight item moves.
+   recolor through the bundled entry point:
+
+   ```shell
+   bash .claude/lib/bash/remove-parallel-item.sh recolor --unstarted "<k> ..." --edges "<a>:<b> ..." --pinned "<k> ..." --generation <g> --current-cohort <c> --highest-pinned-cohort <h>
+   ```
+
+   Write the output field `cohort_assignments` into `cohorts[]` and set the top-level
+   `recolor_generation` to the output field `generation`; the generation increments by exactly
+   one. The result names no pinned key, so no in-flight item moves.
 
    `current_cohort` is F3's top-level field, read from the re-verified durable state: the lowest
    current-generation cohort index still holding a non-terminal item. Under the per-edge barrier an
@@ -117,8 +128,18 @@ Do not record a partial removal, and do not record the rejection itself in `muta
    invocation above, so an ad hoc command is not matchable and would bypass the confirmation
    contract entirely. One invocation, one item, both side effects.
 
-6. **Append exactly one `mutations[]` entry** for a successful removal, built by
-   `build_remove_entry` from `scripts/dev_tools/parallel_mutation_protocol.py`:
+6. **Append exactly one `mutations[]` entry** for a successful removal, built through the
+   bundled entry point:
+
+   ```shell
+   bash .claude/lib/bash/remove-parallel-item.sh entry --item <key> --prior-state <state> --removal-disposition <detach|abandon> --recompute <true|false> --generation <g> --at <timestamp>
+   ```
+
+   `--recompute` equals the decision's `triggers_recompute`. `--generation` is the generation
+   before the removal. Omit `--removal-disposition` for an unstarted item. `--at` is the mutation
+   timestamp in `yyyy-MM-ddTHH-mm` form; when it is omitted the entry point uses the current UTC
+   minute. Exit 0 prints the entry as one JSON line on stdout; exit 1 is a contract rejection whose
+   single stderr line is surfaced before stopping; exit 2 is a usage error.
 
    | Case | `op` | `item_key` | `prior_state` | `new_state` | `disposition` | `recolor_generation` |
    | --- | --- | --- | --- | --- | --- | --- |
@@ -127,7 +148,9 @@ Do not record a partial removal, and do not record the rejection itself in `muta
    | Remove, `abandon` | `remove` | item key | `in_flight` | `withdrawn` | `abandon` | `g` (unchanged) |
 
    `disposition` is non-null only on an in-flight removal and is null on the unstarted row. The `at`
-   timestamp comes from the engine's injected clock seam.
+   timestamp comes from the `--at` value, or from the current UTC minute when `--at` is omitted.
+   The repository-local module `scripts/dev_tools/parallel_mutation_protocol.py` is retained as the
+   parity reference for this entry point and is not invoked on this path.
 
 7. **Validate the checkpoint** before treating the removal as applied. Run the
    `validate_orchestration_artifacts` MCP tool with `artifact_type:

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

@@ -49,7 +49,7 @@ PreToolUse hook can verify the body passed to `gh pr create --body-file` is the
 produced:
 
 1. Write the body text to `artifacts/pr_body_<N>.md`, where `<N>` is the target issue or PR number.
-2. Compute the SHA-256 of the body file bytes and render it as lowercase hexadecimal.
+2. Compute the SHA-256 of the body file by running `sha256sum artifacts/pr_body_<N>.md` as a single command (no chaining) and take the lowercase hexadecimal digest.
 3. Write the sibling receipt `artifacts/pr_body_<N>.receipt.json` with the shape:
 
    ```json
@@ -63,6 +63,8 @@ produced:
    }
    ```
 
+   Obtain it by running `date -u +%Y-%m-%dT%H:%M:%SZ` as a single command.
+
 4. Pass the body to the pull request via `--body-file artifacts/pr_body_<N>.md`; do not use inline
    `--body`.
 

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

@@ -6,7 +6,7 @@ description: 'Quota throttling and account-switching policy for multi-agent orch
 # 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
+losing work. Derived from about five days of continuous multi-agent orchestration (consumer-repository runs
 `bugs-2026-09-11` and `bugs-2026-09-17`).
 
 Every figure marked **MEASURED** was observed; figures marked **ESTIMATE** are extrapolations.

package/resources/claude-customizations/.claude/skills/remediation-handoff-atomic-planner/SKILL.md

@@ -14,7 +14,7 @@ Use this skill when:
 - Audit findings require remediation (FAIL or material PARTIAL findings).
 - Toolchain checks fail.
 - Acceptance criteria are unmet.
-- A required CI check fails after the pull request is open.
+- A CI check fails after the pull request is open.
 - Any new finding surfaces during execution of an active cycle (in which case begin a new cycle, do not extend the active one).
 
 ## Full Handoff Chain
@@ -52,7 +52,7 @@ Trigger remediation when any of these are true:
 - Audit artifacts contain FAIL or meaningful PARTIAL findings.
 - Toolchain checks fail (format, lint, type-check, test, contract, or integration stages).
 - Acceptance criteria are not met.
-- A required CI check fails after the PR is open (workflow-file changes specifically must enter the loop and trigger the `modified-workflow-needs-green-run` rule defined in `.claude/skills/feature-review-workflow/SKILL.md`).
+- A CI check fails after the PR is open (workflow-file changes specifically must enter the loop and trigger the `modified-workflow-needs-green-run` rule defined in `.claude/skills/feature-review-workflow/SKILL.md`).
 
 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`; `autonomous` when no class is stated). When no blocking finding is `autonomous`, the review verdict is `HALT_NON_REMEDIABLE` or `AWAITING_CI`: the orchestrator halts or waits, and no cycle, remediation plan, or `atomic-planner` handoff is created.
 

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

@@ -40,25 +40,42 @@
     ".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-orchestration-preimplementation-gate-targets.ps1",
     ".claude/hooks/enforce-parallel-abandon-gate.ps1",
     ".claude/hooks/enforce-parallel-cohort-barrier.ps1",
     ".claude/hooks/enforce-parallel-cohort-barrier-helpers.ps1",
     ".claude/hooks/enforce-parallel-drift-gate.ps1",
     ".claude/hooks/enforce-parallel-drift-gate-helpers.ps1",
     ".claude/hooks/enforce-parallel-worktree-removal-gate.ps1",
+    ".claude/hooks/enforce-pr-author-command-allowlist.ps1",
+    ".claude/hooks/enforce-pr-author-skill.artifact-root.ps1",
+    ".claude/hooks/enforce-pr-author-skill.docs-only.ps1",
     ".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/feature-folder-resolution.ps1",
+    ".claude/hooks/feature-review-coverage-thresholds.ps1",
+    ".claude/hooks/hook-command-heredoc.ps1",
     ".claude/hooks/hook-command-invocation.ps1",
+    ".claude/hooks/hook-command-invocation-operands.ps1",
+    ".claude/hooks/hook-command-payload.ps1",
+    ".claude/hooks/hook-command-payload-powershell.ps1",
     ".claude/hooks/hook-command-scanner.ps1",
+    ".claude/hooks/hook-dependency-guard.ps1",
+    ".claude/hooks/hook-docs-only-diff.ps1",
     ".claude/hooks/persist-session-id.ps1",
+    ".claude/hooks/subagentstop-envelope.ps1",
     ".claude/hooks/validate-bash.ps1",
     ".claude/hooks/validate-discovery-artifact-gate.ps1",
     ".claude/hooks/validate-executor-output.ps1",
+    ".claude/hooks/validate-feature-review-coverage-metrics.ps1",
+    ".claude/hooks/validate-feature-review-coverage-rules.ps1",
     ".claude/hooks/validate-feature-review-coverage.ps1",
+    ".claude/hooks/validate-orchestrator-output-resolution.ps1",
+    ".claude/hooks/validate-orchestrator-output-routing.ps1",
     ".claude/hooks/validate-orchestrator-output.ps1",
     ".claude/hooks/validate-planner-output.ps1",
     ".claude/hooks/validate-prd-feature-output.ps1",
@@ -145,6 +162,7 @@
     ".claude/lib/orchestrator-state/OrchestratorStateRoutingContract.psm1",
     ".claude/lib/orchestrator-state/OrchestratorStateIssueAdoption.psm1",
     ".claude/lib/orchestrator-state/OrchestratorStateUnconditional.psm1",
+    ".claude/lib/orchestrator-state/OrchestratorStateEpicWaveBarrier.psm1",
     ".claude/lib/discovery-validation/DiscoveryValidation.psm1",
     ".claude/lib/codex-routing/CodexDeployment.psm1",
     ".claude/lib/codex-routing/CodexTopology.psm1",
@@ -171,13 +189,18 @@
     ".claude/lib/bash/abandon-parallel-item.sh",
     ".claude/lib/bash/compute-cohorts.sh",
     ".claude/lib/bash/compute-concurrency-batches.sh",
+    ".claude/lib/bash/mutate-parallel-run.sh",
     ".claude/lib/bash/parallel-cohorts.sh",
     ".claude/lib/bash/parallel-common.sh",
     ".claude/lib/bash/parallel-items-validate.sh",
     ".claude/lib/bash/parallel-lane-assertion.sh",
     ".claude/lib/bash/parallel-manifest-validate.sh",
+    ".claude/lib/bash/parallel-mutation-cli.sh",
+    ".claude/lib/bash/parallel-mutation-ops.sh",
+    ".claude/lib/bash/parallel-mutation.sh",
     ".claude/lib/bash/parallel-yaml-emit.sh",
     ".claude/lib/bash/parallel-yaml-scan.sh",
+    ".claude/lib/bash/remove-parallel-item.sh",
     ".claude/lib/bash/report-lane-assertion.sh",
     ".claude/lib/bash/validate-parallel-manifest.sh",
     "config/orchestration-routing.json",

package/resources/codex-and-agents-customizations/.agents/skills/acceptance-criteria-tracking/SKILL.md

@@ -86,7 +86,7 @@ During feature review (feature-audit phase):
 
 ### When Orchestrators Enforce AC Tracking
 
-Orchestrators do not directly check off AC items. Instead:
+Orchestrators do not directly check off AC items. The one exception is a CI-dependent criterion, which the item's own orchestrator run checks off at S9 as described in `### CI-Dependent Criteria` above. For every other criterion, orchestrators instead:
 
 1. Ensure delegated executors and reviewers reference this skill.
 2. After executor or reviewer completion, verify that AC source files reflect delivered work (spot-check; do not re-execute verification).

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

@@ -1,6 +1,6 @@
 ---
 name: architecture-boundaries
-description: Architecture boundary enforcement rules for the No-COM architecture.
+description: Architecture boundary enforcement rules for a host-neutral layered architecture.
 ---
 
 # Converted rule
@@ -16,7 +16,7 @@ Architecture boundary enforcement is a uniform gate across all tiers (T1–T4).
 - **TypeScript:** `dependency-cruiser`. Configuration file pattern: `.dependency-cruiser.cjs`.
 - **.NET (when the backend exists):** `NetArchTest.Rules`. Test project naming pattern: `*.ArchitectureTests`.
 
-## No-COM Architecture Rules (enforceable assertions)
+## Host-Neutral Architecture Rules (enforceable assertions)
 
 Production code in this repository must satisfy each of the following assertions. Each assertion is enforced by `dependency-cruiser` (TypeScript) or `NetArchTest.Rules` (.NET) where applicable; legacy import utilities, when added, must satisfy the same assertions.
 
@@ -39,9 +39,9 @@ Production code in this repository must satisfy each of the following assertions
 
 ## Layer Boundary Assertions (.NET, applies once the backend exists)
 
-- `TaskMaster.Domain` must have zero references to Outlook PIA, VSTO, or Office.js types.
-- `TaskMaster.Application` may depend on `TaskMaster.Domain` only.
-- Adapter projects may depend on `TaskMaster.Domain` and `TaskMaster.Application`; domain may not depend on adapters.
+- `<Product>.Domain` must have zero references to Outlook PIA, VSTO, or Office.js types.
+- `<Product>.Application` may depend on `<Product>.Domain` only.
+- Adapter projects may depend on `<Product>.Domain` and `<Product>.Application`; domain may not depend on adapters.
 
 ## Enforcement Outcome
 

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

@@ -55,6 +55,17 @@ For each task:
 4. Check off the plan file on disk immediately after verification passes.
 5. Check off satisfied acceptance criteria in the authoritative requirement source file per `acceptance-criteria-tracking`.
 
+## 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>`.
+
 ## Non-Negotiable Constraints
 
 - Do not invent new phases or tasks.

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

@@ -117,6 +117,10 @@ For short-path/minimal-audit plans, Phase 0 evidence is incomplete unless both a
 
 `Output Summary:` is mandatory for each command-step artifact and must concisely summarize the essential result signal (for example: pass/fail status, key counts, coverage headline, or primary diagnostic).
 
+## Evidence Filename Timestamps in Plans
+
+Plans name evidence artifacts `<name>.<timestamp>.md` and never fix a plan-time stamp in an evidence filename. An acceptance condition identifies a consumed evidence artifact by the derivation in `evidence-and-timestamp-conventions` (`### Evidence Filename Timestamp`): the lexicographically greatest file matching `<name>.*.md`, not a pre-stamped literal path. This section governs artifact paths only: asserted search tokens remain concrete.
+
 ## Coverage Evidence Contract (Mandatory when policy requires coverage)
 
 For any language in scope where repository policy requires coverage validation:

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

@@ -34,6 +34,16 @@ Each task must be:
 - independently verifiable,
 - free of placeholder text.
 
+## Scratch Location
+
+Concurrent child runs in one session share one session scratchpad, so every plan places its scratch files 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 plan that uses scratch files defines `SCRATCH` this way.
+- Every scratch file, helper script, staged copy, and coverage report a plan names lives under `SCRATCH`. Subdirectories such as `SCRATCH/stage/` are permitted.
+- A plan never directs a scratch file to the scratchpad root or to a fixed shared name outside `SCRATCH`.
+- 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>`.
+
 ## Mandatory Preflight Loop
 
 Before a plan is finalized:

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

@@ -10,8 +10,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`. Command: `dotnet tool run csharpier .` or `csharpier .`
-2. **Linting — .NET Analyzers**: C# code must pass Roslyn/.NET analyzer diagnostics. Command: `msbuild TaskMaster.sln /t:Build /p:Configuration=Debug /p:Platform="Any CPU" /p:EnableNETAnalyzers=true /p:EnforceCodeStyleInBuild=true`
-3. **Type Checking — Nullable Analysis**: Enable nullable reference types and fail on warnings. Command: `msbuild TaskMaster.sln /t:Build /p:Configuration=Debug /p:Platform="Any CPU" /p:Nullable=enable /p:TreatWarningsAsErrors=true`
+2. **Linting — .NET Analyzers**: C# code must pass Roslyn/.NET analyzer diagnostics. Command: `msbuild <solution>.sln /t:Build /p:Configuration=Debug /p:Platform="Any CPU" /p:EnableNETAnalyzers=true /p:EnforceCodeStyleInBuild=true`
+3. **Type Checking — Nullable Analysis**: Enable nullable reference types and fail on warnings. Command: `msbuild <solution>.sln /t:Build /p:Configuration=Debug /p:Platform="Any CPU" /p:Nullable=enable /p:TreatWarningsAsErrors=true`
 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/skills/csharp-qa-gate/SKILL.md

@@ -28,8 +28,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 run csharpier .`
-2. `msbuild TaskMaster.sln /t:Build /p:Configuration=Debug /p:Platform="Any CPU" /p:EnableNETAnalyzers=true /p:EnforceCodeStyleInBuild=true`
-3. `msbuild TaskMaster.sln /t:Build /p:Configuration=Debug /p:Platform="Any CPU" /p:Nullable=enable /p:TreatWarningsAsErrors=true`
+2. `msbuild <solution>.sln /t:Build /p:Configuration=Debug /p:Platform="Any CPU" /p:EnableNETAnalyzers=true /p:EnforceCodeStyleInBuild=true`
+3. `msbuild <solution>.sln /t:Build /p:Configuration=Debug /p:Platform="Any CPU" /p:Nullable=enable /p:TreatWarningsAsErrors=true`
 4. `vstest.console.exe <test-assembly-paths> /EnableCodeCoverage`
 
 If the environment prevents running any tool, stop and report the change as **unverified**. Do not declare completion.

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

@@ -68,6 +68,14 @@ Create a missing integration branch from current `origin/main` and push it. Befo
 fetch the current remote integration tip. Create every child worktree from that tip, never from
 `main`, and set each feature PR base explicitly to the integration branch.
 
+Before each wave launches, run `git fetch origin main` and then
+`git rev-list --count <integration>..origin/main`. A zero count proceeds directly to the wave.
+A non-zero count runs the main-sync as a dedicated chore child item (the `epic-852-main-sync` /
+PR #882 pattern) whose branch starts from the integration tip, merges `origin/main` with a merge
+commit, and opens a PR into the integration branch; that PR must merge before the wave launches.
+Record the sync child's `features[]` row before its launch, and do not reuse a manifest child's
+issue number for it. Run at most one main-sync child per wave, then re-fetch the integration tip.
+
 Launch all ready children in one bounded parallel wave. Before each launch, persist the
 epic-child topology receipt, reviewed complexity assessment, delegation receipt, and Codex
 model-routing receipt with the same `delegation_id`, then select the generated deployment agent.

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

@@ -63,6 +63,21 @@ must never use placeholders.
 Create or reuse `epic/<epic-slug>-integration` from `origin/main`, push it, and commit the epic
 home before preparation. All prepared child outputs must fan into this branch.
 
+## Integration Commit Form
+
+The epic planner's own commits of the epic manifest, the fanned-in child feature folders and approved plans, and the kickoff copy are orchestration bookkeeping. `.codex/hooks/enforce-orchestration-preimplementation-gate.ps1` exempts them without a ready feature checkpoint only when the invocation is pathspec-bearing and every path operand lies inside `docs/features/epics/`, `docs/features/parallel/`, `docs/features/active/`, `docs/features/potential/`, or `artifacts/orchestration/`. A pathless commit, a whole-tree operand, or any operand outside those trees is denied.
+
+Admitted commit forms, each followed by `--` and the exempt path operands:
+
+- A single-quoted message containing `$`, for example `git commit -m 'docs: costs $5' -- <exempt paths>`.
+- A single-quoted message containing a backtick, for example ``git commit -m 'docs: fix `Foo`' -- <exempt paths>``.
+- The trailer option on `git commit` only, in the separate-value form `--trailer 'Co-Authored-By: Name <email>'` or the `--trailer=<value>` form, any number of times.
+- The one-paragraph multi-message form: the subject in the first `-m` and every trailer in one single-quoted second `-m` value, separated by a literal newline. Each `-m` value becomes its own paragraph and git parses only the last paragraph as the trailer block, so trailers split across separate `-m` values do not form one trailer block.
+
+Quoting rules: `$` and backtick are admitted only inside single quotes. `<`, `>`, and `#` are admitted only inside quotes. A typographic quote character (U+2018 to U+201E) is denied anywhere. Because the executing shell is undetermined (issue #735), a shape whose meaning differs between a POSIX shell and PowerShell is denied: a backslash anywhere in the command line is denied, and `{`, `}`, `,`, `(`, `)`, and `@` are denied outside quotes. Every staging operand must be a plain forward-slash repository-relative path that uses only the characters `A-Z a-z 0-9 . _ / -`.
+
+Not admitted: heredoc-fed messages, and message files supplied through `-F <file>` or `--file=<file>` (issue #732, decision D5).
+
 ## Concurrent Preparation
 
 Place all child preparations in one preparation batch, regardless of execution-wave
@@ -181,7 +196,8 @@ byte-identical; the manifest, durable kickoff, plans, and planning commits must
 repository-aware readiness validator without worktree drift.
 
 Invoke `validate_orchestration_artifacts` for `epic-planner-state` with
-`require_ready_for_execution: true` and the explicit workspace root. Do not write or delegate the
+`require_ready_for_execution: true`, `require_codex_topology: true`,
+`require_codex_model_routing: true`, and the explicit workspace root. Do not write or delegate the
 kickoff until this canonical gate succeeds.
 
 ## Kickoff Artifacts

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

@@ -22,7 +22,8 @@ Use the epic slug or path supplied in the invoking user request.
    per-feature plan paths, preflight evidence, and current Git state. Derive optional missing
    hashes from Git; fail closed on actual drift.
    Invoke `validate_orchestration_artifacts` for `epic-planner-state` with
-   `require_ready_for_execution: true` and the explicit workspace root. Do not delegate until
+   `require_ready_for_execution: true`, `require_codex_topology: true`,
+   `require_codex_model_routing: true`, and the explicit workspace root. Do not delegate until
    that canonical repository-aware gate succeeds.
 4. Delegate the invocation prompt to `epic-orchestrator` and apply `epic-orchestrate`.
 5. Reuse the existing integration branch. Every child resumes at atomic execution from its

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

@@ -48,7 +48,16 @@ Use this skill when:
 Use `yyyy-MM-ddTHH-mm` for all audit, remediation, and evidence artifacts.
 Example: `2026-02-06T14-30`.
 
-The `Timestamp` value is local time read from the host system clock when the recorded command runs (for example `Get-Date -Format yyyy-MM-ddTHH-mm`); the agent never composes or estimates it.
+The `Timestamp` value is UTC read from the host system clock when the recorded command runs (for example `Get-Date -AsUTC -Format yyyy-MM-ddTHH-mm` in PowerShell 7, `(Get-Date).ToUniversalTime().ToString('yyyy-MM-ddTHH-mm')` in Windows PowerShell 5.1, or `date -u +%Y-%m-%dT%H-%M` in a POSIX shell); the agent never composes or estimates it. The value is written without a zone suffix.
+
+### Evidence Filename Timestamp
+
+The stamp in the filename of every artifact under `<FEATURE>/evidence/<kind>/` is the UTC time at which that file is written, read from the host system clock immediately before the write, in the same `yyyy-MM-ddTHH-mm` shape with no zone suffix. It is never a plan-time stamp, a plan-cycle identifier, or any other value fixed before the write.
+
+- Plans name such an artifact `<name>.<timestamp>.md`, and the executor substitutes the write time. A later loop pass writes a new file with a new stamp.
+- A task that consumes an evidence artifact selects the lexicographically greatest file matching `<name>.*.md`. The fixed-width UTC shape sorts in chronological order, so that file is the most recently written one.
+- Plan files (`plan.<timestamp>.md`, stamped by the feature-folder tooling in America/New_York) and the review artifact set (`policy-audit`, `code-review`, `feature-audit`, `remediation-inputs`, which share one stamp) are outside this rule.
+- Existing evidence files whose names carry a plan-time stamp are not renamed.
 
 ## Canonical Evidence Locations
 

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

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

@@ -422,7 +422,7 @@ After each `feature-reviewer` delegation returns:
    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 required check stays `autonomous` and enters the remediation loop.
+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)
 
@@ -453,11 +453,20 @@ 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.
 
-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 required 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.
+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`.
 
@@ -473,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-workflow/SKILL.md

@@ -436,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 definitions and gate matrix in this document are the tier system's source of truth; 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/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