feat(reply-drafts): prepare replies you owe across all channels

[yustme]

Scout now prepares draft replies for conversations where you owe an answer, on the background runs, so you can review them in /scout-work (or the macOS app), lightly edit, and send them yourself. Scout never sends and never creates a native Gmail/Slack draft — a text file in the vault is the only output.

What it detects

Two loop types, across every enabled channel (Gmail, Slack, Linear, GitHub, WhatsApp/Messages):

• direct-debt — someone asked you something and you have not replied.
• promise-answered — you promised to follow up, asked elsewhere, and the answer has now arrived (Scout pairs the promise with the answer).

How it works

• New core phase phases/core/reply-drafts.md (briefing + consolidation) — runs after the connector scans and the action-items list, verifies the debt is real (reads the thread tail, applies the cold-outreach / leave-state filters), then writes one drafts/<TAG>.md per loop and ensures a matching action-item row with a (reply drafted → [[drafts/<TAG>]]) pointer.
• drafts/<TAG>.md frontmatter is the contract the app + /scout-work key on: tag, channel, loop_type, to, thread_ref, subject, status, created, context_answer_ref. Status vocabulary is draft | sent | dismissed.
• templates/drafts/README.md.tmpl documents the contract and is seeded into the vault; drafts/ + drafts/archive/ are scaffolded on install.
• /scout-work gains a Reply item type: it shows the full drafted text and accepts sent / edit: … / dismiss / skip. It never calls a send tool.

Hard constraint

Scout only ever writes draft text and flips status:. No sending, no native drafts — that stays the user’s action.

Tests

• Assembly: the phase lands in SKILL.md (briefing + consolidation), after action-items, and is excluded from DREAMING.md / RESEARCH.md.
• Bootstrap: drafts/ + drafts/archive/ + drafts/README.md are scaffolded on install.
• Full unit suite green (864 passed).

Companion

Paired with the macOS app PR (Raven-Scout/Scout) that adds a Reply Drafts section rendering these files and flipping their status.

[jordanrburger]

Review — reply-drafts

Strong feature — the never-send constraint is enforced consistently (phase + both commands + anti-patterns + tests) and the verify-before-draft gate is genuinely rigorous. Two things I'd resolve before merge, plus a lockfile and a cross-PR note. Most of this surfaced diffing against a real (mature) vault, not from the diff alone.

🔴 Anonymization leak (inline on scout-reply.md). Real bank names (SLSP = Slovenská sporiteľňa, ČSAS = Česká spořitelna), the employer name, and real-person-shaped client names with Slovak subject text, in a public-repo command file. Needs stand-ins per the repo's anonymization rule — see inline.

🔴 drafts/ collides with existing vaults. drafts/ is not an established engine path (nothing on main references it), but a mature vault already uses drafts/ as a free-form drafting workspace — long-form proposals, weekly updates, PR reviews, long replies, none using this PR's tag/channel/status frontmatter. This PR claims the folder as its <TAG>.md namespace and seeds a drafts/README.md that declares "This directory holds prepared reply drafts," which mischaracterizes it. No data loss — the Step 0 archive bash only moves sent/dismissed files, so no-frontmatter files are skipped — but /scout-reply and /scout-work would scan a folder mixing two different "drafts" notions, and the README is wrong for it. Suggest namespacing the feature (reply-drafts/ or drafts/replies/), or making rollout aware of an existing drafts/. This is the "facet built greenfield, deployed onto a mature vault" pattern — captured in #178.

🟡 uv.lock (933 lines) looks unrelated. It's new (not on main) with no pyproject.toml change behind it — ~65% of the diff. Looks accidental, or like a first-time lockfile commit; either way it belongs in its own infra PR rather than riding in a feature PR.

🟡 Cross-PR with #176. Both PRs edit the same _INSTALL_ONLY_TEMPLATES and _CAT1_DIR_LAYOUT tuples → merge conflict for whichever lands second. And on main, upgrade() calls neither _stage_create_dirs nor _stage_install_only_seeds, so on an existing vault /scout-update assembles the phase but does not seed drafts/README.md or pre-create drafts/archive/. The feature depends on #176's upgrade-replay to fully reach existing vaults.

🟡 Autonomy surface. /scout-reply is the first place Scout gains a real send path — slack_send_message + Gmail create_draft. It's well-gated (interactive only, explicit ask, confirm recipient; autonomous runs never send; /scout-work's Reply variant is hard-no-send), but it's a real expansion worth conscious sign-off given how much weight the escalate-vs-handle contract carries.

✓ Verified correct: assembly routing (mode: [briefing, consolidation] → SKILL only, after action-items, excluded from DREAMING/RESEARCH); bootstrap wiring is correct (README in _INSTALL_ONLY_TEMPLATES, drafts/archive in the dir layout); both CLI deps exist (action-items new-prefix, parser name_lookup); 19/19 changed-area tests pass; the Step 0 archive bash is safe on no-status files.

The leak and the greenfield-drafts/ assumption are both the back-port-hygiene gap we're already discussing on #176/#178 — a standardized scrub + mature-vault-diff step in the back-port procedure would have caught both.

[jordanrburger]

Real-world identifiers on a public surface. SLSP (Slovenská sporiteľňa) and ČSAS (Česká spořitelna) are real banks; combined with the employer name, real-person-shaped names, and Slovak subject text, this reads as lifted vault data rather than an example. Same on line 33 (/scout-reply SLSP).

Per the repo's CLAUDE.md anonymization rule (and the "no vault content on public surfaces" principle), these need stand-ins — the way templates/drafts/README.md.tmpl already does it (Jan Novák <jan@firma.cz>, Rozpočet Q3). Suggest: neutral names (Alex / Priya), a generic vendor noun instead of a named bank, and PROJ-####-style tags.