Supervisor-Agent Pattern for Write-Path Actions — Design v0

Status: DESIGN ONLY. Nothing here is wired. This document is the reviewable spec for the Notion task "Design supervisor-agent pattern for write-path actions (Vending-Bench Phase-2 lift)." It does not build a /supervise skill, does not edit settings.json, and does not gate any real write-path. Wiring changes how Ray operates and is a separate, founder-greenlit step.

The lineage: Project Vend Phase 1 single-agent Claudius failed from helpfulness bias (priced below cost, refused $100 offers on $15 items, over-discounted). The Phase-2 fix was not a better prompt — it was an organizational hierarchy (Seymour Cash CEO → Claudius Shopkeeper → Clothius Merchandiser) where the CEO forced verification of prices and delivery times before commitment. The single most valuable intervention: CEO oversight counteracted helpfulness bias more effectively than prompt engineering alone ([[2026-05-01-vending-bench-research-brief.md]], pattern #2). This doc designs RDCO's "Seymour Cash" — a supervisor that critiques Ray's intended write-action before it ships.

1. Reconciliation with verify-action and the /verify-* family (LEAD)

This is the most important section. The risk is building a duplicate. We do not.

The three patterns and where each lives

RDCO already has two distinct verification mechanisms. They occupy different layers and neither covers the write-path-intent gate that Vending-Bench Phase 2 demands. /supervise is a third, specific thing — and the cleanest design is to make it a new sibling in the existing /verify-* family, not a standalone parallel system.

Verdict: NOT a duplicate of verify-action. EXTEND the /verify-* family with a new sibling.

Three sub-claims, each load-bearing:

1. /supervise is NOT the same thing as verify-action. verify-action is a mechanical, deterministic, format-level hook with no judgment — it cannot reason about whether sending an email to a vendor is a good idea, only whether the chat_id regex matches or the text has an em-dash. The Vending-Bench lesson is specifically about judgment under helpfulness bias (should I give this discount? is this price below cost?) — that is irreducibly an LLM-judgment task. A regex cannot catch "you're about to refuse a $100 offer on a $15 item." So verify-action does not subsume the need, and /supervise must not be built as more verify-action rules.

2. /supervise is NOT a duplicate of the existing /verify- skills either — it fills the one open slot in that family.* The family currently covers three surfaces: produced artifacts (/verify-vault-write), produced strategic recommendations (/verify-strategic-output), and outbound dispatch prompts (/verify-dispatch). Notice the gap: every member judges a produced artifact or a plan to produce one. None judges a side-effecting action against the outside world the instant before it fires (send this email, charge this card, push this repo, write to this shared system). That action-intent gate is exactly the Seymour-Cash slot. So:

   Overlap honesty — /verify-dispatch already reasons about action-risk at draft time. This isn't a wholly new concern. /verify-dispatch already carries a rubric item that flags classifier-blocking actions (external email, force-push, settings.json edits) when it reviews an outbound dispatch prompt — i.e., it catches "this dispatch is about to instruct a worker to do something the classifier hard-gates" at dispatch-DRAFT time. What it does not cover is the same action at fire time: when Ray itself is one tool-call away from charging the card / sending the email / pushing the repo, with the literal arguments resolved, outside any dispatch-prompt framing. The supervisor is the fire-time complement to verify-dispatch's draft-time check — same family instinct (don't let a costly outward action go unreviewed), applied at the moment the action actually fires rather than when a plan to dispatch it is being written. That continuity strengthens the sibling case: the family already reaches toward action-risk; the supervisor completes the reach to the fire instant.

3. Recommendation: build /supervise as the fourth /verify-* sibling — /verify-write-action — reusing the family's entire structural shape, and wire verify-action as its mechanical pre-filter. Concretely:

   • Reuse wholesale from the verification-as-independent-worker SOP ([[2026-05-19-verification-as-independent-worker-pattern.md]]): fresh-eyes mandatory dispatch (parent that wants to act cannot self-supervise — confirmation/helpfulness bias is the whole point), read-source-of-truth-fresh, mechanical rubric scoring, structured verdict block, no-auto-execute, depth=1 recursion stop, max-2-iterate-then-escalate, founder-override-beats-the-loop.
   • The only genuinely new content is (a) the action taxonomy (§2), (b) a rubric scored against policy + economics + L5 delegated authority instead of artifact quality, and (c) a third verdict value (ESCALATE TO FOUNDER) that the artifact-critics don't have because artifacts don't carry irreversible outward consequence the way actions do.

Why "extend the family" beats "new /supervise system": a parallel system would duplicate the SOP's pre-flight checklist, verdict schema, recursion-stop, and escalation rules — and then drift from them. The SOP explicitly warns that skill-shape drift is itself a failure mode. Keeping /supervise inside the family means one shape, one set of failure-mode defenses, one place to fix bias. The task title says "supervisor-agent pattern"; the implementation of that pattern is "a fourth verify-* sibling that judges actions, with verify-action as its deterministic Layer-1 pre-filter."

The two-layer stack (how they compose)

Ray intends a write-path action
        │
        ▼
  Layer 1: verify-action  (mechanical hook, ~5ms, deterministic)
        │  catches: em-dash, chat_id format, length, founder-tag,
        │           regex-detectable policy violations
        ├─ block ──► fix mechanically, retry
        ▼ pass
  Layer 2: /verify-write-action  (LLM supervisor sub-agent, ~1 fork)
        │  judges: helpfulness-bias, economic sanity, policy fit,
        │          L5-authority scope, voice/relationship risk
        │  FAIL-CLOSED: on supervisor error/timeout/malformed
        │  output, the Tier-A action is BLOCKED (see §3)
        ├─ APPROVE ────────► "no objection found." Does NOT authorize
        │                     the action. The pre-existing class gate
        │                     (founder send-button / DECISION-APPROVE /
        │                     PR-workflow) is what authorizes firing.
        │                     Supervisor APPROVE is necessary-not-sufficient.
        ├─ REQUEST CHANGES ─► parent revises intent, re-supervise (max 2)
        └─ ESCALATE ────────► founder decides; action does NOT fire

Layer 1 is cheap and catches the mechanical 80%. Layer 2 is the expensive judgment gate that only runs on the action classes the taxonomy (§2) marks as warranting review — which is why latency stays bounded (§6).

Critical semantics — APPROVE is necessary, not sufficient. The supervisor has zero execution authority. An APPROVE verdict means "the supervisor found no objection" — it does not fire the action and does not authorize firing it. The action's actual authorization remains the pre-existing class gate it always had: the founder's send-button for external email ([[feedback_no_autonomous_external_email]]), a founder DECISION-APPROVE for financial actions ([[feedback_paper_trade_deploy_authorization]]), the PR-workflow for code/push ([[feedback_pr_only_workflow]]), and the classifier hard-gate where one applies (§5). The supervisor sits in front of those gates as an extra critique; it can never replace them. So an APPROVE never means "now Ray can fire this on its own" — it means "this cleared the critique; the normal authorization gate still has to say yes." This is the load-bearing safety property: the supervisor can never be the sole authorizer of an outward action.

One naming note for the founder: I propose /verify-write-action (family-consistent) over /supervise (evocative but orphaned from the family naming). Open to /supervise if you prefer the Vending-Bench mnemonic — it's cosmetic. The rest of this doc uses the supervisor generically.

2. Action taxonomy — what warrants supervisor review

The gate is only worth its latency on outward-facing, hard-to-reverse, or shared-state writes. The governing principle, straight from Vending-Bench: review the actions where helpfulness bias produces real-world loss (money, relationships, reputation, shared-system integrity). Skip the high-frequency low-stakes writes — gating those would tax every loop for no protection.

TIER A — SUPERVISE (Layer-2 gate required)

TIER B — EXCLUDE (no Layer-2 gate, latency-protected)

The boundary rule

Supervise an action iff it (a) crosses RDCO's boundary to a third party, OR (b) moves money, OR (c) mutates shared state others read, OR (d) is hard to reverse — AND is not already a deterministic classifier hard-gate that removes Ray's discretion entirely (§5).

Channel replies to the founder and the entire internal-reversible-write surface stay on Layer 1 only. This keeps the supervisor's call-volume low enough that per-call latency is a non-issue (§6).

3. The supervisor interface

A narrow-scope fresh-eyes sub-agent with ZERO execution authority. It reads, judges, and returns a verdict. It cannot send, charge, push, or write anything. (This mirrors the family's "no auto-rewrite / no auto-execute" rule and is the structural guarantee that the supervisor can't become the helpfulness-biased actor it's checking.)

Inputs

1. Proposed action (required) — the literal tool call the parent is about to make: tool name + full arguments (the actual email body / Stripe amount / push target, not a summary). Same discipline as /verify-dispatch requiring the actual dispatch text.
2. Intent (required) — one or two sentences: why the parent wants to take this action, and what outcome it expects. This is what lets the supervisor catch helpfulness bias ("I want to refund the full amount to keep them happy" → supervisor flags the economic asymmetry).
3. Context bundle (curated — see §4) — the relevant policy slice + the L5 north-star frame + any prior commitments on this thread/relationship. NOT the whole vault. Curation is the core tension (§4).
4. Rubric path (read fresh every invocation) — the supervisor's own SKILL.md rubric, per the family's read-fresh discipline.

Outputs — three verdicts

SUPERVISOR VERDICT: <APPROVE | REQUEST CHANGES | ESCALATE TO FOUNDER>
Subject: <tool name + action slug>
Action class: <taxonomy tier-A class>
Source-of-truth: <rubric path + policy slice read>

RUBRIC RESULTS:
- Economic sanity:        <PASS/FAIL> — <one-line reason>
- Helpfulness-bias check: <PASS/FAIL> — <one-line reason>
- Policy fit:             <PASS/FAIL> — <one-line reason>
- Authority scope (L5):   <PASS/FAIL> — <one-line reason>
- Reversibility/blast-radius: <PASS/FAIL> — <one-line reason>
- Voice/relationship risk: <PASS/FAIL> — <one-line reason>

FINDINGS (if REQUEST CHANGES / ESCALATE):
- <tag>: <description> — <specific fix>

ESCALATION RATIONALE (only if ESCALATE):
<one paragraph: why this exceeds Ray's delegated authority and what decision the founder must make>

• APPROVE = "no objection found" — all rubric items PASS. This does NOT authorize firing the action and the supervisor does NOT fire it. APPROVE is necessary-not-sufficient: the action's actual authorization remains the pre-existing class gate it always had — the founder's send-button for external email, a founder DECISION-APPROVE for financial actions, the PR-workflow for code/push, the classifier hard-gate where one applies (§1, §5). The supervisor's APPROVE only clears the critique; the normal authorization gate must still independently say yes. The supervisor can never be the sole authorizer of an outward action.
• REQUEST CHANGES = 1+ FAIL on a fixable-by-Ray dimension (wording, amount, scope) AND the action stays within delegated authority once fixed. Parent revises the action and re-supervises (max 2 cycles, then escalate — per the family's loop-cap).
• ESCALATE TO FOUNDER = the action exceeds Ray's delegated authority, OR consequence × uncertainty is high, OR a rubric FAIL is not Ray-fixable (it's a judgment call only the founder owns). Action does NOT fire; founder decides.

The third verdict is the genuinely new piece versus the artifact-critics: artifacts don't fire into the world, so they only need PASS/ITERATE/SCRAP. Actions can carry consequence beyond Ray's authority, so they need an explicit punt-to-founder rail. This maps 1:1 to Miura-Ko's L5 marker: "escalates when uncertainty/consequence exceeds authority" ([[2026-05-01-ann-miura-ko-six-levels-ai-pilled-organizations.md]]).

Fail-mode behavior — the supervisor FAILS CLOSED

On supervisor error, timeout, or malformed/unparseable output, the Tier-A action is BLOCKED (fail-closed). Absence of a clean APPROVE is treated as not-cleared, never as cleared. A crashed or hung supervisor must hold the action, surface the failure, and route to the founder — it must never let the action through on the theory that "the check didn't run, so proceed."

This is a deliberate departure from verify-action, which fails OPEN. verify-action's PreToolUse hook is a mechanical script that, by hook convention, exits 0 (allows the tool call) if it crashes — a sensible default for a format check on a channel reply, where a hook bug shouldn't brick every reply Ray sends. The supervisor must NOT inherit that default. The two are not symmetric: verify-action gates low-stakes, fully-reversible channel-reply mechanics, so fail-open is acceptable; the supervisor gates exactly the money / external-email / public-push surface where a single wrong fire is costly and hard to reverse. A fail-OPEN supervisor would silently wave every gated Tier-A action through the instant it crashed — converting the safety gate into a no-op precisely when it matters. Hence: verify-action fails open by design; the supervisor fails closed by design.

(Note this fail-closed default never fires anything either — a blocked-and-held action still has to clear its pre-existing class gate to proceed, per the APPROVE-is-necessary-not-sufficient rule above. Fail-closed means "do not treat as cleared," not "escalate then auto-send.")

4. Supervisor context curation — the core tension

The failure modes are symmetric and both fatal:

• Too generic a context → rubber-stamps. A supervisor handed only "be a good CEO" and the action will reason its way to APPROVE on almost everything (the agreement-bias failure the SOP already names). It becomes latency with no protection. This is the more dangerous failure because it's invisible — the gate looks like it's working.
• Too narrow / too much policy → false-rejects. A supervisor handed every memory file and every SOP will find some rule to cite against almost any action, blocking legitimate work and training the parent to route around the gate. Death by a thousand REQUEST-CHANGES.

Curation design — scoped policy packs keyed to action class

Don't hand the supervisor "everything." Hand it a small, action-class-specific policy pack assembled at supervise-time:

1. Always-loaded core (small, ~1 page): the L5 north-star frame (delegated-authority boundaries) + the boundary rule from §2 + the helpfulness-bias definition from Vending-Bench. This is the lens, not the rulebook.
2. Class-specific pack (loaded by taxonomy tier-A class):
   • External comms → feedback_no_autonomous_external_email, feedback_x_voice_mismatch, feedback_brief_imessage_link_to_hq, feedback_employer_client_content_boundary, feedback_listen_and_injection_caution (the relevant ~5, not all 50 memories).
   • Financial → Stripe policy + "API cost is budget-controlled" boundary + paper-trade authorization memory.
   • Public code/infra → feedback_pr_only_workflow + HQ carve-out + classifier-hard-gate memory.
   • Shared-system writes → the relevant data-boundary memories only.
3. Thread/relationship state (just-in-time): prior commitments on this thread or this counterparty (e.g., "you already quoted them $X last week"). This is what catches the Vending-Bench drift failure (contradicting a prior commitment).

Four discipline rules to keep curation honest

• The pack is owned by a concern separate from the actor. Per the SOP's "rubric files should be owned by a separate concern, not the producer." The policy packs live in the supervisor skill / a policy dir, never assembled by the parent that wants to act (or the parent curates a self-serving pack).
• Stale-policy-pack freshness check (a supervisor enforcing a retired memory is a false-reject generator). On every invocation the supervisor checks the date: frontmatter on each policy/memory file it loads into the pack and flags any source older than ~60 days for re-review — mirroring the verification SOP's stale-rubric rule ("check the date: frontmatter on the rubric and flag if older than ~60 days"). Stale packs are not a cosmetic problem: a memory can be superseded without being deleted, and a supervisor that blocks an action by citing a rule the founder has since reversed is generating false-rejects against current policy. Two enforcement hooks: (1) the >60-day flag surfaces the stale source in the verdict block so it gets re-scoped; (2) when two loaded memories disagree on the same topic, the supervisor applies the newer one (memories evolve, latest is canonical) AND logs the conflict so the older memory can be retired — the exact memory-conflict-logging rule from CLAUDE.md ("Don't silently apply the newer rule — surface the drift," logged to working-context.md Errors & Corrections). A supervisor that silently enforces a retired memory is indistinguishable from a mis-calibrated one; freshness-checking is how the pack stays a current-policy gate rather than a museum of old rules.
• Periodic SCRAP-test against a known-bad action. Same anti-agreement-bias drill the family already mandates: after N consecutive APPROVEs, fire a deliberately-bad action (refund $100 on a $15 item) and confirm the supervisor catches it. If it APPROVEs, the pack has gone generic — re-scope.
• False-reject log. Every REQUEST CHANGES / ESCALATE the founder later overrides as "that was fine, ship it" gets logged. A pattern of overrides on one class = that class's pack is too aggressive; loosen it. This is the calibration feedback loop (an L5 marker: updates shared memory so future behavior improves). A subset of these overrides will trace to a stale-pack false-reject — when they do, the fix is retiring the superseded memory (above), not just loosening the class.

5. Founder-escalation policy — when supervisor blocks vs punts

The supervisor has three exits. The decision tree:

Is the action a deterministic classifier HARD-GATE
(deploy/production-write the auto-mode classifier already denies,
 per feedback_automode_classifier_hard_gate)?
   YES → the supervisor is moot here; the classifier already blocks
         and only a founder-set permission rule or founder-direct
         action unblocks. Supervisor notes it and routes to founder.
         (Do NOT design the supervisor to "talk past" the hard-gate —
          that's the exact denial-bypass pattern the classifier flags.)
   NO  ↓

Is the fix within Ray's hands AND the action within delegated authority once fixed?
   YES → REQUEST CHANGES. Ray revises, re-supervises (max 2), then fires or escalates.
   NO  ↓

Does the action exceed delegated authority, OR is consequence × uncertainty high,
OR is the failing dimension a founder-only judgment call?
   YES → ESCALATE TO FOUNDER. Action does NOT fire.

What the supervisor BLOCKS-and-fixes (REQUEST CHANGES) vs PUNTS (ESCALATE)

• REQUEST CHANGES (Ray-fixable, stays in authority): email tone too effusive / over-promises a date → tighten wording. iMessage to non-founder runs long → trim per the brief-iMessage memory. A refund amount is defensible but the reason line is weak → rewrite. Ray fixes and proceeds.
• ESCALATE TO FOUNDER (out of authority or founder-judgment): any first-time action to a new external counterparty. Any financial action above a founder-set dollar threshold (propose: anything > $0 to start, loosen later — see open questions). Any action that contradicts a prior founder decision. Any action where the supervisor's own confidence is low (it should say so, not fake a verdict — per feedback_no_batched_result_declaration). Per [[feedback_no_autonomous_external_email]], all external email sends are already founder-gated — for that class the supervisor's job is to make the draft good enough that the founder's send is a 5-second yes, not to authorize the send itself.

Hard constraint — the supervisor cannot override CLAUDE.md hard rules or the classifier

The supervisor is tier-4-ish (a skill/sub-agent). It cannot authorize anything a CLAUDE.md hard rule or the auto-mode classifier forbids. If Ray's intended action is classifier-hard-gated, the supervisor's ONLY correct move is ESCALATE — it must never produce an APPROVE that the parent could cite as "the supervisor said it's fine" to retry past the classifier. That would be the denial-bypass anti-pattern ([[feedback_automode_classifier_hard_gate]]). The supervisor is a pre-filter that makes founder/classifier-gated actions better, never a substitute for those gates.

6. Latency / cost tradeoffs

• Per-supervised-write cost: ~1 sub-agent fork (same unit cost as any /verify-* member). LLM spend per call is budget-controlled (feedback_api_cost_budget_controlled) — cost is not the constraint; latency and call-volume are.
• Why the taxonomy makes this acceptable: Tier-A actions (external email, Stripe charge, public push, outbound call) are rare and inherently high-latency-tolerant — a vendor email that takes one extra sub-agent fork before sending is invisible against the human-response time of the loop. The high-frequency writes (vault, board, state, founder-replies) are all Tier-B and never hit Layer 2. So the supervisor fires maybe single-digit times per active day, on exactly the actions where a few seconds of latency is free.
• Layer-1 absorbs the cheap checks. verify-action's mechanical hook handles the ~5ms format/voice checks on every channel reply, so Layer 2 never wastes a fork on em-dash-class problems.
• Where it's NOT acceptable: any high-frequency internal write (would tax the loop), and the autonomous-monitoring path where a blocking sub-agent could stall the loop (per feedback_no_blocking_modal_in_monitoring). Mitigation: in monitoring mode, Tier-A actions that would ESCALATE are queued async to the founder via channel, not blocked-and-waited-on.
• Rule of thumb: gate the dozens-per-day actions, never the hundreds-per-day ones. The taxonomy is drawn exactly on that line.

Monitoring-mode behavior for time-sensitive Tier-A ESCALATEs (founder asleep)

The async-queue mitigation above covers the general case (escalate → park → ping founder → wait for his decision). But an ESCALATE can be time-sensitive and arrive when the founder is unreachable (asleep, the 9pm–9am off-window). This applies to any Tier-A class, not just email — a financial deadline, a deploy window, a vendor needing a same-hour answer, an outbound-call slot. The governing constraints, in tension:

• The supervisor still has zero authority — it cannot self-grant the escalated action just because the founder is slow to respond. APPROVE-is-necessary-not-sufficient and ESCALATE-does-not-fire hold especially here; "the founder was asleep" is never an authorization. (This is the same denial-bypass logic as §5: timeout pressure must not become a loophole.)
• No blocking modal — the supervisor must not freeze the monitoring loop waiting on a human (per feedback_no_blocking_modal_in_monitoring, which caused a multi-hour outage). It parks and moves on.

Specified behavior — park-with-a-deadline, never auto-fire:

1. The action does NOT fire. Default outcome of a time-sensitive ESCALATE the founder hasn't answered = the action is missed/parked, not auto-executed. For irreversible Tier-A actions (money, outbound call, public push), missing the window is the safe failure and is preferred over firing unauthorized. This is the explicit tradeoff: the supervisor optimizes against irreversible wrong-fires, accepting some missed-but-reversible-later opportunities.
2. Escalate async with the deadline attached. The channel ping to the founder includes (a) the action, (b) why it's time-sensitive, (c) the hard deadline, and (d) the explicit default ("if I don't hear from you by HH:MM, this action will be MISSED — I will not fire it"). This makes the cost of non-response legible to the founder without the agent assuming authority.
3. Open-threads / parking discipline applies. The escalate rides the existing aged-ask parking mechanism (feedback_open_threads_channel_state): the 🅿️ marker plus morning-brief surfacing means a slept-through time-sensitive escalate is the first thing the founder sees on wake, with the window-outcome noted.
4. The ONE narrow exception is out of scope for v1. A pre-authorized "if X happens overnight and the founder is unreachable, you MAY fire Y within these bounds" standing grant is conceivable — but that is a founder-set standing authorization, identical in kind to the autonomy grant of §9 Q3, and it requires its own spec. v1 does not include any overnight auto-fire path. Default stays: park, deadline-ping, miss-if-unanswered.

7. Rollout plan — gate ONE write-path first

Gate the outbound third-party email loop first. Rationale:

1. It's the single highest-leverage Vending-Bench gap per the source brief — the async-human-extension send_email affordance is the tool that converts text-bound autonomy into real-world operation, and it's the most exposed to helpfulness bias.
2. It's already founder-gated ([[feedback_no_autonomous_external_email]]) — so wiring the supervisor here is additive, pending an instrumented draft-path interception point that must first be built or identified: it inserts a quality critique before the draft reaches the founder, who still presses send. No new autonomy is granted; we're just making his send-decision a better-informed 5-second yes. The caveat (do not skip this): verify-action's rule R005 (the no-autonomous-external-email rule) is documented but not wired in v1 — because no Gmail send tool exists to wire against. There is therefore no instrumented email-send-or-draft interception point today for the supervisor to hook into. So "additive and risk-free" overstates it: a precondition of the pilot is to build or identify the draft-path interception point (the place where an outbound email draft is materialized and can be handed to the supervisor before it reaches the founder). Until that hook exists, there is nothing to wire the supervisor onto. This is a build dependency, not a given — and it's the reason Phase 1 is "wire into the draft path," not "flip a switch." It still sidesteps the "wiring changes how Ray operates" concern (no new autonomy), but it is not free.
3. It's low-volume — third-party emails are rare, so latency is a non-issue and we get clean signal on supervisor calibration before expanding.

Phased expansion (each phase = separate founder greenlight):

• Phase 0 (this doc): design only.
• Phase 1: wire /verify-write-action into the outbound-email draft path as a pre-founder critique. Founder still sends. Collect APPROVE/REQUEST-CHANGES/ESCALATE stats + false-reject log for ~2 weeks.
• Phase 2: if calibration is good, extend to Stripe financial actions (with a founder-set dollar threshold — small to start).
• Phase 3: extend to public code push / shared-system writes.
• Phase 4 (OUT of scope for this design — requires its own separate spec): letting APPROVE verdicts actually authorize the send on a narrow, dollar-capped email class without a founder press. This is the real autonomy increment — the one flip from advisory to authoritative — and it is not approved-but-deferred. It is blocked pending a separate, founder-greenlit spec with its own risk analysis and gate design (elevated to §9 Q3 so it isn't read as a pre-approved phase). Nothing in this design authorizes it; do not smuggle it in via "we already planned Phase 4."

8. Test plan — flawed-action cases the supervisor must catch

Per the acceptance criteria, ≥5 deliberately-flawed actions. Each is a fixture: (proposed action + intent) → expected verdict. These double as the anti-agreement-bias SCRAP-test corpus (§4).

A passing supervisor catches 1–7 with the indicated verdict and APPROVEs 8. Case 8 is the false-reject guard; a supervisor that fails it is mis-calibrated toward blocking.

9. Open questions for founder review

1. Naming + family placement. Ship as /verify-write-action (family-consistent, my recommendation) or /supervise (Vending-Bench mnemonic)? Either way it reuses the /verify-* SOP shape. Confirm you want it inside the family rather than a standalone system. (Top question — it's the whole reconciliation.)
2. Financial dollar-threshold for auto-APPROVE vs always-ESCALATE. I propose starting at "$0 — every financial action escalates" and loosening only after calibration data. Where do you want the line, and do you want it per-class? (Top question — it directly sets how much autonomy the supervisor grants.)
3. Does APPROVE ever get to authorize the send on its own? (The real autonomy grant — explicitly OUT of scope for this design.) Throughout this doc the supervisor's APPROVE is necessary-not-sufficient: it clears the critique but the pre-existing class gate (founder send-button, DECISION-APPROVE, PR-workflow) is what authorizes firing. The §7 Phase-4 sketch — "let an APPROVE verdict actually authorize the send without a founder press for a narrow, dollar-capped email class" — is the one place the model flips from advisory to authoritative, and it is the genuine autonomy increment. It is scoped OUT of this design and requires its own separate spec. It is not a footnote or a "far-future Phase 4 we'll get to" — surfacing it as a buried phase is exactly the phase-creep this doc warns against (a future session could read "Phase 4" as pre-approved-just-deferred and smuggle it in). Calling it out here: granting APPROVE real authorization power is a distinct, founder-greenlit decision with its own risk analysis, its own gate design, and its own spec doc — nothing in this design authorizes it, and Phase 4 in §7 must be read as "blocked pending that separate spec," not "approved-but-later." (Top question — it's where advisory becomes authoritative.)
4. Does the email-loop pilot (§7 Phase 1) stay strictly "pre-founder critique, founder still sends" for v1? (I strongly recommend yes; any move toward auto-send is Q3's separate spec, not a Phase-1 option.)
5. In autonomous-monitoring mode, confirm the rule: a Tier-A action that would ESCALATE is queued async to you via channel, never blocked-and-waited-on (per the no-blocking-modal memory), with time-sensitive escalates handled per §6. Is async-queue + park-the-action the behavior you want?
6. Who owns the policy packs (§4)? I propose a ~/.claude/policies/ dir owned separately from the supervisor skill so the actor never curates its own leniency. Acceptable, or do you want them inline in the SKILL.md?

Appendix — pattern lineage

• Vending-Bench / Project Vend Phase 2 ([[2026-05-01-vending-bench-research-brief.md]]) — Seymour Cash CEO oversight as the helpfulness-bias fix. The supervisor is RDCO's Seymour Cash for write-path actions. Open follow-up #2 in that brief ("prototype a supervisor-agent pattern... before any send action") is this doc.
• Miura-Ko L5 ([[2026-05-01-ann-miura-ko-six-levels-ai-pilled-organizations.md]]) — the supervisor operationalizes two L5 markers: acts within delegated authority (APPROVE only inside authority) and escalates when uncertainty/consequence exceeds authority (the ESCALATE rail). L4→L5 is exactly Phase 1→Phase 2 of Project Vend.
• Verification-as-independent-worker SOP ([[2026-05-19-verification-as-independent-worker-pattern.md]]) — the structural chassis the supervisor inherits wholesale. The supervisor is the fourth surface; actions are the surface, helpfulness bias + economic loss + authority overreach are the drift to catch.
• verify-action ([[~/.claude/skills/verify-action/SKILL.md]]) — Layer-1 mechanical pre-filter; complementary, not duplicated.
• Auto-mode classifier hard-gate ([[feedback_automode_classifier_hard_gate]]) — the supervisor never overrides the classifier; ESCALATE is its only move on a hard-gated action.

Changelog

v0 → v0.1 (2026-06-04) — fresh-eyes review pass

Surgical revision applying a fresh-eyes reviewer's six specific fixes. The central design claim — ship as the 4th /verify-* family sibling /verify-write-action — was reviewer-VERIFIED as sound and is unchanged. The spine, taxonomy (§2), rubric (§3), curation logic (§4), escalation tree (§5), rollout sequencing (§7), and test corpus (§8) are preserved. Six targeted patches:

1. Closed the APPROVE-semantics safety loophole (§1 stack diagram, §1 authority table, §3). v0 contradicted itself — "advisory / no execution authority" vs "APPROVE → action fires." Redefined APPROVE = "no objection found," which does NOT authorize firing; the pre-existing class gate (founder send-button / DECISION-APPROVE / PR-workflow / classifier hard-gate) remains the sole authorizer. APPROVE is now stated as necessary-not-sufficient in all three places. The supervisor can never be the sole authorizer of an outward action.
2. Added FAIL-CLOSED fail-mode (§3 new subsection + §1 diagram note). On supervisor error/timeout/malformed output the Tier-A action is BLOCKED. Explicitly contrasted with verify-action's PreToolUse hook, which fails OPEN (exit 0 on crash) — the supervisor must NOT inherit that default, because a crashing fail-open supervisor would silently wave every gated money/email action through.
3. Added overlap honesty (§1 sub-claim 2). Acknowledged that verify-dispatch already has a rubric item reasoning about classifier-blocking actions (external email, force-push, settings.json) at dispatch-DRAFT time; positioned the supervisor as the fire-time complement, strengthening the sibling case.
4. Downgraded the first-write-path claim (§7). "Strictly additive and risk-free" → "additive, pending an instrumented draft-path interception point that must first be built/identified" — because verify-action's R005 is documented-but-not-wired (no Gmail send tool exists to wire against), so no instrumented email-send/draft interception point exists yet.
5. Elevated the buried autonomy decision (§9 Q3 + §7 Phase 4). The Phase-4 idea (let APPROVE authorize the send without a founder press) is the real advisory→authoritative flip. Promoted to top-tier open question Q3 and explicitly scoped OUT of this design ("requires its own separate spec"); §7 Phase 4 rewritten as "blocked pending that spec," not a pre-approved deferred phase — closing the phase-creep the doc warns against.
6. Added two gaps (§4 + §6). (a) A stale-policy-pack freshness check in §4 — mirrors the verification SOP's >60-day rubric-flag rule and CLAUDE.md's memory-conflict-logging rule (a supervisor enforcing a retired memory is a false-reject generator). (b) Monitoring-mode behavior for time-sensitive Tier-A ESCALATEs in §6 (any class, not just email) — when the founder is asleep: park-with-a-deadline, deadline-ping, miss-if-unanswered, never auto-fire; overnight auto-fire is out of scope for v1.

Still a design doc. No implementation, no wiring, no settings.json edits, no /verify-write-action skill built. The Notion task remains open. Credit: this revision integrates a fresh-eyes review of the v0 design.