feat(workflows): promote no-approvals.org to template, merge pearl framing

Pearl independently built its own no-approvals workflow (handoff in this
morning's inbox) and asked rulesets to take the best from both. That's
cross-project signal that the workflow earns a place at the template tier.

Promoted from =.ai/project-workflows/= to =claude-templates/.ai/workflows/=
with a mirror under =.ai/workflows/=. INDEX entry added under "Tools and
meta" listing the full set of trigger phrases.

Merged from pearl's draft: the prominent "What's Suspended" / "What Stays
On" split (same content as the prior "Contract" section, easier to scan),
wider trigger phrases (the project-only version had fewer), the
mode-resets-when-Craig-switches-topics guard, an explicit destructive-action
carve-out as its own bullet rather than buried in the "real question"
section, and a subagent-review-gate callout.

Kept from the rulesets version: the Session Log update emphasis between
items, the real-question include/exclude lists, and the don't-auto-wrap-up
guard.

A History section at the bottom records the merge for future archaeology.

6 files changed, 262 insertions, 176 deletions

diff --git a/.ai/project-workflows/no-approvals.org b/.ai/project-workflows/no-approvals.org
deleted file mode 100644
index 1d7d98a..0000000
--- a/.ai/project-workflows/no-approvals.org
+++ /dev/null
@@ -1,78 +0,0 @@
-#+TITLE: No-Approvals Mode
-#+AUTHOR: Craig Jennings & Claude
-#+DATE: 2026-05-28
-
-* When to Use
-
-Craig invokes this for the remainder of a session when the planned work is well-scoped and he wants to step away. He'll check back in to see completed tasks or a single question waiting for him with the recommendation as item 1.
-
-Triggers (any variant): "no approval gates for the rest of this session", "no-approvals mode", "stop asking, just keep going", "I'll check back in when you're done or stuck".
-
-* The Contract
-
-Craig gives up:
-- Per-commit approval gates (commits.md Step 2 "approve / changes / edit" prompt).
-- Per-decision check-ins for routine choices.
-- Inbox-processing confirmations.
-
-Claude keeps:
-- =/review-code= before every commit (mandatory, blocking on Critical or Important findings).
-- =/voice personal= on every commit message (mandatory; 41 patterns).
-- Stop and ask only when there's a real question (a judgment call Claude cannot make, a destructive action, an ambiguous requirement, a genuine surprise in the tree).
-- All other engineering discipline (TDD, content scope, no AI attribution, the safety rules in =commits.md=).
-
-* Workflow Steps
-
-** 1. Acknowledge the mode
-
-Restate the contract in one sentence so the mode is visible in the session log. Append a Session Log entry with the trigger phrase and the time.
-
-** 2. Plan the work
-
-Lay out the remaining work as a numbered list. Pick the order yourself; don't ask. Surface the list once so Craig sees what's coming when he checks back in.
-
-** 3. Execute each item
-
-For each item:
-- Do the work.
-- Update the Session Log per the rules in =protocols.org= (every state-mutating turn writes before the closing message).
-- Before any commit: run =/review-code= against the staged diff. Surface Critical and Important findings inline; fix them and re-review until clean. Minor findings shown but don't block.
-- Draft the commit message. Run =/voice personal= (the skill, or walk the 41 patterns inline if unavailable). Print the final message inline before committing so the log shows it.
-- Commit and push.
-
-** 4. Reach a question or finish
-
-Two exit paths:
-
-*** A. Question for Craig
-
-When you hit a real question, stop. Phrase it with the recommendation as item 1, per =interaction.md='s "Order Options with the Recommendation at Item 1". Surface the question with whatever context Craig needs to decide (what you've finished, what the question is about, what your recommendation is and why, alternatives).
-
-A "real question" excludes:
-- Routine commit-message wording (just commit it; the message stays in =git log= and can be edited via interactive rebase if it bothers you).
-- Choice of commit decomposition (use judgment).
-- Whether to do something Craig already told you to do.
-- Confirmation of obvious next steps.
-
-A "real question" includes:
-- A destructive operation (=git reset --hard=, force-push, =rm -rf=, dropping a branch).
-- An ambiguous requirement where the wrong call wastes meaningful work.
-- A surprise in the tree (unexpected WIP, unexplained branch state, a conflict you can't resolve mechanically).
-- A judgment Craig has consistently wanted to make himself.
-
-*** B. Done
-
-When the planned work is finished, post a single summary message: what shipped, what's left for next session (if anything), and a one-line invitation back ("Ready when you are"). Don't auto-wrap-up the session — that's still Craig's call.
-
-* Common Mistakes
-
-1. Skipping =/review-code= because the diff "looks clean". The gate is mandatory in this mode, not just protective when uncertain.
-2. Skipping =/voice personal= on commit messages. Same — the rule survives mode changes.
-3. Bundling a "question" with a hidden ask for permission ("I'm about to do X, is that OK?"). That's an approval gate. Either do X or surface a real question.
-4. Surfacing every minor decision as a question to be safe. The mode exists because Craig wants velocity; over-surfacing defeats the purpose. Use judgment.
-5. Forgetting to update the Session Log between items. The log is the only crash-recovery anchor while Craig is away; missing entries lose work.
-6. Failing to print the commit message inline before committing. The print step exists so the log shows exactly what landed, without Craig having to read the diff to find out.
-
-* Exit
-
-This mode applies for the remainder of the session that invoked it. It does not persist across wrap-up. The next session starts in normal-gate mode unless Craig invokes no-approvals again.
diff --git a/.ai/workflows/INDEX.org b/.ai/workflows/INDEX.org
index a61b824..36d12c8 100644
--- a/.ai/workflows/INDEX.org
+++ b/.ai/workflows/INDEX.org
@@ -84,6 +84,8 @@ This index must list every =.org= file in =.ai/workflows/= except this one and e
   - Triggers: "keep me posted on this", "provide status checks on this job", "let me know when it's done", "monitor this for me". Auto: any job estimated 10+ min.
 - =create-workflow.org= — define a new workflow.
   - Triggers: "let's create/define/design a workflow for [activity]", or unmatched workflow request after this index returns no hit.
+- =no-approvals.org= — drop the interaction-level approval gates for a pre-agreed batch while keeping engineering-discipline gates (=/review-code=, =/voice personal=, tests, session-log updates, subagent reviews, destructive-action consent). Mode stays on until Craig turns it off, a real question arises, the queue empties, or the conversation switches topics.
+  - Triggers: "no-approvals mode", "no approvals", "no-approval", "no need for approval gates", "stop asking, just keep going", "I'll check back in when you're done or stuck", "do all =<selector>= with no-approval"
 - =cross-agent-comms.org= — protocol for cross-project agent coordination via =inbox/from-agents/= (file-based IPC, GPG-signed, supports cross-machine over Tailscale). Auto: when =cross-agent-watch= detects a new inbound message, or when an agent decides to initiate a cross-project conversation. Operational scripts (=cross-agent-send=, =-recv=, =-watch=, =-status=, =-discover=, =-halt=, =-resume=) and their READMEs live at =.ai/scripts/cross-agent-comms/=.
 
 * Living Document
diff --git a/.ai/workflows/no-approvals.org b/.ai/workflows/no-approvals.org
new file mode 100644
index 0000000..e4181ce
--- /dev/null
+++ b/.ai/workflows/no-approvals.org
@@ -0,0 +1,129 @@
+#+TITLE: No-Approvals Mode
+#+AUTHOR: Craig Jennings & Claude
+#+DATE: 2026-05-28
+
+* Overview
+
+A mode Craig switches on to drop the approval gates between work items so a pre-agreed batch of tasks runs straight through without "OK to proceed?" interruptions. The mode stays on until Craig turns it off, until a real question arises, until the queue runs out, or until the conversation moves to an unrelated topic.
+
+The point is throughput on work where the approval has already been earned upfront — a queue of tagged tasks Craig triaged, a "do all the =:quick:solo:= ones" sweep, a multi-step refactor with no design calls left. Approval gates earn their keep when judgment is uncertain. They become friction when the decision is already made.
+
+This is *not* a license to skip the engineering discipline that keeps work shippable. Code review, voice pass, testing, and verification all stay on. The gates this mode turns off are the *interaction* gates: "I drafted a commit message, approve?" / "Plan looks like X, OK to start?" / "Ready to push?"
+
+* When to Use This Workflow
+
+Craig activates the mode with any of:
+
+- "no-approvals mode" / "no approvals" / "no-approval"
+- "no need for approval gates"
+- "stop asking, just keep going"
+- "I'll check back in when you're done or stuck"
+- "do all =<selector>= with no-approval" (e.g. "do all =:quick:solo:= tasks with no-approval")
+- Queuing several tasks in =todo.org= followed by any phrase above
+- Any equivalent phrasing that signals he doesn't want to be re-asked between items
+
+Mode resets when:
+
+- Craig says approvals are back on
+- A new top-level user message switches the topic away from the batch (assume the mode is scoped to the work it was invoked for)
+- A real question or unknown next step is hit (return control to Craig and exit the batch)
+- The session wraps up (mode doesn't persist across wrap-up)
+
+* What's Suspended
+
+The interaction gates that step the workflow back to Craig for an "OK to proceed?" check:
+
+- The commit-message gate in =commits.md= Step 2. Print the final commit message inline, then commit immediately. No "approve / request changes / open in editor" prompt.
+- The PR-description gate. Print the final body, then create the PR.
+- The PR-review-reply gate. Print the final reply, then post.
+- "Ready to start?" / "Plan looks like X, proceed?" gates before implementation work begins.
+- "Move on to the next task?" gates between items in a queued batch.
+- Per-task summary prompts at the end of each item. Give one short result line and proceed to the next.
+
+* What Stays On
+
+The engineering-discipline gates protect quality, not Craig's interaction time. They remain in force:
+
+- =/review-code= against the staged diff before every commit. Critical and Important findings still block. Minor findings still surface. No "proceed anyway" override unless Craig has given it explicitly for this batch.
+- =/voice personal= on every publish artifact (commit messages, PR titles + bodies, PR review comments). The 41-pattern walk happens. The printed result just doesn't wait for approval.
+- The full test suite + lint + compile before commit (per =verification.md=).
+- Fetch-and-reconcile in =commits.md= Step 0.
+- Session Log updates per =protocols.org=. Every state-mutating turn writes to =.ai/session-context.org= before the closing message. The log is the crash-recovery anchor while Craig is away. Missing entries lose work.
+- Subagent review-gate cadence (=subagents.md=). Review each subagent's output before the next dispatch.
+- Destructive or irreversible operations per =CLAUDE.md='s "Executing actions with care": force-push, =rm -rf=, dropping a column, dropping a branch, package removal. These need explicit consent regardless of mode. No-approvals is for *interaction* gates, not destructive-action consent.
+
+* Workflow Steps
+
+** 1. Acknowledge the mode
+
+Restate the contract in one sentence so the mode is visible. Name the scope ("no-approvals for the =:quick:solo:= tasks; stays on until done or until I hit a question"). Append a Session Log entry with the trigger phrase and the time.
+
+** 2. Plan the work
+
+Lay out the remaining work as a numbered list. Pick the order yourself; don't ask. Surface the list once so Craig sees what's coming when he checks back in.
+
+** 3. Execute each item
+
+For each item:
+
+- Do the work.
+- Update the Session Log per the rules in =protocols.org=.
+- Before any commit: run =/review-code= against the staged diff. Surface Critical and Important findings inline; fix them and re-review until clean. Minor findings show but don't block.
+- Draft the commit message. Run =/voice personal= (the skill, or walk the 41 patterns inline if unavailable). Print the final message inline before committing so the log shows it.
+- Commit and push.
+- One-line status between items ("Task X done, on to Y.") so Craig knows what's happening when he checks back in.
+
+** 4. Reach a question or finish
+
+Two exit paths:
+
+*** A. Question for Craig
+
+When you hit a real question, stop. Phrase it with the recommendation as item 1, per =interaction.md='s "Order Options with the Recommendation at Item 1". Surface the question with whatever context Craig needs to decide (what you've finished, what the question is about, what your recommendation is and why, alternatives).
+
+A "real question" does NOT include:
+
+- Routine commit-message wording. Just commit it. The message stays in =git log= and can be edited via interactive rebase if it bothers you.
+- Choice of commit decomposition. Use judgment.
+- Whether to do something Craig already told you to do.
+- Confirmation of obvious next steps.
+
+A "real question" DOES include:
+
+- A destructive operation (=git reset --hard=, force-push, =rm -rf=, dropping a branch).
+- An ambiguous requirement where the wrong call wastes meaningful work.
+- A surprise in the tree (unexpected WIP, unexplained branch state, a conflict you can't resolve mechanically).
+- A judgment Craig has consistently wanted to make himself.
+- A finding suggesting the user's stated goal is wrong (e.g. the "fix" reveals the bug is elsewhere).
+
+When breaking out, say so explicitly: "Pausing no-approvals batch — <reason>. Decision needed: <question>."
+
+*** B. Done
+
+When the planned work is finished, post a single summary message: what shipped, what's left for next session (if anything), and a one-line invitation back ("Ready when you are"). Don't auto-wrap-up the session — that's still Craig's call.
+
+* Common Mistakes
+
+1. *Skipping =/review-code=* — the gate is mandatory in this mode, not just protective when uncertain.
+2. *Skipping =/voice personal= on commit messages* — same: the rule survives mode changes.
+3. *Bundling a "question" with a hidden ask for permission* ("I'm about to do X, is that OK?"). That's an approval gate. Either do X or surface a real question.
+4. *Surfacing every minor decision as a question to be safe* — the mode exists because Craig wants velocity; over-surfacing defeats the purpose. Use judgment.
+5. *Plowing through a Critical or Important finding* — those still block. The batch pauses, the issue gets fixed, the batch resumes.
+6. *Skipping destructive-action consent* — force push, =rm -rf=, dropping production data still need explicit consent. No-approvals doesn't cover these.
+7. *Continuing past genuine ambiguity* — if there are two reasonable ways forward, stop and ask. The batch's purpose is to skip *redundant* approvals, not to invent decisions Craig didn't pre-agree to.
+8. *Forgetting to surface progress* — Craig still wants the one-line status between items so he knows what's happening.
+9. *Forgetting to update the Session Log between items* — the log is the only crash-recovery anchor while Craig is away.
+10. *Failing to print the commit message inline before committing* — the print step exists so the log shows exactly what landed without Craig having to read the diff to find out.
+11. *Carrying no-approvals across sessions or unrelated user messages* — assume it resets when the work it was scoped for finishes, or when Craig moves to a different topic.
+
+* Exit
+
+This mode applies for the remainder of the session that invoked it. It doesn't persist across wrap-up. The next session starts in normal-gate mode unless Craig invokes no-approvals again.
+
+* Living Document
+
+If a recurring pattern emerges (e.g. Craig wants the one-line status to include the commit SHA, or wants per-task tests skipped because the suite runs once at the end), fold it in. The mode is shaped by use — refine as the dogfooding signal arrives.
+
+* History
+
+Promoted from project-only (=.ai/project-workflows/no-approvals.org= in rulesets, commit =e27bf57= 2026-05-28) to template after pearl independently built its own version (handoff =2026-05-28-0814-from-pearl-no-approvals.org=). The merge took pearl's prominent "What's Suspended" / "What Stays On" split, wider trigger phrases, the mode-resets-on-topic-shift guard, the explicit destructive-action carve-out, and the subagent-review callout. The session-log emphasis, real-question include/exclude lists, and "don't auto-wrap-up" guard came from rulesets.
diff --git a/claude-templates/.ai/workflows/INDEX.org b/claude-templates/.ai/workflows/INDEX.org
index a61b824..36d12c8 100644
--- a/claude-templates/.ai/workflows/INDEX.org
+++ b/claude-templates/.ai/workflows/INDEX.org
@@ -84,6 +84,8 @@ This index must list every =.org= file in =.ai/workflows/= except this one and e
   - Triggers: "keep me posted on this", "provide status checks on this job", "let me know when it's done", "monitor this for me". Auto: any job estimated 10+ min.
 - =create-workflow.org= — define a new workflow.
   - Triggers: "let's create/define/design a workflow for [activity]", or unmatched workflow request after this index returns no hit.
+- =no-approvals.org= — drop the interaction-level approval gates for a pre-agreed batch while keeping engineering-discipline gates (=/review-code=, =/voice personal=, tests, session-log updates, subagent reviews, destructive-action consent). Mode stays on until Craig turns it off, a real question arises, the queue empties, or the conversation switches topics.
+  - Triggers: "no-approvals mode", "no approvals", "no-approval", "no need for approval gates", "stop asking, just keep going", "I'll check back in when you're done or stuck", "do all =<selector>= with no-approval"
 - =cross-agent-comms.org= — protocol for cross-project agent coordination via =inbox/from-agents/= (file-based IPC, GPG-signed, supports cross-machine over Tailscale). Auto: when =cross-agent-watch= detects a new inbound message, or when an agent decides to initiate a cross-project conversation. Operational scripts (=cross-agent-send=, =-recv=, =-watch=, =-status=, =-discover=, =-halt=, =-resume=) and their READMEs live at =.ai/scripts/cross-agent-comms/=.
 
 * Living Document
diff --git a/claude-templates/.ai/workflows/no-approvals.org b/claude-templates/.ai/workflows/no-approvals.org
new file mode 100644
index 0000000..e4181ce
--- /dev/null
+++ b/claude-templates/.ai/workflows/no-approvals.org
@@ -0,0 +1,129 @@
+#+TITLE: No-Approvals Mode
+#+AUTHOR: Craig Jennings & Claude
+#+DATE: 2026-05-28
+
+* Overview
+
+A mode Craig switches on to drop the approval gates between work items so a pre-agreed batch of tasks runs straight through without "OK to proceed?" interruptions. The mode stays on until Craig turns it off, until a real question arises, until the queue runs out, or until the conversation moves to an unrelated topic.
+
+The point is throughput on work where the approval has already been earned upfront — a queue of tagged tasks Craig triaged, a "do all the =:quick:solo:= ones" sweep, a multi-step refactor with no design calls left. Approval gates earn their keep when judgment is uncertain. They become friction when the decision is already made.
+
+This is *not* a license to skip the engineering discipline that keeps work shippable. Code review, voice pass, testing, and verification all stay on. The gates this mode turns off are the *interaction* gates: "I drafted a commit message, approve?" / "Plan looks like X, OK to start?" / "Ready to push?"
+
+* When to Use This Workflow
+
+Craig activates the mode with any of:
+
+- "no-approvals mode" / "no approvals" / "no-approval"
+- "no need for approval gates"
+- "stop asking, just keep going"
+- "I'll check back in when you're done or stuck"
+- "do all =<selector>= with no-approval" (e.g. "do all =:quick:solo:= tasks with no-approval")
+- Queuing several tasks in =todo.org= followed by any phrase above
+- Any equivalent phrasing that signals he doesn't want to be re-asked between items
+
+Mode resets when:
+
+- Craig says approvals are back on
+- A new top-level user message switches the topic away from the batch (assume the mode is scoped to the work it was invoked for)
+- A real question or unknown next step is hit (return control to Craig and exit the batch)
+- The session wraps up (mode doesn't persist across wrap-up)
+
+* What's Suspended
+
+The interaction gates that step the workflow back to Craig for an "OK to proceed?" check:
+
+- The commit-message gate in =commits.md= Step 2. Print the final commit message inline, then commit immediately. No "approve / request changes / open in editor" prompt.
+- The PR-description gate. Print the final body, then create the PR.
+- The PR-review-reply gate. Print the final reply, then post.
+- "Ready to start?" / "Plan looks like X, proceed?" gates before implementation work begins.
+- "Move on to the next task?" gates between items in a queued batch.
+- Per-task summary prompts at the end of each item. Give one short result line and proceed to the next.
+
+* What Stays On
+
+The engineering-discipline gates protect quality, not Craig's interaction time. They remain in force:
+
+- =/review-code= against the staged diff before every commit. Critical and Important findings still block. Minor findings still surface. No "proceed anyway" override unless Craig has given it explicitly for this batch.
+- =/voice personal= on every publish artifact (commit messages, PR titles + bodies, PR review comments). The 41-pattern walk happens. The printed result just doesn't wait for approval.
+- The full test suite + lint + compile before commit (per =verification.md=).
+- Fetch-and-reconcile in =commits.md= Step 0.
+- Session Log updates per =protocols.org=. Every state-mutating turn writes to =.ai/session-context.org= before the closing message. The log is the crash-recovery anchor while Craig is away. Missing entries lose work.
+- Subagent review-gate cadence (=subagents.md=). Review each subagent's output before the next dispatch.
+- Destructive or irreversible operations per =CLAUDE.md='s "Executing actions with care": force-push, =rm -rf=, dropping a column, dropping a branch, package removal. These need explicit consent regardless of mode. No-approvals is for *interaction* gates, not destructive-action consent.
+
+* Workflow Steps
+
+** 1. Acknowledge the mode
+
+Restate the contract in one sentence so the mode is visible. Name the scope ("no-approvals for the =:quick:solo:= tasks; stays on until done or until I hit a question"). Append a Session Log entry with the trigger phrase and the time.
+
+** 2. Plan the work
+
+Lay out the remaining work as a numbered list. Pick the order yourself; don't ask. Surface the list once so Craig sees what's coming when he checks back in.
+
+** 3. Execute each item
+
+For each item:
+
+- Do the work.
+- Update the Session Log per the rules in =protocols.org=.
+- Before any commit: run =/review-code= against the staged diff. Surface Critical and Important findings inline; fix them and re-review until clean. Minor findings show but don't block.
+- Draft the commit message. Run =/voice personal= (the skill, or walk the 41 patterns inline if unavailable). Print the final message inline before committing so the log shows it.
+- Commit and push.
+- One-line status between items ("Task X done, on to Y.") so Craig knows what's happening when he checks back in.
+
+** 4. Reach a question or finish
+
+Two exit paths:
+
+*** A. Question for Craig
+
+When you hit a real question, stop. Phrase it with the recommendation as item 1, per =interaction.md='s "Order Options with the Recommendation at Item 1". Surface the question with whatever context Craig needs to decide (what you've finished, what the question is about, what your recommendation is and why, alternatives).
+
+A "real question" does NOT include:
+
+- Routine commit-message wording. Just commit it. The message stays in =git log= and can be edited via interactive rebase if it bothers you.
+- Choice of commit decomposition. Use judgment.
+- Whether to do something Craig already told you to do.
+- Confirmation of obvious next steps.
+
+A "real question" DOES include:
+
+- A destructive operation (=git reset --hard=, force-push, =rm -rf=, dropping a branch).
+- An ambiguous requirement where the wrong call wastes meaningful work.
+- A surprise in the tree (unexpected WIP, unexplained branch state, a conflict you can't resolve mechanically).
+- A judgment Craig has consistently wanted to make himself.
+- A finding suggesting the user's stated goal is wrong (e.g. the "fix" reveals the bug is elsewhere).
+
+When breaking out, say so explicitly: "Pausing no-approvals batch — <reason>. Decision needed: <question>."
+
+*** B. Done
+
+When the planned work is finished, post a single summary message: what shipped, what's left for next session (if anything), and a one-line invitation back ("Ready when you are"). Don't auto-wrap-up the session — that's still Craig's call.
+
+* Common Mistakes
+
+1. *Skipping =/review-code=* — the gate is mandatory in this mode, not just protective when uncertain.
+2. *Skipping =/voice personal= on commit messages* — same: the rule survives mode changes.
+3. *Bundling a "question" with a hidden ask for permission* ("I'm about to do X, is that OK?"). That's an approval gate. Either do X or surface a real question.
+4. *Surfacing every minor decision as a question to be safe* — the mode exists because Craig wants velocity; over-surfacing defeats the purpose. Use judgment.
+5. *Plowing through a Critical or Important finding* — those still block. The batch pauses, the issue gets fixed, the batch resumes.
+6. *Skipping destructive-action consent* — force push, =rm -rf=, dropping production data still need explicit consent. No-approvals doesn't cover these.
+7. *Continuing past genuine ambiguity* — if there are two reasonable ways forward, stop and ask. The batch's purpose is to skip *redundant* approvals, not to invent decisions Craig didn't pre-agree to.
+8. *Forgetting to surface progress* — Craig still wants the one-line status between items so he knows what's happening.
+9. *Forgetting to update the Session Log between items* — the log is the only crash-recovery anchor while Craig is away.
+10. *Failing to print the commit message inline before committing* — the print step exists so the log shows exactly what landed without Craig having to read the diff to find out.
+11. *Carrying no-approvals across sessions or unrelated user messages* — assume it resets when the work it was scoped for finishes, or when Craig moves to a different topic.
+
+* Exit
+
+This mode applies for the remainder of the session that invoked it. It doesn't persist across wrap-up. The next session starts in normal-gate mode unless Craig invokes no-approvals again.
+
+* Living Document
+
+If a recurring pattern emerges (e.g. Craig wants the one-line status to include the commit SHA, or wants per-task tests skipped because the suite runs once at the end), fold it in. The mode is shaped by use — refine as the dogfooding signal arrives.
+
+* History
+
+Promoted from project-only (=.ai/project-workflows/no-approvals.org= in rulesets, commit =e27bf57= 2026-05-28) to template after pearl independently built its own version (handoff =2026-05-28-0814-from-pearl-no-approvals.org=). The merge took pearl's prominent "What's Suspended" / "What Stays On" split, wider trigger phrases, the mode-resets-on-topic-shift guard, the explicit destructive-action carve-out, and the subagent-review callout. The session-log emphasis, real-question include/exclude lists, and "don't auto-wrap-up" guard came from rulesets.
diff --git a/inbox/2026-05-28-0814-from-pearl-no-approvals.org b/inbox/2026-05-28-0814-from-pearl-no-approvals.org
deleted file mode 100644
index e61b69d..0000000
--- a/inbox/2026-05-28-0814-from-pearl-no-approvals.org
+++ /dev/null
@@ -1,98 +0,0 @@
-#+TITLE: No-Approvals Mode
-#+AUTHOR: Craig Jennings & Claude
-#+DATE: 2026-05-28
-
-* Heads-up from pearl (2026-05-28)
-
-Craig flagged that he plans to use a "no-approvals" mode and the rulesets project is already building one. He drafted this in pearl as a project-workflow (=.ai/project-workflows/no-approvals.org=) and asked that a copy come here so rulesets can compare with whatever is in flight there and take the best from both.
-
-Source path in pearl: =/home/cjennings/code/pearl/.ai/project-workflows/no-approvals.org=.
-
-Key points Craig dictated, in his own framing:
-- Explicit way to signal there are no approval gates until he turns them back on.
-- Don't stop at any approval gate. Finish each task fully, then start the next. Continue until a question arises or the next work item is unknown.
-- Triggers he'll use: queuing several tasks in =todo.org= then "do all =:quick:solo:= with no-approval", or just "no-approval" / "no approvals" / "no need for approval gates" in a command.
-- Engineering discipline still applies. He named specifically: =/code-review= before every commit and =/voice personal= on every commit message (he flagged this as by far the most common). The rest of CLAUDE.md / commits.md / testing.md / verification.md still binds.
-
-Action: review against rulesets' draft, merge the better framing of each section, decide where the canonical version lives (rulesets' workflow vs claude-rules vs both).
-
-* Overview
-
-A mode Craig switches on to drop the approval gates between work items, so a pre-agreed batch of tasks runs straight through without "OK to proceed?" interruptions. Stays on until Craig turns it off, until a genuine question arises, or until the queue runs out.
-
-The point is throughput on work where the approval has already been earned upfront — a queue of tagged tasks Craig has already triaged, a "do all the =:quick:solo:= ones" sweep, a multi-step refactor with no design calls left. Approval gates are valuable when judgment is uncertain. They are friction when the decision is already made.
-
-This is *not* a license to skip the engineering discipline that keeps work shippable. Code review, voice pass, testing, and verification all stay on. The gates this turns off are the *interaction* gates — "I drafted a commit message, approve?" / "Plan looks like X, OK to start?" / "Ready to push?"
-
-* When to Use This Workflow
-
-Craig activates it with any of:
-- "no-approval" / "no approvals"
-- "no need for approval gates"
-- "do all <selector> with no-approval" (e.g. "do all =:quick:solo:= tasks with no-approval")
-- Queuing several tasks in =todo.org= followed by any phrase above
-- Any equivalent phrasing that signals he does not want to be re-asked between items
-
-Deactivates when:
-- Craig says it is back on (any explicit "approvals back on" signal)
-- A new top-level user message arrives that does not reaffirm no-approvals — assume the mode resets when Craig switches topics
-- A genuine question or unknown next step is hit — return control to Craig and exit the batch
-
-* What's Suspended
-
-Approval gates that step the workflow back to Craig for an "OK to proceed?" check:
-
-- The commit-message gate in =commits.md= Step 2 (draft inline, get approval, commit). Print the final commit message inline, then commit immediately. No "approve / request changes / open in editor" prompt.
-- The PR-description gate in the same flow. Print the final body, then create the PR.
-- The PR-review-reply gate. Print the final reply, then post.
-- "Ready to start?" / "Plan looks like X, proceed?" gates before implementation work begins.
-- "Move on to the next task?" gates between items in a queued batch.
-- Per-task summary prompts at the end of each item. Give one short result line and proceed to the next.
-
-* What Stays On
-
-Engineering discipline gates that protect quality, not Craig's interaction time:
-
-- =/code-review= against the staged diff before every commit. Critical and Important findings still block. Minor findings still surface. No "proceed anyway" override unless Craig has given it explicitly for this batch.
-- =/voice personal= against every publish artifact (commit messages, PR titles + bodies, PR review comments). The 41-pattern walk happens. The printed result just does not wait for approval.
-- The full test suite + lint + compile before commit (=verification.md=).
-- Fetch-and-reconcile in =commits.md= Step 0.
-- Any destructive or irreversible operation per =CLAUDE.md= "Executing actions with care". Those need explicit consent regardless of the mode — force push, =rm -rf=, dropping a column. No-approvals is for *interaction* gates, not destructive-action consent.
-- Anything specifically requiring Craig's design call, preference, or sign-off. Stop and ask. The batch ends here.
-- Subagent review-gate cadence (=subagents.md=). Review each subagent's output before the next dispatch.
-
-* When to Break Out of the Batch
-
-Even with no-approvals on, return control to Craig immediately if:
-
-- A genuine ambiguity surfaces (multiple ways to do the next step, no clear default).
-- A finding suggests the user's stated goal is wrong (e.g. the "fix" reveals the bug is elsewhere).
-- =/code-review= surfaces a Critical or Important finding the batch cannot resolve safely.
-- Tests fail in a way that needs Craig's judgment.
-- The queued work is done and no obvious next item exists.
-- Any guideline above says "stop and ask" — that wins over no-approvals.
-
-When breaking out, say so explicitly: "Pausing no-approvals batch — <reason>. Decision needed: <question>."
-
-* Activation Pattern
-
-When Craig invokes no-approvals (with one of the phrases above):
-
-1. Acknowledge the mode is on and name the scope ("no-approvals for the =:quick:solo:= tasks; stays on until done or until I hit a question").
-2. Identify the queue — the tasks named explicitly, or the org-tag selector, or "the next N tasks in todo.org".
-3. Walk them in order. For each: do the work, run =/code-review= + =/voice personal= + tests as required, commit, move to the next.
-4. Brief one-line status between items ("Task X done, on to Y").
-5. At the end of the queue: summarize what shipped, confirm batch is complete, return control.
-
-* Common Mistakes
-
-1. *Bypassing =/code-review= or =/voice personal=* — these are not approval gates, they are quality gates. They stay on.
-2. *Plowing through a Critical finding* — Critical and Important findings still block. The batch pauses, the issue gets fixed, the batch resumes.
-3. *Skipping destructive-action consent* — force push, =rm -rf=, dropping production data still need explicit consent per =CLAUDE.md= "Executing actions with care". No-approvals does not cover these.
-4. *Continuing past genuine ambiguity* — if there are two reasonable ways forward, stop and ask. The batch's purpose is to skip *redundant* approvals, not to invent decisions Craig did not pre-agree to.
-5. *Forgetting to surface progress* — Craig still wants the one-line status between items so he knows what is happening.
-6. *Carrying no-approvals across sessions or unrelated user messages* — assume it resets when the work it was scoped for finishes, or when Craig moves to a different topic.
-
-* Living Document
-
-If a recurring pattern emerges (e.g. Craig wants the one-line status to include the commit SHA, or wants per-task tests skipped because the suite runs once at the end), fold it in. The mode is shaped by use — refine as the dogfooding signal arrives.