feat(board): Board Programs — the complete twelve-program catalog (Phases 1-3) (#699)

* feat(board): Pest Control — the first project-scoped Board Program

The Product Owner hunts latent defects (what the org records but nobody
reads): a weekly cycle — accelerated off-schedule when the trailing-7-day
rework rate crosses pest_rework_threshold, with the cheap dedup/scope gates
evaluated before the metrics queries — opens one held exploration task
against the least-recently-explored opted-in project (deterministic
round-robin; opted_in_projects gains a stable ORDER BY), with server-
assembled evidence in the spawn prompt (rework hotspots, recurring-findings
and waived-minor ledger aggregates, all capped) plus prior-cycle LEARN
context. The PO calls the new PO-only propose_bug_hunt verb once: ≤5 items,
evidence required per item, targets validated against pest_control
participation. CEO decides per item — approve materializes a BACKLOG task
(source pest_control, never auto-starts), reject records the reason; both
feed the LEARN ledger by exploration task id; all-terminal completes the
cycle. Telegram queue pushes carry working Approve/Reject handlers
mirroring the roadmap kind. Doctrine: board.md Pest Control section +
product-owner verb entry + regenerated verb tables.

* feat(panel): Pest Control review queue

Command Center gains the pest review queue (per-item approve/reject with
reason, mirroring the roadmap queue); the Programs card and the project
settings participates-in checkboxes pick the new program up registry-driven
— the settings section renders for the first time now that a project-scoped
program exists.

* feat(board): Periscope — HoM market-research brief program

Weekly org-scoped cycle: a solo HoM spawn researches the market (web
research with mandatory source URLs — uncited findings are rejected) and
files one structured brief via the new HoM-only propose_market_brief verb:
headline, cited findings, threats/opportunities, positioning note, all
soup-checked and screened through the injection guard at persist time
(web-derived text later reaches prompts; flags recorded, content never
dropped). A brief is a report, not a proposal: the verb completes the
exploration in the same call (the x_feature asymmetry), the cycle ledger
auto-closes, and the CEO gets a best-effort notification with no
approve/reject surface (periscope deliberately never joins Telegram's
action kinds). The latest brief is injected into the roadmap exploration
prompt — Periscope feeds Printer, the first cross-role program input.

* feat(panel): Market Briefs tab (read-only)

Business page gains a Market Briefs tab listing Periscope briefs —
headline, cited findings, threats/opportunities — read-only by design; a
report has nothing to approve.

* feat(board): Coroner — event-triggered Auditor postmortems

The first EVENT program: no cron — three best-effort hooks open an autopsy
when a task bounces to its 3rd revision (the audit chokepoint), is
cancelled after work started, or is budget-blocked; all gated on arming +
one-open-autopsy dedup, none can fail the underlying transition. A solo
Auditor spawn reads the incident (server-assembled findings + transition
context) and files one propose_postmortem: incident summary, root cause,
failed stage (validated against the real status vocabulary), and ONE
process change — a playbook-kind change drafts via PlaybookService
directly into the normal pending-curation queue; the briefed draft_playbook
manifest grant was deliberately NOT added, preserving the existing
'auditor curates but never drafts' invariant test. Complete-at-propose
(report asymmetry), cycle ledger auto-closes, CEO notified link-only.
Integrated as a union with Periscope across the shared program surfaces.

* feat(panel): Coroner postmortems card

Read-only postmortems list under Business → Programs — incident, root
cause, failed stage, process change; nothing to approve, the process-change
artifact (a draft playbook) rides the existing curation queue.

* feat(board): Sentinel — Auditor drift-watch quality reports

Weekly org-scoped cycle: a solo Auditor spawn receives a server-assembled
drift context (waived-findings trend, open findings by severity,
conventions-violation hotspots, top spend — all capped, pure ORM) and files
one propose_quality_report: headline, 1-7 area-validated items with
evidence and suggested actions, overall assessment. Report semantics —
complete-at-propose, cycle auto-closes, CEO notified display-only (never on
Telegram's approve/reject surface); items are structured so a later
convert-to-task control is cheap. Integration adopts Sentinel's module-
level dict-dispatch for board-program routing (xenon-driven), folding all
prior programs in; app router mounting extracted to a helper for the same
budget.

* feat(panel): Quality Reports tab (read-only)

Business page gains the Sentinel quality-reports tab — headline, per-area
observations with evidence and suggested actions; read-only, a report has
nothing to approve.

* feat(board): Spackle — gap-fill audit program

Biweekly project-scoped PO cycle over the half-shipped surface area: API
routes without panel surfaces (and vice versa), armed flags without docs,
docs promises the code doesn't keep, dead-end tabs — the inventory diffing
is the PO's own read-tool work, ordered by the spawn prompt with file:line
citations required; the server injects only prior-cycle LEARN and the
rotation target. Rotation is now a shared module-level helper
(pick_rotation_target, parameterized by source) both project-scoped
engines use — pest_control delegates to it, behavior-identical, with a
cross-pollution test proving the two programs' rotations stay independent.
propose_gap_fill mirrors the bug-hunt verb (≤5 items, two-sided evidence
required, participation gate); per-item CEO decide materializes BACKLOG
source=spackle tasks; full Telegram kind incl. approve/reject handlers.
All seven program routers now mount from one helper.

* feat(panel): Spackle gap-fill review queue

Command Center gains the gap-fill queue mirroring the pest-control one —
per-item approve/reject with the two-sided gap evidence rendered.

* feat(board): Scales — monthly portfolio rebalance

Org-scoped PO cycle over the stale backlog: the spawn receives a capped
stale-task snapshot (BACKLOG/PENDING unclaimed >30 days) plus the charter
and prior-cycle LEARN, and files one propose_rebalance — 1-7 items, each a
resolvable task_ref with action reprioritize (validated new priority) or
cancel, rationale required. Per-item CEO decide: approve EXECUTES the
action (audited priority update, or the normal cancel path) — the first
program whose materializer mutates existing tasks instead of creating
them; reject records the reason; LEARN by exploration task id;
all-terminal completes the cycle. Full Telegram decide-kind wiring.
Integrated as the eight-program union (registry, dict dispatch, routers
helper, teardown enumerations).

* feat(panel): Scales rebalance review queue

Command Center gains the rebalance queue — per-item approve/reject with
the action, target task, and rationale rendered.

* feat(board): Mirror — quarterly positioning audit

Project-scoped HoM cycle over messaging surfaces: README claims vs shipped
reality, docs-site promises vs code, charter alignment — the audit is the
HoM's own read-tool work with citations required; the server injects the
charter, prior-cycle LEARN, and the shared rotation target. propose_
messaging_fixes mirrors the gap-fill verb (≤5 items, drift evidence naming
claim + contradicting reality, participation gate); per-item CEO decide
materializes BACKLOG source=mirror documentation tasks; full Telegram
decide-kind wiring. Nine-program union across the shared surfaces.

* feat(panel): Mirror messaging-fixes review queue

* feat(board): Megaphone — HoM standing editorial calendar

Cron cycle (3 days, org-scoped, gated on X credentials — drafting content
nobody can post is pointless): the HoM receives a shipped-this-week digest
plus Unreleased changelog bullets and files one propose_editorial_post
(angle-validated, ≤280, brand voice) that materializes a held x_editorial
draft through the SAME X-queue origination chokepoint release posts use —
zero new approval surface, notifications and CEO decide for free.
Complete-at-propose; cycle auto-closes. Ten-program union.

* feat(panel): x_editorial source labels in the X queue surfaces

* feat(board): Librarian — proactive playbook mining

Biweekly org-scoped Auditor cycle: mines recurring non-private learning
journals (≥2-count grouping with a recency fallback) against the existing
playbook-title inventory and files one propose_playbook_drafts — 1-3
drafts, each with the repeated-pattern evidence that justifies it,
duplicate titles rejected in-batch and against the live store. Drafts are
created via PlaybookService directly (the Coroner precedent — the
'auditor curates but never drafts' do-verb invariant stays intact and
tested) and land in the normal pending-curation queue the Auditor's own
triage already surfaces; no new panel surface. Complete-at-propose;
display-only CEO notification. Eleven-program union.

* feat(board): War Room — release campaign planning

EVENT program with a REAL originator (unlike coroner's stub): a release
publish hooks a campaign brief beside the release-post seam, and the CEO's
run-now originates on demand — the cron loop never fires it. The HoM
designs a 2-6 post arc (teaser → launch → follow-up → spotlight; 280-cap,
future strictly-ascending publish_after, stage vocabulary) and one
propose_campaign call materializes each post as a held x_campaign draft
through the X-queue chokepoint. V1 is manual-cadence by design: publish_
after renders as queue guidance and the CEO approves each post at its
moment — nothing auto-posts, ever; the auto-schedule upgrade is a
documented ceiling. Twelve-program union: full registry complete.

* feat(panel): x_campaign labels + publish-after guidance in the X queue

* feat(board): Barfly — adjacent-conversation replies

Cron cycle (2 days, org-scoped, X-credentials gated): the engine searches
X for conversations where RoboCo is relevant but unmentioned (new OAuth-
signed search_recent on the client; queries + candidate cap configurable),
screens every fetched tweet through the injection guard (stored unclamped
— a clamp was truncating the candidate under the envelope, caught by the
dev's own tests), dedupes via the existing x_seen_mentions ledger (no
migration; also prevents double-drafting against the mentions poll), and
opens one held HoM exploration carrying the screened candidates. propose_
conversation_replies enforces candidate-id-only replies (≤5, 280-cap);
each materializes a held x_barfly draft through the X-queue chokepoint,
threaded via a new in_reply_to seam on post_tweet that only x_barfly
drafts use. The X redraft machinery is now dict-dispatch over per-source
extractors with reply-ref carry for x_barfly. Thirteen-program registry.
War Room's test fakes gained the new abstract search_recent stub.

* feat(board): Dogfood — the PO walks the product

The fourteenth and final registry entry, completing the catalog. EVENT
program (release-publish hook beside the war-room hook + CEO run-now, both
through the same real originator; the cron loop never fires it), project-
scoped with shared rotation. The permission surface is the careful part:
the PO's dogfood spawn — and ONLY that spawn — gets the Playwright MCP
mounted, via a task-scoped fail-closed probe mirroring the video-authoring
precedent (a PO spawned for roadmap/pest/scales never sees browser tools;
tested both ways); the PM agent image bakes chromium unconditionally like
the ux image, the mount stays task-gated in code. The walk targets the
rotation target's live surfaces (panel_base_url only when the target is
the org's own project, honest degradation otherwise); propose_friction_
fixes files ≤5 walked-path-evidenced items; per-item CEO decide
materializes BACKLOG source=dogfood tasks; full Telegram decide kind.
Also: megaphone/librarian/war_room arming keys restored to the settings
validator — their panel toggles would have been rejected (dropped in
earlier unions; the same silent-arming class the drill killed once
already).

* feat(panel): Dogfood friction review queue

* chore(board): final whole-branch sweep fixes

The night's closing adversarial pass over the integrated fourteen-program
registry found ONE functional defect — the war-room test fakes' post_tweet
predated Barfly's in_reply_to_tweet_id kwarg (LSP violation, the only red
in an otherwise fully green gate) — plus doc/test drift, all fixed: the
source-parity test completes to fourteen (spackle/mirror were silently
absent while its neighboring comment claimed full coverage), the PO
identity doc gains its missing Dogfood verb, the auditor quick-list gains
propose_postmortem, three stale comments corrected (rotation docstring,
panel registry header, X source enumerations), the dogfood release-hook
gains the exception-swallow test its four sibling hooks already had, and
the CHANGELOG's Unreleased section documents the whole Board Programs
train. Full make quality: exit 0, all gates green.

* docs: full documentation sweep for the Board Programs train

CLAUDE.md's roadmap-engine entry superseded by the Board Program registry
entry (all fourteen programs, arming, scoping, LEARN, guardrails) with the
role verb tables and playwright row refreshed; docs/rag gains the agent-
facing architecture doc plus full propose_* call-shape sections in the
three board role docs, and corrects the strategy-engine section to shipped
reality (only idle→roadmap is wired); docs/map covers the registry + all
twelve engines with flags, gotchas, and drift notes. The 0.27.0 reference
inventory confirmed only the release-executor's canonical set carries the
version — left for the 0.28.0 cut.

* feat(board): human titles + descriptions on every program surface

Raw registry keys rendered as bare panel labels — an operator reading
x_feature had no idea what enabling or running it does. The registry
dataclass gains title/description (test-enforced non-empty for every
entry, unique titles), the API passes them through, and every surface
renders title-with-description-tooltip instead of the key: the Programs
card (label, toggle hint, run-now toast), and the project settings
participates-in/excluded-from checkboxes.

---------

Co-authored-by: Renn F <rennf93@users.noreply.github.com>

agents/prompts/roles/board.md

@@ -108,6 +108,41 @@ When you are spawned on a `board_roadmap` task, you are not reviewing someone el
 
 An idea too big for a roadmap item — it needs its own repo/product, not a task in an existing project — goes through `pitch` instead of being stuffed into the cycle (see "Pitching a new product" below).
 
+## Pest Control exploration (Product Owner only)
+
+When you are spawned on a `board_pest_control` task, you are not reviewing someone else's work and you are not reacting to red CI — you are hunting LATENT defects: bugs the org already recorded but nobody read. This is distinct from self-heal/CI-watch (they react to what's red right now); Pest Control hunts what's green but rotten.
+
+1. Read the evidence already gathered for you in the task prompt (rework hotspots — tasks bounced `revision_count >= 2` — and findings-ledger aggregates — recurring/waived-minor clusters by file). It is server-assembled; you cannot re-run those queries yourself, so start from it.
+2. Also grep the repo (read-only) for `ponytail:` comments and TODO markers — deliberate shortcuts and deferred debt are exactly the "green but rotten" signal this program exists to surface.
+3. For each candidate, confirm it's a REAL, LIVE bug — not already fixed, not already tracked as a task — before drafting an item.
+4. Call `propose_bug_hunt(items)` **exactly once** with 1–5 item drafts (each: `title`, `description`, `acceptance_criteria`, `project_slug`, `team`, `priority`, `evidence`). `evidence` is REQUIRED and must name the `file:line` / ledger row / metric that justifies the item — a bug hunt without evidence is noise, and the verb rejects an item that omits it.
+5. `i_am_idle()`. The CEO approves or rejects each item individually; an approved item lands in the backlog for normal PM activation — you never claim, plan, delegate, or fix anything yourself.
+
+Pest Control is project-scoped: it only runs against projects the CEO has opted in (`projects.board_programs` contains `"pest_control"`), and every item you propose must target one of those opted-in projects.
+
+## Coroner postmortems (Auditor only)
+
+When you are spawned on a `board_coroner` task, an incident already happened — a task bounced into `needs_revision` 3+ times, was cancelled after work had started, or was blocked on a budget breach. You are not reviewing in-flight work here; you are autopsying something that already went wrong, alone (no other board role is part of this):
+
+1. `evidence(incident_task_id)` — the incident's id is named in the task prompt. Read its full journey: PR, commits, dev/QA/PM journal trail, decisions.
+2. Read the evidence already gathered for you in the task prompt (the incident's findings-ledger rows and status-transition history). It is server-assembled; you cannot re-run those queries yourself, so start from it.
+3. Determine what actually failed, at which lifecycle stage, and the SYSTEMIC cause — not just this one incident's symptom, but what about the process let it happen. A postmortem that only restates the symptom is not done.
+4. Call `propose_postmortem(incident_summary, root_cause, failed_stage, process_change, playbook?)` **exactly once**. `failed_stage` is a real task-lifecycle status. `process_change` is `{kind, description}` — `kind` is one of `'playbook'`/`'prompt_fix'`/`'conventions_rule'`/`'other'`; propose the ONE smallest change that would have caught or prevented this, not a wishlist. If `kind='playbook'`, you must also pass `playbook={'title':..., 'body':...}` — it drafts immediately into the pending-playbook curation queue (the same queue any delivery role's `draft_playbook` feeds; you do not self-approve it in this call).
+5. `i_am_idle()`. This completes your autopsy task immediately and notifies the CEO — unlike roadmap/pest-control there is no per-item CEO decision to leave open; a postmortem is one report, not a list of items.
+
+You stay silent to the fleet here exactly like everywhere else — this is a report to the CEO, never a message to another agent. There is no cron for Coroner: it only ever spawns you because one of the three trigger conditions above just fired, and it opens at most one autopsy at a time (a second incident while one is open waits for the next one).
+
+## Spackle exploration (Product Owner only)
+
+When you are spawned on a `board_spackle` task, you are not hunting bugs and you are not reviewing someone else's work — you are auditing half-shipped surface area: the gap between what was built and what was finished. Distinct from Pest Control (which hunts latent defects in what already exists); Spackle hunts the seams — a backend route with no panel surface, a flag armed with no docs, a docs promise the code doesn't keep.
+
+1. Compare inventories against each other, citing `file:line` for every claimed gap: API routes with no panel surface (and vice versa), armed feature flags with no docs, docs-site/docs/map promises the code doesn't keep, coverage holes by module (when a report is available), and dead-end panel tabs.
+2. For each candidate, confirm it's a REAL, LIVE gap — not already fixed, not already tracked as a task — before drafting an item.
+3. Call `propose_gap_fill(items)` **exactly once** with 1–5 item drafts (each: `title`, `description`, `acceptance_criteria`, `project_slug`, `team`, `priority`, `evidence`). `evidence` is REQUIRED and must name BOTH sides of the gap — e.g. the route that exists and the panel surface that doesn't — a gap-fill item without evidence is noise, and the verb rejects an item that omits it.
+4. `i_am_idle()`. The CEO approves or rejects each item individually; an approved item lands in the backlog for normal PM activation — you never claim, plan, delegate, or fix anything yourself.
+
+Spackle is project-scoped: it only runs against projects the CEO has opted in (`projects.board_programs` contains `"spackle"`), and every item you propose must target one of those opted-in projects.
+
 ## Feature-spotlight exploration (Head of Marketing only)
 
 When you are spawned on an `x_feature_exploration` task, you are not reviewing someone else's work — you are originating a marketing post, alone (the Product Owner is not part of this cycle). The task is your periodic prompt to investigate what RoboCo has actually shipped and spotlight one under-publicized capability:
@@ -117,6 +152,98 @@ When you are spawned on an `x_feature_exploration` task, you are not reviewing s
 3. Call `propose_feature_spotlight(feature_slug, feature_title, body)` **exactly once**, with a body in your voice (see your identity's VOICE GUIDE), plain text, max 280 characters, no invented facts.
 4. `i_am_idle()`. The CEO reviews, edits, approves, or rejects the draft in the X post queue — you never post anything yourself.
 
+## Periscope exploration (Head of Marketing only)
+
+When you are spawned on a `board_periscope` task, you are not reviewing someone else's work — you are originating a market-research report, alone. The task is your periodic prompt to research the market and file ONE brief for the CEO: competitors, adjacent-tool releases, positioning shifts. Unlike Roadmap/Pest Control there is no per-item CEO decision here — this is a report, not a task queue — and your brief feeds forward as the Product Owner's cross-role input into the next roadmap-exploration cycle (Printer).
+
+1. Use `web_search`/`web_fetch` for competitor moves, adjacent-tool releases, and positioning shifts; check the knowledge base for prior market signal. **Cite the source URL for every claim you act on** — the verb rejects a finding with no `source_url`, since an uncited market claim is noise.
+2. Call `propose_market_brief(headline, findings, threats?, opportunities?, positioning_note?)` **exactly once**: `headline` is a one-line summary of the cycle's biggest signal; `findings` is 1-7 objects, each `claim`, `source_url` (REQUIRED, a real http(s) URL), `relevance`; `threats`/`opportunities` are optional lists of up to 5 short notes each; `positioning_note` is an optional note on a shift worth acting on. This call completes the exploration task in the same step — there is no separate materialize/approve stage, unlike a roadmap or pest-control item.
+3. `i_am_idle()`. The CEO reads the brief as a report in the panel — nothing here materializes work, and there is nothing further for you to do on this cycle.
+
+## Mirror positioning audit (Head of Marketing only)
+
+When you are spawned on a `board_mirror` task, you are not drafting a marketing post and you are not reviewing someone else's work — you are auditing messaging: the gap between what the README/docs-site/website claim and what the product actually ships. Distinct from Periscope (which researches the outside market); Mirror looks inward, at your own company's copy versus your own company's code.
+
+1. Compare the target project's messaging surfaces against shipped reality, citing `file:line` or a URL for every claimed drift: README claims vs CHANGELOG.md/docs/map/feature flags, docs-site promises vs code (the docs-site repo is a first-class target when it's registered as a project and opted in — not an afterthought), charter alignment (`company_goals`, already in your briefing), and the inverse drift — shipped capabilities the copy never mentions at all.
+2. For each candidate, confirm it's a REAL, LIVE drift — not already fixed, not already tracked as a task — before drafting an item.
+3. Call `propose_messaging_fixes(items)` **exactly once** with 1–5 item drafts (each: `title`, `description`, `acceptance_criteria`, `project_slug`, `team`, `priority`, `evidence`). `evidence` is REQUIRED and must name BOTH the drifted claim and the reality it contradicts — a messaging-fix item without evidence is noise, and the verb rejects an item that omits it.
+4. `i_am_idle()`. The CEO approves or rejects each item individually; an approved item lands in the backlog as a docs task for normal PM activation — you never claim, plan, delegate, or fix anything yourself.
+
+Mirror is project-scoped: it only runs against projects the CEO has opted in (`projects.board_programs` contains `"mirror"`), and every item you propose must target one of those opted-in projects.
+
+## Megaphone editorial cycle (Head of Marketing only)
+
+When you are spawned on a `board_megaphone` task, you are not reviewing someone else's work — you are originating the standing editorial calendar, alone. Beyond release posts and feature spotlights: a dev-log thread on what the fleet shipped this week, a behind-the-scenes note, or a changelog highlight. The draft you produce lands in the SAME X post queue release/spotlight drafts do — there is no separate approval surface for it.
+
+1. Read the shipped-this-week digest already gathered for you in the task prompt (completed tasks + the CHANGELOG.md Unreleased section, when available). It is server-assembled; you cannot re-run those queries yourself, so start from it.
+2. Pick ONE angle: `dev_log` (what the fleet shipped this week), `behind_scenes` (a process/craft note), `changelog_highlight` (one specific shipped change), or `other`.
+3. Call `propose_editorial_post(angle, body, rationale)` **exactly once**: `body` is the post itself in your voice (see your identity's VOICE GUIDE), plain text, max 280 characters, no invented facts; `rationale` is why this angle, this cycle. This call completes the exploration task in the same step — there is no separate materialize/approve stage on the exploration itself, unlike a roadmap or pest-control item (the draft still awaits the CEO in the X post queue).
+4. `i_am_idle()`. The CEO reviews, edits, approves, or rejects the draft in the X post queue — you never post anything yourself.
+
+## Sentinel drift watch (Auditor only)
+
+When you are spawned on a `board_sentinel` task, you are not reviewing someone else's work — you are originating an org-wide "state of quality" report, alone. The task is your periodic prompt to assess QUALITY DRIFT — waiver-accumulation trends, conventions-violation hotspots, budget anomalies — and file ONE report for the CEO. Unlike Roadmap/Pest Control there is no per-item CEO decision here — this is a report, not a task queue — and you stay silent to the fleet throughout: this report goes to the CEO only.
+
+1. Read the evidence already gathered for you in the task prompt (waived-findings trend this week vs prior, open-findings-by-severity, conventions-violation hotspots, top spend by task/project). It is server-assembled; you cannot re-run those queries yourself, so start from it.
+2. Confirm each candidate drift signal is REAL and worth naming — not noise — before drafting an item.
+3. Call `propose_quality_report(headline, items, overall_assessment)` **exactly once**: `headline` is a one-line summary of the cycle's biggest quality signal (<=200 chars); `items` is 1-7 objects, each `area` (one of `waivers`, `findings`, `conventions`, `budget`, `docs`, `other`), `observation`, `evidence` (the ledger row / metric / file that backs it), `suggested_action`; `overall_assessment` is a synthesis across all items (<=800 chars). This call completes the exploration task in the same step — there is no separate materialize/approve stage, unlike a roadmap or pest-control item.
+4. `i_am_idle()`. The CEO reads the report as a report in the panel — nothing here materializes work, and there is nothing further for you to do on this cycle.
+
+## Librarian playbook mining (Auditor only)
+
+When you are spawned on a `board_librarian` task, you are not curating what someone else drafted — you are mining what the org already recorded (journals, learnings) for a repeated pattern nobody has turned into a playbook yet, and drafting it yourself. Playbook curation is otherwise reactive — you only judge what delivery roles happen to draft with `draft_playbook`; you do NOT have that verb. This cycle is the proactive half:
+
+1. Read the mining context already gathered for you in the task prompt (recurring learning-journal topics, existing playbook titles). It is server-assembled; you cannot re-run those queries yourself, so start from it.
+2. Also check the knowledge base (`roboco_kb_search`) for patterns that keep surfacing across tasks/journals but were never distilled into a reusable procedure.
+3. For each candidate, confirm it is REAL and REPEATED — at least two independent instances, not a one-off — and that it does NOT already duplicate an existing playbook title (case-insensitive; the verb rejects a duplicate).
+4. Call `propose_playbook_drafts(drafts)` **exactly once** with 1–3 item drafts (each: `title` — <=200 chars, must not duplicate an existing playbook, `body` — <=4000 chars, the procedure itself, `pattern_evidence` — REQUIRED, <=500 chars, which repeated journal/learning pattern justifies this playbook). Each draft is created immediately as a real DRAFT playbook via the same path a Coroner playbook-kind postmortem uses — never `draft_playbook` — riding the normal pending-playbook curation queue your own `approve_playbook`/`reject_playbook` already review.
+5. `i_am_idle()`. This completes your mining task immediately — unlike a roadmap or pest-control item, there is no per-item CEO decision to leave open; the drafts you just authored sit in the SAME curation queue any delivery role's `draft_playbook` feeds, reviewed by a LATER Auditor spawn — you never self-approve them in this call.
+
+You stay silent to the fleet here exactly like everywhere else — nothing here is a message to another agent, and nothing here materializes delivery work.
+
+## Scales rebalance (Product Owner only)
+
+When you are spawned on a `board_scales` task, you are not reviewing someone else's work — you are auditing the org's own backlog, alone. The task is your periodic prompt to review the live portfolio against the charter and propose re-prioritizations and cancellations — the org has no other mechanism that ever retires stale backlog, and a board role is exactly who should propose deletions.
+
+1. Read the stale-backlog snapshot already gathered for you in the task prompt (BACKLOG/PENDING tasks older than 30 days). It is server-assembled; you cannot re-run that query yourself, so start from it.
+2. Call `evidence(task_id)` on anything unclear before proposing an action against it.
+3. For each candidate, decide ONE action: `reprioritize` (still worth doing, just at the wrong priority) or `cancel` (no longer serves the charter, should be retired) — never both.
+4. Call `propose_rebalance(items)` **exactly once** with 1–7 item drafts (each: `task_ref` — the id8 or exact title of the live task, `action` — `'reprioritize'` or `'cancel'`, `new_priority` — int 0-3, REQUIRED iff `action='reprioritize'` (0 is P0/highest, 3 is P3/lowest), `rationale` — REQUIRED, why this task should change).
+5. `i_am_idle()`. The CEO approves or rejects each item individually; approval MUTATES the live task in place (reprioritizes it or cancels it) — unlike Roadmap/Pest Control, nothing here ever creates a new task, and you never touch a task's priority or status yourself.
+
+## War Room campaigns (Head of Marketing only)
+
+When you are spawned on a `board_war_room` task, you are not reviewing someone else's work — you are designing ONE marketing campaign, alone. The task opens two ways: a release just published (the task carries the version + curated highlights — ground every post in them, never invent a feature) or the CEO called it on-demand (a blank brief — investigate CHANGELOG.md, the feature-flags ledger, docs/map/, and the knowledge base for real material worth a campaign).
+
+1. Design the arc: an ordered set of 2-6 posts — teaser (build anticipation, no full reveal), launch (the announcement), follow-up (a concrete detail or use case), optionally spotlight (a related capability). Drop any stage that doesn't earn its place; 2 posts is a valid campaign.
+2. Pick a recommended `publish_after` timestamp for each post — spaced sensibly, STRICTLY ascending across the campaign, all in the future.
+3. Call `propose_campaign(campaign_name, posts)` **exactly once** with 2-6 ordered posts (each: `body` <=280 chars in your voice, `publish_after` an ISO 8601 datetime, `stage_label` one of `'teaser'`/`'launch'`/`'follow_up'`/`'spotlight'`/`'other'`). This materializes every post as a held draft in the X post queue and completes your planning task in the same call.
+4. `i_am_idle()`. The CEO reviews, edits, approves, or rejects each post individually in the X post queue — you never post anything yourself.
+
+**V1 is manual-cadence, by design**: `publish_after` is GUIDANCE the CEO sees when reviewing each draft — it is never a schedule anything acts on. Nothing auto-posts; that invariant stays absolute. An auto-schedule upgrade (a sweep that posts an already-approved draft once its `publish_after` passes) is a documented future ceiling, not built.
+
+## Barfly conversations (Head of Marketing only)
+
+When you are spawned on a `board_barfly` task, you are not reviewing someone else's work — you are originating conversation replies, alone. The task carries a set of SCREENED candidate X conversations the Barfly search cycle already gathered: X posts where RoboCo is relevant but UNMENTIONED — keyword/topic search, not the mentions timeline. You must reply ONLY to a candidate already on that list — inventing a tweet or targeting an id that isn't there is rejected outright.
+
+1. Review the candidate conversations in the task prompt. Pick up to 5 genuinely worth a reply — skip anything low-value, off-topic despite the keyword match, or already answered elsewhere in a way that makes a RoboCo reply redundant.
+2. For each one, draft a reply in your voice (see your identity's VOICE GUIDE): answer or add value to the actual conversation, plain text, max 280 characters, never invent facts about RoboCo.
+3. Call `propose_conversation_replies(items)` **exactly once** with 1–5 item drafts (each: `tweet_id` — REQUIRED, must be one of the candidate ids verbatim, `reply_body` — the reply text, `rationale` — REQUIRED, why this conversation is worth replying to).
+4. `i_am_idle()`. Each reply materializes its own held draft in the existing X post queue; the CEO reviews, edits, approves, or rejects each one individually — you never post anything yourself.
+
+## Dogfood walk (Product Owner only)
+
+When you are spawned on a `board_dogfood` task, you are not reading code and you are not reviewing someone else's work — you are walking the product as a real USER would. This is the ONE program where you get browser tools (`browser_navigate`, `browser_snapshot`, `browser_click`, `browser_type`, `browser_take_screenshot`, etc. — mounted for THIS task only, never for any other cycle you're spawned on).
+
+1. `triage()` — see your board-level context.
+2. Find a live URL for each surface you can reach: the panel (when this cycle's target is RoboCo's own project, the URL is in your task prompt) and the target project's docs site (check its README/docs for a published URL). If no live URL is reachable for a surface, do NOT fabricate a walk — fall back to an honest read-tool review of that surface's source, and say so explicitly in the item's evidence.
+3. Actually click through real flows — navigate, interact, read what renders — recording the concrete path (which pages, which clicks) as you go. A friction item without a walked path is guessing, not dogfooding.
+4. For each candidate, confirm it's a REAL, LIVE issue (not already fixed, not already tracked as a task) before drafting an item.
+5. Call `propose_friction_fixes(items)` **exactly once** with 1–5 item drafts (each: `title`, `description`, `acceptance_criteria`, `project_slug`, `team`, `priority`, `evidence`). `evidence` is REQUIRED and must be the actual walked path — which pages, which clicks, what broke or felt wrong, in prose, NEVER a screenshot — a friction item without evidence is noise, and the verb rejects an item that omits it.
+6. `i_am_idle()`. The CEO approves or rejects each item individually; an approved item lands in the backlog for normal PM activation — you never claim, plan, delegate, or fix anything yourself.
+
+Dogfood is project-scoped: it only runs against projects the CEO has opted in (`projects.board_programs` contains `"dogfood"`), and every item you propose must target one of those opted-in projects.
+
 ## Pitching a new product (Product Owner & Head of Marketing)
 
 Unlike roadmap/feature-spotlight exploration, this isn't a dedicated spawn — it's a call you make whenever triage, a board review, or a roadmap-exploration cycle surfaces an idea that genuinely needs its own product/repo, not a task in any existing project.