devrites 3.0.7 → 3.1.0

package/pack/generated/codex/skills/rite-pov/SKILL.md

@@ -11,9 +11,13 @@ This is the Codex mirror of a DevRites skill. In Codex:
 
 - Load DevRites engineering standards from `.agents/skills/devrites-lib/reference/standards/`. Read `.agents/skills/devrites-lib/reference/standards/core.md` before workflow work, then load the other `.agents/skills/devrites-lib/reference/standards/*.md` files exactly when this skill asks for them.
 - Use the installed `devrites-engine` binary as the canonical runtime helper surface for orientation, gates, and state mutation.
-- When this skill asks for a DevRites specialist or writer agent, **explicitly** spawn the matching Codex custom agent from `.codex/agents/devrites-*.toml` through Codex subagents (`spawn_agent`), then wait for its result and reconcile it as the skill instructs. Do not do the review inline just because the instruction to spawn is embedded here: Codex under-fires embedded spawn/skill instructions (openai/codex #23496), so treat the spawn as required, not optional.
-- The independence of a fresh-context subagent is the point. If Codex genuinely cannot spawn subagents in the current surface, run the documented inline fallback and **label the result an inline fallback, not an independent review**: an inline pass shares the calling context and is weaker evidence.
-- Codex project hooks are installed in `.codex/hooks.json`. Review and trust them with `/hooks` before relying on hook enforcement.
+- **Invocation and dispatch are different:** invoke means run a skill in this context; dispatch means start a fresh agent with `spawn_agent`, await it, and reconcile its result. Never describe inline skill work as a dispatch.
+- For every DevRites specialist or writer dispatch, first call `spawn_agent` with the named `devrites-<role>` custom role. The matching project contract is `.codex/agents/devrites-<role>.toml`.
+- If `spawn_agent` is callable but a named read-only role is unavailable, use generic `explorer` only when the host proves that run has a runtime-enforced read-only sandbox. Tell it to read `.codex/agents/devrites-<role>.toml`, follow its `developer_instructions`, and execute the unchanged packet. A missing read-only custom role is not evidence that spawning is unavailable.
+- Never dispatch generic `worker` for `devrites-slice-wright` unless the host proves that worker run carries exact DevRites identity and the same `.wright-allowlist` enforcement as the named role. Codex reports a generic run as `agent_type=worker`, so the generated global hooks cannot prove that binding. Reject that unsafe rung and use the documented labelled inline wright path with `.reconcile-inline` plus the full reconcile gate.
+- If the host cannot prove the generic explorer is runtime read-only, reject that rung too. Only when no spawn primitive exists or a higher-priority policy rejects a safe spawn may the root run the documented discipline inline. Label it `independence: fallback`, never call it independent, and apply every fallback risk gate. An unbound generic wright or unconfined generic explorer is such a safety rejection, not evidence that no agents exist.
+- Wait for every required fresh-context dispatch before reconciling or advancing. A backgrounded or lost result is incomplete.
+- Codex project hooks are installed in `.codex/hooks.json`; declared-leaf hooks are scoped inside `.codex/agents/devrites-*.toml`. Review and trust them with `/hooks` before relying on hook enforcement.
 - When this skill asks a HITL question via `AskUserQuestion`: Codex's equivalent (`request_user_input`) exists only in Plan mode. Outside Plan mode, render the option set as a plain numbered list in chat and **end the turn** so the human answers: NEVER silently pick an option yourself; auto-picking is AFK's contract, gated by the `.devrites/AFK` sentinel.
 
 

package/pack/generated/codex/skills/rite-pr-feedback/SKILL.md

@@ -12,9 +12,13 @@ This is the Codex mirror of a DevRites skill. In Codex:
 
 - Load DevRites engineering standards from `.agents/skills/devrites-lib/reference/standards/`. Read `.agents/skills/devrites-lib/reference/standards/core.md` before workflow work, then load the other `.agents/skills/devrites-lib/reference/standards/*.md` files exactly when this skill asks for them.
 - Use the installed `devrites-engine` binary as the canonical runtime helper surface for orientation, gates, and state mutation.
-- When this skill asks for a DevRites specialist or writer agent, **explicitly** spawn the matching Codex custom agent from `.codex/agents/devrites-*.toml` through Codex subagents (`spawn_agent`), then wait for its result and reconcile it as the skill instructs. Do not do the review inline just because the instruction to spawn is embedded here: Codex under-fires embedded spawn/skill instructions (openai/codex #23496), so treat the spawn as required, not optional.
-- The independence of a fresh-context subagent is the point. If Codex genuinely cannot spawn subagents in the current surface, run the documented inline fallback and **label the result an inline fallback, not an independent review**: an inline pass shares the calling context and is weaker evidence.
-- Codex project hooks are installed in `.codex/hooks.json`. Review and trust them with `/hooks` before relying on hook enforcement.
+- **Invocation and dispatch are different:** invoke means run a skill in this context; dispatch means start a fresh agent with `spawn_agent`, await it, and reconcile its result. Never describe inline skill work as a dispatch.
+- For every DevRites specialist or writer dispatch, first call `spawn_agent` with the named `devrites-<role>` custom role. The matching project contract is `.codex/agents/devrites-<role>.toml`.
+- If `spawn_agent` is callable but a named read-only role is unavailable, use generic `explorer` only when the host proves that run has a runtime-enforced read-only sandbox. Tell it to read `.codex/agents/devrites-<role>.toml`, follow its `developer_instructions`, and execute the unchanged packet. A missing read-only custom role is not evidence that spawning is unavailable.
+- Never dispatch generic `worker` for `devrites-slice-wright` unless the host proves that worker run carries exact DevRites identity and the same `.wright-allowlist` enforcement as the named role. Codex reports a generic run as `agent_type=worker`, so the generated global hooks cannot prove that binding. Reject that unsafe rung and use the documented labelled inline wright path with `.reconcile-inline` plus the full reconcile gate.
+- If the host cannot prove the generic explorer is runtime read-only, reject that rung too. Only when no spawn primitive exists or a higher-priority policy rejects a safe spawn may the root run the documented discipline inline. Label it `independence: fallback`, never call it independent, and apply every fallback risk gate. An unbound generic wright or unconfined generic explorer is such a safety rejection, not evidence that no agents exist.
+- Wait for every required fresh-context dispatch before reconciling or advancing. A backgrounded or lost result is incomplete.
+- Codex project hooks are installed in `.codex/hooks.json`; declared-leaf hooks are scoped inside `.codex/agents/devrites-*.toml`. Review and trust them with `/hooks` before relying on hook enforcement.
 - When this skill asks a HITL question via `AskUserQuestion`: Codex's equivalent (`request_user_input`) exists only in Plan mode. Outside Plan mode, render the option set as a plain numbered list in chat and **end the turn** so the human answers: NEVER silently pick an option yourself; auto-picking is AFK's contract, gated by the `.devrites/AFK` sentinel.
 
 

package/pack/generated/codex/skills/rite-pressure-test/SKILL.md

@@ -11,9 +11,13 @@ This is the Codex mirror of a DevRites skill. In Codex:
 
 - Load DevRites engineering standards from `.agents/skills/devrites-lib/reference/standards/`. Read `.agents/skills/devrites-lib/reference/standards/core.md` before workflow work, then load the other `.agents/skills/devrites-lib/reference/standards/*.md` files exactly when this skill asks for them.
 - Use the installed `devrites-engine` binary as the canonical runtime helper surface for orientation, gates, and state mutation.
-- When this skill asks for a DevRites specialist or writer agent, **explicitly** spawn the matching Codex custom agent from `.codex/agents/devrites-*.toml` through Codex subagents (`spawn_agent`), then wait for its result and reconcile it as the skill instructs. Do not do the review inline just because the instruction to spawn is embedded here: Codex under-fires embedded spawn/skill instructions (openai/codex #23496), so treat the spawn as required, not optional.
-- The independence of a fresh-context subagent is the point. If Codex genuinely cannot spawn subagents in the current surface, run the documented inline fallback and **label the result an inline fallback, not an independent review**: an inline pass shares the calling context and is weaker evidence.
-- Codex project hooks are installed in `.codex/hooks.json`. Review and trust them with `/hooks` before relying on hook enforcement.
+- **Invocation and dispatch are different:** invoke means run a skill in this context; dispatch means start a fresh agent with `spawn_agent`, await it, and reconcile its result. Never describe inline skill work as a dispatch.
+- For every DevRites specialist or writer dispatch, first call `spawn_agent` with the named `devrites-<role>` custom role. The matching project contract is `.codex/agents/devrites-<role>.toml`.
+- If `spawn_agent` is callable but a named read-only role is unavailable, use generic `explorer` only when the host proves that run has a runtime-enforced read-only sandbox. Tell it to read `.codex/agents/devrites-<role>.toml`, follow its `developer_instructions`, and execute the unchanged packet. A missing read-only custom role is not evidence that spawning is unavailable.
+- Never dispatch generic `worker` for `devrites-slice-wright` unless the host proves that worker run carries exact DevRites identity and the same `.wright-allowlist` enforcement as the named role. Codex reports a generic run as `agent_type=worker`, so the generated global hooks cannot prove that binding. Reject that unsafe rung and use the documented labelled inline wright path with `.reconcile-inline` plus the full reconcile gate.
+- If the host cannot prove the generic explorer is runtime read-only, reject that rung too. Only when no spawn primitive exists or a higher-priority policy rejects a safe spawn may the root run the documented discipline inline. Label it `independence: fallback`, never call it independent, and apply every fallback risk gate. An unbound generic wright or unconfined generic explorer is such a safety rejection, not evidence that no agents exist.
+- Wait for every required fresh-context dispatch before reconciling or advancing. A backgrounded or lost result is incomplete.
+- Codex project hooks are installed in `.codex/hooks.json`; declared-leaf hooks are scoped inside `.codex/agents/devrites-*.toml`. Review and trust them with `/hooks` before relying on hook enforcement.
 - When this skill asks a HITL question via `AskUserQuestion`: Codex's equivalent (`request_user_input`) exists only in Plan mode. Outside Plan mode, render the option set as a plain numbered list in chat and **end the turn** so the human answers: NEVER silently pick an option yourself; auto-picking is AFK's contract, gated by the `.devrites/AFK` sentinel.
 
 

package/pack/generated/codex/skills/rite-prototype/SKILL.md

@@ -12,16 +12,20 @@ This is the Codex mirror of a DevRites skill. In Codex:
 
 - Load DevRites engineering standards from `.agents/skills/devrites-lib/reference/standards/`. Read `.agents/skills/devrites-lib/reference/standards/core.md` before workflow work, then load the other `.agents/skills/devrites-lib/reference/standards/*.md` files exactly when this skill asks for them.
 - Use the installed `devrites-engine` binary as the canonical runtime helper surface for orientation, gates, and state mutation.
-- When this skill asks for a DevRites specialist or writer agent, **explicitly** spawn the matching Codex custom agent from `.codex/agents/devrites-*.toml` through Codex subagents (`spawn_agent`), then wait for its result and reconcile it as the skill instructs. Do not do the review inline just because the instruction to spawn is embedded here: Codex under-fires embedded spawn/skill instructions (openai/codex #23496), so treat the spawn as required, not optional.
-- The independence of a fresh-context subagent is the point. If Codex genuinely cannot spawn subagents in the current surface, run the documented inline fallback and **label the result an inline fallback, not an independent review**: an inline pass shares the calling context and is weaker evidence.
-- Codex project hooks are installed in `.codex/hooks.json`. Review and trust them with `/hooks` before relying on hook enforcement.
+- **Invocation and dispatch are different:** invoke means run a skill in this context; dispatch means start a fresh agent with `spawn_agent`, await it, and reconcile its result. Never describe inline skill work as a dispatch.
+- For every DevRites specialist or writer dispatch, first call `spawn_agent` with the named `devrites-<role>` custom role. The matching project contract is `.codex/agents/devrites-<role>.toml`.
+- If `spawn_agent` is callable but a named read-only role is unavailable, use generic `explorer` only when the host proves that run has a runtime-enforced read-only sandbox. Tell it to read `.codex/agents/devrites-<role>.toml`, follow its `developer_instructions`, and execute the unchanged packet. A missing read-only custom role is not evidence that spawning is unavailable.
+- Never dispatch generic `worker` for `devrites-slice-wright` unless the host proves that worker run carries exact DevRites identity and the same `.wright-allowlist` enforcement as the named role. Codex reports a generic run as `agent_type=worker`, so the generated global hooks cannot prove that binding. Reject that unsafe rung and use the documented labelled inline wright path with `.reconcile-inline` plus the full reconcile gate.
+- If the host cannot prove the generic explorer is runtime read-only, reject that rung too. Only when no spawn primitive exists or a higher-priority policy rejects a safe spawn may the root run the documented discipline inline. Label it `independence: fallback`, never call it independent, and apply every fallback risk gate. An unbound generic wright or unconfined generic explorer is such a safety rejection, not evidence that no agents exist.
+- Wait for every required fresh-context dispatch before reconciling or advancing. A backgrounded or lost result is incomplete.
+- Codex project hooks are installed in `.codex/hooks.json`; declared-leaf hooks are scoped inside `.codex/agents/devrites-*.toml`. Review and trust them with `/hooks` before relying on hook enforcement.
 - When this skill asks a HITL question via `AskUserQuestion`: Codex's equivalent (`request_user_input`) exists only in Plan mode. Outside Plan mode, render the option set as a plain numbered list in chat and **end the turn** so the human answers: NEVER silently pick an option yourself; auto-picking is AFK's contract, gated by the `.devrites/AFK` sentinel.
 
 
-# $rite-prototype: throwaway code that answers ONE question
+# $rite-prototype: answer one question with throwaway code
 
-A prototype is **throwaway code that answers exactly one question**. The question
-chooses the shape: get the shape wrong and the whole prototype wastes the user's time.
+A prototype is throwaway code for exactly one question. Choose its shape from that
+question.
 
 ## 0. Read core rules
 
@@ -37,11 +41,12 @@ down. Examples that count as "the question":
 - "Which of these three settings layouts feels right?"
 - "Will the proposed state machine deadlock when X overlaps Y?"
 
-A vague question ("explore this feature") is not enough: push back once to sharpen it.
+A vague request such as "explore this feature" is not enough. Ask once for a specific
+question.
 
 ## 2. Pick the branch
 
-Read the user's prompt + the surrounding code. Two branches:
+Read the user's prompt and surrounding code, then choose one branch:
 
 | Question shape | Branch | Artifact |
 |---|---|---|
@@ -51,50 +56,48 @@ Read the user's prompt + the surrounding code. Two branches:
 If genuinely ambiguous and the user is AFK: pick by the surrounding code (backend module
 → Logic; page / component → UI) and state the assumption in a comment at the top.
 
-**Variations must differ in shape.** UI prototypes where the variations are just colour
-or padding tweaks teach nothing: push each variation to a different *information
-architecture* / *interaction model* so the user can pick a direction, not a polish.
+**Variations must differ in structure.** Colour or padding changes alone do not answer
+a design question. Give each variation a different information architecture or
+interaction model.
 
 ## 3. Rules that apply to both branches
 
-1. **Throwaway from day one, and visibly so.** Place the prototype next to where it
-   will eventually be used (so context is obvious) but name it so a casual reader sees
-   it's a prototype: `prototype/`, `__prototype__`, `.scratch/`, etc. Obey the project's
+1. **Mark it as throwaway.** Place the prototype near its eventual use, but use a name
+   that clearly identifies it: `prototype/`, `__prototype__`, `.scratch/`, etc. Obey the project's
    existing routing / module convention; don't invent a new top-level structure.
-2. **One command to run.** Use whatever task runner the project already has: `pnpm
-   <name>`, `python <path>`, `bun <path>`. The user must start it without thinking.
+2. **Provide one run command.** Use the project's existing task runner: `pnpm
+   <name>`, `python <path>`, or `bun <path>`.
 3. **No persistence by default.** State lives in memory. Persistence is usually the
    thing the prototype is *checking*, not a dependency. If the question explicitly
    involves a DB, hit a scratch DB or a local file with a name like
    `PROTOTYPE — wipe me`.
-4. **Skip the polish.** No tests. No error handling beyond what makes it run. No
-   abstractions. The point is learn fast, delete fast.
+4. **Skip polish.** Add no tests, abstractions, or error handling beyond what is needed
+   to run and answer the question.
 5. **Surface state.** After every action (Logic) or on every variant switch (UI), print
    or render the full relevant state so the user can see what changed.
-6. **Delete or absorb when done.** When the question has an answer, either delete the
-   prototype or fold the validated decision into the real code: don't leave it
-   rotting in the repo.
+6. **Delete or absorb when done.** After answering the question, delete the prototype
+   or fold the validated decision into production code.
 
 ## 4. Capture the answer
 
-The *answer* is the only durable output. Before declaring the prototype done, write
+The answer is the only durable output. Before declaring the prototype done, write
 one of:
 
 - An entry in the active feature's `decisions.md` (`.devrites/work/<slug>/decisions.md`)
   with the question and the answer.
 - A `NOTES.md` next to the prototype if no active feature exists.
 
-If the user is around, this is a quick conversation. If they're AFK, the prototype is
-complete only once the verdict is filled in: a blank `VERDICT: ___` is not an
-answer. Leave it marked **not yet complete** and queue the open question so a later pass
-fills the verdict before the prototype is deleted.
+If the user is present, ask for the verdict directly. In AFK, the prototype remains
+incomplete until the verdict is filled in. A blank `VERDICT: ___` is not an answer.
+Mark it **not yet complete**. Queue the question and do not delete the prototype until
+a later pass records the verdict.
 
 ## Where this slots in
 
-`$rite-prototype` is a **scoped detour**, not a phase of its own. Typical placements:
+`$rite-prototype` is a scoped detour, not a separate phase. Typical uses:
 
-- **Between `$rite-spec` and `$rite-define`:** a design question is undecidable on
-  paper; prototype it, capture the answer, return to `$rite-define`.
+- **During `$rite-clarify` (between spec and define):** a product/constraint question is
+  undecidable on paper; prototype it, capture the answer, return to `$rite-clarify`.
 - **Mid-build:** `$rite-build` hit a state-model ambiguity that the spec doesn't
   resolve. Drop into a Logic prototype, capture the answer, return.
 

package/pack/generated/codex/skills/rite-prove/SKILL.md

@@ -11,19 +11,23 @@ This is the Codex mirror of a DevRites skill. In Codex:
 
 - Load DevRites engineering standards from `.agents/skills/devrites-lib/reference/standards/`. Read `.agents/skills/devrites-lib/reference/standards/core.md` before workflow work, then load the other `.agents/skills/devrites-lib/reference/standards/*.md` files exactly when this skill asks for them.
 - Use the installed `devrites-engine` binary as the canonical runtime helper surface for orientation, gates, and state mutation.
-- When this skill asks for a DevRites specialist or writer agent, **explicitly** spawn the matching Codex custom agent from `.codex/agents/devrites-*.toml` through Codex subagents (`spawn_agent`), then wait for its result and reconcile it as the skill instructs. Do not do the review inline just because the instruction to spawn is embedded here: Codex under-fires embedded spawn/skill instructions (openai/codex #23496), so treat the spawn as required, not optional.
-- The independence of a fresh-context subagent is the point. If Codex genuinely cannot spawn subagents in the current surface, run the documented inline fallback and **label the result an inline fallback, not an independent review**: an inline pass shares the calling context and is weaker evidence.
-- Codex project hooks are installed in `.codex/hooks.json`. Review and trust them with `/hooks` before relying on hook enforcement.
+- **Invocation and dispatch are different:** invoke means run a skill in this context; dispatch means start a fresh agent with `spawn_agent`, await it, and reconcile its result. Never describe inline skill work as a dispatch.
+- For every DevRites specialist or writer dispatch, first call `spawn_agent` with the named `devrites-<role>` custom role. The matching project contract is `.codex/agents/devrites-<role>.toml`.
+- If `spawn_agent` is callable but a named read-only role is unavailable, use generic `explorer` only when the host proves that run has a runtime-enforced read-only sandbox. Tell it to read `.codex/agents/devrites-<role>.toml`, follow its `developer_instructions`, and execute the unchanged packet. A missing read-only custom role is not evidence that spawning is unavailable.
+- Never dispatch generic `worker` for `devrites-slice-wright` unless the host proves that worker run carries exact DevRites identity and the same `.wright-allowlist` enforcement as the named role. Codex reports a generic run as `agent_type=worker`, so the generated global hooks cannot prove that binding. Reject that unsafe rung and use the documented labelled inline wright path with `.reconcile-inline` plus the full reconcile gate.
+- If the host cannot prove the generic explorer is runtime read-only, reject that rung too. Only when no spawn primitive exists or a higher-priority policy rejects a safe spawn may the root run the documented discipline inline. Label it `independence: fallback`, never call it independent, and apply every fallback risk gate. An unbound generic wright or unconfined generic explorer is such a safety rejection, not evidence that no agents exist.
+- Wait for every required fresh-context dispatch before reconciling or advancing. A backgrounded or lost result is incomplete.
+- Codex project hooks are installed in `.codex/hooks.json`; declared-leaf hooks are scoped inside `.codex/agents/devrites-*.toml`. Review and trust them with `/hooks` before relying on hook enforcement.
 - When this skill asks a HITL question via `AskUserQuestion`: Codex's equivalent (`request_user_input`) exists only in Plan mode. Outside Plan mode, render the option set as a plain numbered list in chat and **end the turn** so the human answers: NEVER silently pick an option yourself; auto-picking is AFK's contract, gated by the `.devrites/AFK` sentinel.
 
 
 # $rite-prove: prove the completed feature
 
-Turn "I think it works" into recorded evidence for the **whole feature**. Read the active
-workspace first; if none, run `$rite-spec <feature>`.
+Record evidence for the **whole feature**. Read the active workspace first; if none,
+run `$rite-spec <feature>`.
 
-> **Differs from built-in `/verify` and `/run`:** those prove a single change /
-> launch the app. `$rite-prove` is feature-scoped. It walks `spec.md` acceptance
+> **Scope:** built-in `/verify` proves one change and `/run` launches the app.
+> `$rite-prove` covers a feature. It walks `spec.md` acceptance
 > criteria one-by-one, runs the full relevant test suite + build/typecheck/lint,
 > ascends the browser-proof ladder (step 4),
 > and writes `evidence.md` + `browser-evidence.md` keyed to the active
@@ -33,12 +37,13 @@ workspace first; if none, run `$rite-spec <feature>`.
 Read `tasks.md` + `state.md`. **If ANY slice is still pending/unbuilt, STOP** and tell the
 user to finish it with `$rite-build`: `$rite-prove` runs once, when the full task is
 complete, not after each slice. (Each slice already got its own targeted tests during
-`$rite-build`; this phase is the comprehensive proof of the assembled feature.)
+`$rite-build`; this phase proves the assembled feature as a whole.)
 
-**Never report a pass you didn't observe.** If a command couldn't run, say so and give exact manual steps.
+**Never report an unobserved pass.** If a command could not run, report that and give
+exact manual steps.
 
-**Re-runnable, scoped.** `$rite-prove` runs once when the full feature is assembled, but
-it can be **re-run scoped** afterwards: when `$rite-polish` or `$rite-review` edit code,
+**Scoped reruns are allowed.** `$rite-prove` runs once when the full feature is assembled.
+After `$rite-polish` or `$rite-review` edits code,
 the existing `evidence.md` no longer post-dates the change, so re-run `$rite-prove` over
 the affected criteria/routes to refresh proof before `$rite-seal`.
 
@@ -54,7 +59,7 @@ Pull these via `Read` when relevant:
   user flow): telemetry must be present **and observed to emit**, not assumed.
 - `developer-experience.md`: when the change ships a developer-facing surface (API / CLI / SDK /
   webhook / config / error messages / getting-started): **measure** the DX scorecard (run the flow,
-  time time-to-hello-world, capture the verbatim error text), don't assert it.
+  measure time-to-hello-world, and capture verbatim error text), rather than asserting it.
 - `definition-of-done.md`: standing Done bar: acceptance mapped, fresh proof, no open hard gates, scoped edits, rollback/docs where needed.
 
 
@@ -63,6 +68,10 @@ Pull these via `Read` when relevant:
   blocker; don't refactor unrelated code.
 - Spec Drift Guard applies: if tests/evidence reveal the spec is wrong, stop and handle
   drift (`rite-build/reference/spec-drift-guard.md`).
+- **Runner observes; root records; wright fixes.** Use the file-backed fresh-context
+  contract in [`agents.md`](../devrites-lib/reference/standards/agents.md). The root owns
+  the evidence verdict and canonical writes. Every accepted source/test correction is one
+  bounded `devrites-slice-wright` packet, never an inline edit.
 
 ## Workflow
 0. Read `.agents/skills/devrites-lib/reference/standards/core.md` first (the always-on operating rules); pull the
@@ -75,23 +84,28 @@ Pull these via `Read` when relevant:
    [test-command-discovery](reference/test-command-discovery.md): README, package
    scripts, Makefile, CI configs, Gemfile/Rakefile, pyproject, go.mod, Cargo.toml.
    **Completion:** exact runnable test/build/typecheck/lint commands are recorded or explicitly unavailable.
-3. **Run the full relevant test suite** for the feature (not a single slice), then the
-   relevant **build / typecheck / lint**.
-4. **UI feature?** Read `design-brief.md` + `references.md`, then run the browser proof ladder over the feature's routes:
+3. **Run proof in fresh context.** Freeze the candidate and dispatch
+   `devrites-proof-runner` with the exact commands, cwd, prerequisites, acceptance map,
+   and scratch boundary. Await and validate its observed full relevant test suite plus
+   **build / typecheck / lint** report. The runner writes no canonical evidence.
+4. **UI feature?** Include `design-brief.md`, `references.md`, routes, browser harness, and
+   allowed scratch path in the proof packet, then have the runner apply the browser proof ladder:
    [proof-ladder](reference/proof-ladder.md) + [browser-proof](reference/browser-proof.md)
    (`devrites-browser-proof`): routes, viewports, screenshots (opened + described),
    console, network, interaction paths, and the brief's proof targets. Compare screenshots
-   with target references, record deltas, fix/re-render, and do not pass with an unresolved
-   material mismatch.
+   with target references and record deltas. An unresolved material mismatch is a failed
+   result; the root handles any accepted correction at step 6 before re-rendering.
 5. **Map proof completely.** Follow
    [`reference/acceptance-proof.md`](reference/acceptance-proof.md) for acceptance/scenario
    coverage and the conditional critical-path, observability, developer-surface, and wiring
    branches. Completion: every criterion, planned interaction, and declared key link has a
    proof class plus passing evidence, or is recorded as a blocker.
 6. **On failure** → [failure-triage](reference/failure-triage.md) +
-   `devrites-debug-recovery`. Reproduce → isolate → fix within scope → re-run; if a fix
-   would exceed scope, record a blocker.
-7. Update `evidence.md`, `browser-evidence.md` (if UI), `traceability.md`, and
+   `devrites-debug-recovery`. The root reconciles the reproduction. Send an accepted,
+   in-scope correction to the sole writer, `devrites-slice-wright`; then freeze the new
+   candidate and dispatch a fresh proof runner for affected checks. If a fix would exceed
+   scope, record a blocker.
+7. The root updates `evidence.md`, `browser-evidence.md` (if UI), `traceability.md`, and
    `state.md`. New proof goes to `evidence.md` (`proof.md` is a read-only alias:
    see `devrites-lib/reference/workspace-artifact-schema.md`).
 

package/pack/generated/codex/skills/rite-quick/SKILL.md

@@ -11,9 +11,13 @@ This is the Codex mirror of a DevRites skill. In Codex:
 
 - Load DevRites engineering standards from `.agents/skills/devrites-lib/reference/standards/`. Read `.agents/skills/devrites-lib/reference/standards/core.md` before workflow work, then load the other `.agents/skills/devrites-lib/reference/standards/*.md` files exactly when this skill asks for them.
 - Use the installed `devrites-engine` binary as the canonical runtime helper surface for orientation, gates, and state mutation.
-- When this skill asks for a DevRites specialist or writer agent, **explicitly** spawn the matching Codex custom agent from `.codex/agents/devrites-*.toml` through Codex subagents (`spawn_agent`), then wait for its result and reconcile it as the skill instructs. Do not do the review inline just because the instruction to spawn is embedded here: Codex under-fires embedded spawn/skill instructions (openai/codex #23496), so treat the spawn as required, not optional.
-- The independence of a fresh-context subagent is the point. If Codex genuinely cannot spawn subagents in the current surface, run the documented inline fallback and **label the result an inline fallback, not an independent review**: an inline pass shares the calling context and is weaker evidence.
-- Codex project hooks are installed in `.codex/hooks.json`. Review and trust them with `/hooks` before relying on hook enforcement.
+- **Invocation and dispatch are different:** invoke means run a skill in this context; dispatch means start a fresh agent with `spawn_agent`, await it, and reconcile its result. Never describe inline skill work as a dispatch.
+- For every DevRites specialist or writer dispatch, first call `spawn_agent` with the named `devrites-<role>` custom role. The matching project contract is `.codex/agents/devrites-<role>.toml`.
+- If `spawn_agent` is callable but a named read-only role is unavailable, use generic `explorer` only when the host proves that run has a runtime-enforced read-only sandbox. Tell it to read `.codex/agents/devrites-<role>.toml`, follow its `developer_instructions`, and execute the unchanged packet. A missing read-only custom role is not evidence that spawning is unavailable.
+- Never dispatch generic `worker` for `devrites-slice-wright` unless the host proves that worker run carries exact DevRites identity and the same `.wright-allowlist` enforcement as the named role. Codex reports a generic run as `agent_type=worker`, so the generated global hooks cannot prove that binding. Reject that unsafe rung and use the documented labelled inline wright path with `.reconcile-inline` plus the full reconcile gate.
+- If the host cannot prove the generic explorer is runtime read-only, reject that rung too. Only when no spawn primitive exists or a higher-priority policy rejects a safe spawn may the root run the documented discipline inline. Label it `independence: fallback`, never call it independent, and apply every fallback risk gate. An unbound generic wright or unconfined generic explorer is such a safety rejection, not evidence that no agents exist.
+- Wait for every required fresh-context dispatch before reconciling or advancing. A backgrounded or lost result is incomplete.
+- Codex project hooks are installed in `.codex/hooks.json`; declared-leaf hooks are scoped inside `.codex/agents/devrites-*.toml`. Review and trust them with `/hooks` before relying on hook enforcement.
 - When this skill asks a HITL question via `AskUserQuestion`: Codex's equivalent (`request_user_input`) exists only in Plan mode. Outside Plan mode, render the option set as a plain numbered list in chat and **end the turn** so the human answers: NEVER silently pick an option yourself; auto-picking is AFK's contract, gated by the `.devrites/AFK` sentinel.
 
 

package/pack/generated/codex/skills/rite-resolve/SKILL.md

@@ -12,24 +12,28 @@ This is the Codex mirror of a DevRites skill. In Codex:
 
 - Load DevRites engineering standards from `.agents/skills/devrites-lib/reference/standards/`. Read `.agents/skills/devrites-lib/reference/standards/core.md` before workflow work, then load the other `.agents/skills/devrites-lib/reference/standards/*.md` files exactly when this skill asks for them.
 - Use the installed `devrites-engine` binary as the canonical runtime helper surface for orientation, gates, and state mutation.
-- When this skill asks for a DevRites specialist or writer agent, **explicitly** spawn the matching Codex custom agent from `.codex/agents/devrites-*.toml` through Codex subagents (`spawn_agent`), then wait for its result and reconcile it as the skill instructs. Do not do the review inline just because the instruction to spawn is embedded here: Codex under-fires embedded spawn/skill instructions (openai/codex #23496), so treat the spawn as required, not optional.
-- The independence of a fresh-context subagent is the point. If Codex genuinely cannot spawn subagents in the current surface, run the documented inline fallback and **label the result an inline fallback, not an independent review**: an inline pass shares the calling context and is weaker evidence.
-- Codex project hooks are installed in `.codex/hooks.json`. Review and trust them with `/hooks` before relying on hook enforcement.
+- **Invocation and dispatch are different:** invoke means run a skill in this context; dispatch means start a fresh agent with `spawn_agent`, await it, and reconcile its result. Never describe inline skill work as a dispatch.
+- For every DevRites specialist or writer dispatch, first call `spawn_agent` with the named `devrites-<role>` custom role. The matching project contract is `.codex/agents/devrites-<role>.toml`.
+- If `spawn_agent` is callable but a named read-only role is unavailable, use generic `explorer` only when the host proves that run has a runtime-enforced read-only sandbox. Tell it to read `.codex/agents/devrites-<role>.toml`, follow its `developer_instructions`, and execute the unchanged packet. A missing read-only custom role is not evidence that spawning is unavailable.
+- Never dispatch generic `worker` for `devrites-slice-wright` unless the host proves that worker run carries exact DevRites identity and the same `.wright-allowlist` enforcement as the named role. Codex reports a generic run as `agent_type=worker`, so the generated global hooks cannot prove that binding. Reject that unsafe rung and use the documented labelled inline wright path with `.reconcile-inline` plus the full reconcile gate.
+- If the host cannot prove the generic explorer is runtime read-only, reject that rung too. Only when no spawn primitive exists or a higher-priority policy rejects a safe spawn may the root run the documented discipline inline. Label it `independence: fallback`, never call it independent, and apply every fallback risk gate. An unbound generic wright or unconfined generic explorer is such a safety rejection, not evidence that no agents exist.
+- Wait for every required fresh-context dispatch before reconciling or advancing. A backgrounded or lost result is incomplete.
+- Codex project hooks are installed in `.codex/hooks.json`; declared-leaf hooks are scoped inside `.codex/agents/devrites-*.toml`. Review and trust them with `/hooks` before relying on hook enforcement.
 - When this skill asks a HITL question via `AskUserQuestion`: Codex's equivalent (`request_user_input`) exists only in Plan mode. Outside Plan mode, render the option set as a plain numbered list in chat and **end the turn** so the human answers: NEVER silently pick an option yourself; auto-picking is AFK's contract, gated by the `.devrites/AFK` sentinel.
 
 
 # $rite-resolve: answer the human gate
 
-`$rite-resolve` is the canonical resume verb for **async** human gates: a checkpoint that
-already paused and **stopped the session** (an AFK blocking/escalating/irreversible queue, or a
-HITL pause the human walked away from), plus `--batch`. When `$rite-build` asks a gap **inline**
+`$rite-resolve` resumes an **async** human gate: a checkpoint that already paused and
+**stopped the session** (an AFK blocking/escalating/irreversible queue, or a HITL pause
+left unanswered), plus `--batch`. When `$rite-build` asks a question **inline**
 via `AskUserQuestion` and the human is present, that pick resolves the gate **in place** through
 the same `devrites-engine resolve` writer. You don't type `$rite-resolve` for it. For the async case this
 skill takes the human's answer (or `--drop` / `--batch`), writes it to `questions.md`, updates
 `state.md` (clears `Awaiting human`, sets `Status: running`), and recommends the next command.
 
-It is **deliberately small**: one verb, one source of truth (`questions.md`), one cursor
-(`state.md`). The full AFK / HITL contract lives in
+It has one verb, one source of truth (`questions.md`), and one cursor (`state.md`). The
+full AFK / HITL contract lives in
 [`afk-hitl.md`](../devrites-lib/reference/standards/afk-hitl.md).
 
 ## Rules consulted (read on demand from `.agents/skills/devrites-lib/reference/standards/`)
@@ -57,9 +61,9 @@ Pull these via `Read` when shaping the resolve:
   unblocked slice's `Slice mode` (step 4, the named exception); everything else goes through
   the script, never by hand.
 - **Human gates are for human-only decisions, not the agent's work.** A `questions.md` entry the
-  human must answer is a genuine *decision* (a scope / design / risk call only the human can make).
-  Not a task the agent can do itself. If a question is really agent-doable ("should I write the
-  test?", "go implement X"), don't record a human answer that punts the agent's own job back to it:
+  human must answer is a genuine decision (a scope / design / risk call only the human can make),
+  not a task the agent can do. If a question is really agent-doable ("should I write the
+  test?", "go implement X"), do not record a human answer that returns the agent's work to it:
   flag the mis-tag and route it to the right skill (`$rite-build`, `$rite-plan unblock`,
   `devrites-debug-recovery`). The human resolves decisions; the agent does the work.
 
@@ -79,9 +83,10 @@ Pull these via `Read` when shaping the resolve:
    `tasks.md`. Confirm the qid is `status: open`. If `state.md` `Status` is not
    `awaiting_human` and the question's `gate` is `blocking`, surface the inconsistency
    before proceeding (don't auto-repair: flag it).
-3. **Render preview.** Echo the qid, the question, the proposed answer (if any), the
-   user's answer, and which slice unblocks. Stop here and ask `confirm? (y/N)` **unless**
-   the answer was provided non-interactively via `--batch`.
+3. **Apply explicit consent.** Supplying `<qid> "<answer>"`, `--drop`, or `--batch` is the
+   user's explicit consent for this local workspace mutation. Echo the qid, answer/drop,
+   and slice being unblocked, then continue immediately; do not ask the user to confirm the
+   command they just typed.
 4. **Mutate.** Run `devrites-engine resolve` with the same
    arguments. The script:
    - flips the qid's `status` to `answered` / `dropped` and stamps `answered_at` + `answer`;

package/pack/generated/codex/skills/rite-resolve/reference/answer-protocol.md

@@ -6,6 +6,9 @@ shapes, the batch file format, and the rules the underlying `devrites-engine res
 
 ## Three input shapes
 
+Each form is an explicit local mutation command. Supplying it is the confirmation; the
+skill applies it once after validation and reports the result instead of asking for `y` again.
+
 ### 1. Single answer
 
 ```

package/pack/generated/codex/skills/rite-review/SKILL.md

@@ -11,21 +11,25 @@ This is the Codex mirror of a DevRites skill. In Codex:
 
 - Load DevRites engineering standards from `.agents/skills/devrites-lib/reference/standards/`. Read `.agents/skills/devrites-lib/reference/standards/core.md` before workflow work, then load the other `.agents/skills/devrites-lib/reference/standards/*.md` files exactly when this skill asks for them.
 - Use the installed `devrites-engine` binary as the canonical runtime helper surface for orientation, gates, and state mutation.
-- When this skill asks for a DevRites specialist or writer agent, **explicitly** spawn the matching Codex custom agent from `.codex/agents/devrites-*.toml` through Codex subagents (`spawn_agent`), then wait for its result and reconcile it as the skill instructs. Do not do the review inline just because the instruction to spawn is embedded here: Codex under-fires embedded spawn/skill instructions (openai/codex #23496), so treat the spawn as required, not optional.
-- The independence of a fresh-context subagent is the point. If Codex genuinely cannot spawn subagents in the current surface, run the documented inline fallback and **label the result an inline fallback, not an independent review**: an inline pass shares the calling context and is weaker evidence.
-- Codex project hooks are installed in `.codex/hooks.json`. Review and trust them with `/hooks` before relying on hook enforcement.
+- **Invocation and dispatch are different:** invoke means run a skill in this context; dispatch means start a fresh agent with `spawn_agent`, await it, and reconcile its result. Never describe inline skill work as a dispatch.
+- For every DevRites specialist or writer dispatch, first call `spawn_agent` with the named `devrites-<role>` custom role. The matching project contract is `.codex/agents/devrites-<role>.toml`.
+- If `spawn_agent` is callable but a named read-only role is unavailable, use generic `explorer` only when the host proves that run has a runtime-enforced read-only sandbox. Tell it to read `.codex/agents/devrites-<role>.toml`, follow its `developer_instructions`, and execute the unchanged packet. A missing read-only custom role is not evidence that spawning is unavailable.
+- Never dispatch generic `worker` for `devrites-slice-wright` unless the host proves that worker run carries exact DevRites identity and the same `.wright-allowlist` enforcement as the named role. Codex reports a generic run as `agent_type=worker`, so the generated global hooks cannot prove that binding. Reject that unsafe rung and use the documented labelled inline wright path with `.reconcile-inline` plus the full reconcile gate.
+- If the host cannot prove the generic explorer is runtime read-only, reject that rung too. Only when no spawn primitive exists or a higher-priority policy rejects a safe spawn may the root run the documented discipline inline. Label it `independence: fallback`, never call it independent, and apply every fallback risk gate. An unbound generic wright or unconfined generic explorer is such a safety rejection, not evidence that no agents exist.
+- Wait for every required fresh-context dispatch before reconciling or advancing. A backgrounded or lost result is incomplete.
+- Codex project hooks are installed in `.codex/hooks.json`; declared-leaf hooks are scoped inside `.codex/agents/devrites-*.toml`. Review and trust them with `/hooks` before relying on hook enforcement.
 - When this skill asks a HITL question via `AskUserQuestion`: Codex's equivalent (`request_user_input`) exists only in Plan mode. Outside Plan mode, render the option set as a plain numbered list in chat and **end the turn** so the human answers: NEVER silently pick an option yourself; auto-picking is AFK's contract, gated by the `.devrites/AFK` sentinel.
 
 
 # $rite-review: feature-scoped review
 
-Senior review of the **active feature scope only**. **Read the active workspace first**;
-if none, tell the user to run `$rite-spec <feature>`.
+Review the **active feature scope only**. **Read the active workspace first**; if none,
+tell the user to run `$rite-spec <feature>`.
 
-> **Differs from built-in `/code-review` in:** `/code-review` is a generic
-> diff review with no workspace context. `$rite-review` reads
+> **Scope:** `/code-review` is a generic diff review with no workspace context.
+> `$rite-review` reads
 > `.devrites/work/<slug>/spec.md` first, runs Spec ↔ Code-review axes as
-> parallel subagents (see [`parallel-dispatch.md`](../devrites-lib/reference/parallel-dispatch.md)), and gates feeding
+> parallel fresh-context reviewers (see [`parallel-dispatch.md`](../devrites-lib/reference/parallel-dispatch.md)), and gates feeding
 > into `$rite-seal`. Use `/code-review` for a one-off diff; use
 > `$rite-review` for a DevRites feature where the spec is the contract.
 
@@ -34,7 +38,7 @@ Pull these via `Read` when the diff demands them:
 - `code-review.md`: small PRs, severity labels, tests-first review focus.
 - `review-checklist.md`: compact pass/fail sweep before reporting the verdict.
 - `principles.md`: declared project invariants (`.devrites/principles.md`); a diff that violates one with no recorded exception is a Critical, blocking finding.
-- `testing.md`: confirm the tests prove the spec, not just pass.
+- `testing.md`: confirm that passing tests actually prove the spec.
 - `agents.md`: when to fan out to which review subagent.
 - `security.md`: when input / auth / data / integrations / secrets are in scope.
 - `security-checklist.md`: for the same security-sensitive scope, the compact trust-boundary sweep.
@@ -44,10 +48,14 @@ Pull these via `Read` when the diff demands them:
 - **Feature scope only.** Review touched files + the diff. **NO whole-project refactors,
   NO drive-by cleanup.** DO NOT delete suspected dead code outside this feature without
   asking. Spec Drift Guard applies.
-- **Reviews the finished product.** `$rite-polish` has already done **code simplification**
-  + UI normalize/polish. Review judges; if it reveals a real complexity issue polish
-  missed, flag it as a finding: don't re-run a simplification sweep here.
-- Findings are labeled (below). Re-prove after any change you make.
+- **Review the finished product.** `$rite-polish` has already simplified code and
+  normalized or polished UI. If review finds a remaining complexity issue, record it as
+  a finding rather than rerunning a simplification pass.
+- Findings are labeled (below). Re-prove after any accepted correction.
+- **Reviewers judge; root reconciles; wright fixes.** Follow
+  [`agents.md`](../devrites-lib/reference/standards/agents.md). The root owns the verdict and
+  canonical writes; every accepted source/test correction routes to
+  `devrites-slice-wright`.
 
 ## Workflow
 0. Read `.agents/skills/devrites-lib/reference/standards/core.md` first (the always-on operating rules); pull the
@@ -64,13 +72,14 @@ Pull these via `Read` when the diff demands them:
 2. **Review tests first:** do they prove the acceptance criteria? Missing,
    weak, or wrong tests are the first findings.
    **Completion:** every acceptance criterion maps to a proven test or a labeled finding.
-3. **Spec ↔ Code-review split (parallel sub-agents, fresh context).** A change can pass
+3. **Review spec and code separately in parallel.** A change can pass
    one axis and fail the other: code that follows every project standard but
    implements the wrong thing (Code-review pass, Spec fail), or code that does exactly
    what the spec asked but breaks project conventions (Spec pass, Code-review fail).
-   Running them serially in one context lets one mask the other. So:
-   - Dispatch **two** read-only reviewers in **parallel** via the `Task` tool, each
-     with its own narrow brief and no cross-pollination:
+   Separate contexts prevent one axis from masking the other:
+   - Freeze the candidate and fresh-context dispatch **two** read-only reviewers in
+     parallel, each with its own `agent-packet/v1`, narrow brief, and no
+     cross-pollination:
      - **Spec axis** → `devrites-spec-reviewer`: "Apply your documented discipline on
        the active feature workspace + diff. Report (a) criteria the spec asked for that
        are missing or partial, (b) behaviour in the diff the spec did not ask for
@@ -113,15 +122,20 @@ Pull these via `Read` when the diff demands them:
 6. **Performance:** apply `devrites-audit perf`
    ([performance-review](reference/performance-review.md)) only when performance is
    relevant or a regression risk is visible (measure first).
-7. Apply only in-scope fixes; **run verification after changes** (`$rite-prove` logic).
-8. Update `review.md`, `evidence.md`, and `state.md`.
-9. **Guard against the silent reviewer.** After `review.md` is written, run:
+7. Reconcile and accept only in-scope fixes. Consolidate them into one bounded wright
+   correction packet; never edit source in the reviewing context. Freeze the new candidate
+   and **run affected verification after changes** (`$rite-prove` logic), then perform at
+   most one narrow recheck of affected findings.
+8. The root updates `review.md`, `evidence.md`, and `state.md`.
+   **Completion:** the records name the reviewed candidate identity and every accepted
+   correction has affected proof plus its narrow recheck.
+9. **Require an account from every reviewer.** After `review.md` is written, run:
    ```bash
    devrites-engine review-integrity
    devrites-engine review-fingerprints --write
    ```
-   Exit 1 means an adversarial axis reported nothing and justified nothing: a suspected
-   rubber-stamp. Re-run that axis or add its `No-findings:` justification; do not carry a silent
+   Exit 1 means an adversarial axis reported neither findings nor a justification. Re-run
+   that axis or add its `No-findings:` justification; do not carry a silent
    axis into `$rite-seal` (where it surfaces as an Important).
 
 ## Finding labels
@@ -131,13 +145,13 @@ Pull these via `Read` when the diff demands them:
 - **Nit:** trivial/style.
 - **FYI:** context, no action implied.
 
-**Action decoration (orthogonal to severity).** Also tag each finding with how to act on it:
+**Action tag (separate from severity).** Tag each finding with how to act on it:
 `blocking` (fix before seal), `non-blocking` (fix when convenient), or `if-minor` (fix only if the
 change is already small: a pure noise-economics lever). Only a **`blocking` Critical** gates the
 seal; a `non-blocking` / `if-minor` finding is recorded, not a stop.
 
-## Confidence + signal-to-noise
-Borrow `$rite-vet`'s discipline so review stays **trusted, not noisy**: a reviewer that posts
+## Confidence and signal-to-noise
+Apply `$rite-vet`'s confidence rules. A reviewer that posts
 18 comments per PR teaches the team to ignore every one (below ~10% false-positive rate devs
 investigate each finding; past ~30% they label the tool noisy and skip it):
 - **Confidence-band each finding** (1-10) and state the band. A low-confidence finding (≤4)
@@ -145,21 +159,20 @@ investigate each finding; past ~30% they label the tool noisy and skip it):
   (low-confidence): n` line, never raised as Critical/Important.
 - **Verify before you escalate.** Every Critical/Important quotes the spec line or cites the
   `file:line` that proves it: no unverified blockers.
-- **Budget the noise.** Roll up trivia ("N style nits") into a single line; tooling already
+- **Limit low-value comments.** Roll up trivia ("N style nits") into a single line; tooling already
   catches style. Review's job is correctness + spec fidelity, not a lint dump.
 - **A silent axis is suspicious, not clean.** An adversarial axis that raises nothing must earn
   it: end its `## Spec` / `## Code review` section with a **`No-findings:`** line naming the
   passes it ran (missing/partial/incorrect for spec; edge cases, error paths, the riskiest
   decision, a changed behavior whose test may not cover it for code) and why each came back
-  empty. This is the mirror of confidence-banding: banding kills the false positive, this catches
-  the false negative ([`code-review.md` § Zero findings is suspicious](../devrites-lib/reference/standards/code-review.md)).
+  empty. Confidence bands suppress false positives; this requirement catches silent false
+  negatives ([`code-review.md` § Zero findings is suspicious](../devrites-lib/reference/standards/code-review.md)).
 
 ## Severity orientation (labels, not score)
 
 After labeling, summarize findings as `Critical / Important / Suggestion / Nit /
-FYI` counts. There is no composite number — `$rite-seal` gates on
-`Critical == 0` and on acceptance + drift. Inventing a number invites gaming;
-the labels do the work.
+FYI` counts. There is no composite number. `$rite-seal` gates on
+`Critical == 0` and on acceptance plus drift. Do not invent a composite score.
 
 > **Mid-flight discipline.** When tempted to demote a Critical, hide a finding, fix without re-verification, or wander out of scope: see [`anti-patterns`](reference/anti-patterns.md). Load it the moment you reach for the excuse.