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.

1 files changed, 0 insertions, 98 deletions

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.