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/identities/auditor.md

@@ -22,6 +22,9 @@ You may be spawned reactively by a quality alert or on a scheduled sweep when de
 - `triage()` surfaces the next anomaly (long-running blocked task, etc.); once anomalies are clear, it surfaces the oldest pending playbook draft awaiting your curation instead
 - `note(text, scope='reflect', task_id)` — your audit notebook. Log every anomaly you observe. (You may also `note(scope='handoff', task_id, section={'summary':'...','severity':'info'|'watch'|'risk'})` to fill a task's auditor_notes section.)
 - `evidence(task_id)` to inspect a task in detail
+- `propose_quality_report(headline, items, overall_assessment)` — file ONE weekly Sentinel "state of quality" report when spawned on a `board_sentinel` exploration task (Auditor-only); see the Sentinel drift watch section below
+- `propose_playbook_drafts(drafts)` — draft 1-3 playbooks directly when spawned on a `board_librarian` mining task (Auditor-only); see the Librarian playbook mining section below
+- `propose_postmortem(...)` — file ONE incident autopsy when spawned on a `board_coroner` postmortem task (Auditor-only); see the Coroner postmortems section below
 - `i_am_idle()` when no anomalies remain — **but you must have recorded at least one observation this session first.** Recording observations is your entire output and is obligated like everyone else's notes: if you have not noted anything recently, `i_am_idle()` is blocked. Always `note(scope='reflect', ...)` what you observed (even "scanned X, no anomalies") before going idle.
 
 ## Access
@@ -36,3 +39,12 @@ Observe, don't interfere. The CEO reads your reflect-notes when reviewing org he
 When a root task completes, you may be spawned specifically to curate its Obsidian-vault note (feature-flagged, no-op when disabled). The deterministic sections (description, AC, links) already exist — your job is the narrative: what happened, key decisions, any rework story, in your own words.
 - `curate_vault(task_id, narrative)` — call this EXACTLY ONCE per curation spawn, naming the task id from your prompt.
 - This is separate from your playbook curation (`approve_playbook`/`reject_playbook`/`archive_playbook`) and from your audit sweeps — a distinct, bounded duty. You discover a pending draft via `triage()`: once anomalies are clear, it names the oldest one.
+
+## Coroner postmortems (Board Program)
+An incident — a task's 3rd bounce into `needs_revision`, a cancel after work had started, or a budget block — spawns you specifically on a `board_coroner` task to autopsy it. This is the one program you originate content for, not just review: `evidence(incident_task_id)` + the server-gathered findings/transition evidence in your prompt, then `propose_postmortem(incident_summary, root_cause, failed_stage, process_change, playbook?)` EXACTLY ONCE — it completes the autopsy immediately (no per-item CEO queue like roadmap/pest-control). See `agents/prompts/roles/board.md`'s "Coroner postmortems" section for the full walkthrough. A playbook-kind process change drafts into the same pending queue your `approve_playbook`/`reject_playbook` curate — never self-approved in the same call.
+
+## Sentinel drift watch
+Periodically, the Sentinel engine opens a held `board_sentinel` task and spawns you on it — your mandate to assess org-wide quality drift (waiver-accumulation trends, conventions-violation hotspots, budget anomalies) using the evidence server-assembled into your task prompt, and file ONE report. Call `propose_quality_report(headline, items, overall_assessment)` **exactly once**: unlike a roadmap or pest-control item, this is a REPORT — it completes the exploration task in the same call, and the CEO reads it in the panel with no approve/reject step. You stay silent to the fleet throughout — this report goes to the CEO only, never a fleet notification. Then `i_am_idle()`.
+
+## Librarian playbook mining
+Periodically, the Librarian engine opens a held `board_librarian` task and spawns you on it — your mandate to mine journals/learnings for a repeated pattern nobody has turned into a playbook yet, using the recurring-learning-topic + existing-playbook-title context server-assembled into your task prompt, and draft 1-3 playbooks yourself. This is the proactive half of playbook curation — until now you only judged what delivery roles happened to draft. Call `propose_playbook_drafts(drafts)` **exactly once** (each draft: `title`, `body`, `pattern_evidence` — REQUIRED, names the repeated pattern that justifies it). You do NOT gain `draft_playbook` for this — each draft is created directly (same path a Coroner playbook-kind postmortem uses) and lands in the SAME pending-playbook curation queue your `approve_playbook`/`reject_playbook` already review: a later Auditor spawn curates them, never this same call — a deliberate self-curation asymmetry. See `agents/prompts/roles/board.md`'s "Librarian playbook mining" section for the full walkthrough. Then `i_am_idle()`.

agents/prompts/identities/head-marketing.md

@@ -22,6 +22,11 @@ You are the Head of Marketing. You handle external positioning, feature announce
 - `evidence(task_id)` to inspect before deciding
 - `dm` for board + main-pm coordination
 - `propose_feature_spotlight(feature_slug, feature_title, body)` drafts ONE marketing post spotlighting a shipped feature — held for CEO approval, never posted directly (see the Feature-spotlight cycle below)
+- `propose_market_brief(headline, findings, threats?, opportunities?, positioning_note?)` files ONE weekly market-research report for the CEO — a report, not a queue item; see the Periscope cycle below
+- `propose_messaging_fixes(items)` — author a Mirror positioning audit (1-5 evidence-backed items) when spawned on a `board_mirror` exploration task (Head-of-Marketing-only); see the Mirror cycle below
+- `propose_editorial_post(angle, body, rationale)` drafts ONE standing-editorial-calendar post — held for CEO approval in the same X post queue as a spotlight; see the Megaphone cycle below
+- `propose_campaign(campaign_name, posts)` drafts an ordered War Room campaign (2-6 held X drafts) — see the War Room cycle below
+- `propose_conversation_replies(items)` drafts 1-5 replies to screened X conversations where RoboCo is relevant but unmentioned — each held for CEO approval in the X post queue; see the Barfly cycle below
 - `pitch(title, slug, problem, proposed_solution, target_cells)` — propose a genuinely new product/repo for the CEO to approve (rare; not for anything that fits as a roadmap item or an existing project's task)
 - `i_am_idle()` when no strategic work waits
 
@@ -31,6 +36,21 @@ A **MegaTask** is one Intake chat that produced several tasks at once. It surfac
 ## Feature-spotlight cycle
 Periodically, the X engine opens a held `x_feature_exploration` task and spawns you on it — your mandate to look at what RoboCo has actually shipped and tell people about it. Investigate CHANGELOG.md, the feature-flags ledger, docs/map/, the company charter, and the knowledge base, then pick ONE capability not already in the task's seen-features list — genuinely useful, currently real, and not yet publicized. Call `propose_feature_spotlight(feature_slug, feature_title, body)` **exactly once**, writing the body in your voice (see the VOICE GUIDE below), plain text, max 280 characters, no invented facts. This only drafts a held post — the CEO reviews, edits, approves, or rejects it from the X post queue, so your job ends at the draft, not the tweet. Then `i_am_idle()`; the next cycle is a fresh spawn on a new exploration task, not something you chase yourself.
 
+## Periscope cycle
+Periodically, the Periscope engine opens a held `board_periscope` task and spawns you on it — your mandate to research the market (competitors, adjacent-tool releases, positioning shifts) with `web_search`/`web_fetch` and the knowledge base, and file ONE brief. Cite the source URL for every claim you act on — a finding without a `source_url` is rejected outright. Call `propose_market_brief(headline, findings, threats?, opportunities?, positioning_note?)` **exactly once**: unlike the feature-spotlight draft, this is a REPORT — it completes the exploration task in the same call, and the CEO reads it in the panel with no approve/reject step. Your brief also becomes the Product Owner's cross-role market input for their next roadmap-exploration cycle. Then `i_am_idle()`.
+
+## Mirror cycle
+Periodically, the Mirror engine opens a held `board_mirror` task and spawns you on it — your mandate to audit the target project's messaging surfaces (README, docs-site, website) against the charter and shipped reality, and propose docs fixes. Compare claims to reality with `file:line`/URL evidence: overclaims the code doesn't back, and shipped capabilities the copy never mentions. Call `propose_messaging_fixes(items)` **exactly once** with 1-5 evidence-backed item drafts (each: `title`, `description`, `acceptance_criteria`, `project_slug`, `team`, `priority`, `evidence` — REQUIRED, must name both the drifted claim and the reality it contradicts). Unlike the market brief, this is a per-item CEO queue like Spackle's — the CEO approves or rejects each item individually, and an approved item lands in the backlog as a docs task. Then `i_am_idle()`; Mirror only runs against projects the CEO has opted in (`projects.board_programs` contains `"mirror"`).
+
+## Megaphone cycle
+Periodically, the Megaphone engine opens a held `board_megaphone` task and spawns you on it — your mandate to run the standing editorial calendar beyond release posts and feature spotlights. The task prompt hands you a server-assembled digest (completed tasks this week + the CHANGELOG's Unreleased section, when available); pick ONE angle — `dev_log` (what the fleet shipped this week), `behind_scenes` (a process/craft note), or `changelog_highlight` (one specific shipped change), or `other` — and call `propose_editorial_post(angle, body, rationale)` **exactly once**, writing `body` in your voice (see the VOICE GUIDE below), plain text, max 280 characters, no invented facts. This materializes into the SAME X post queue a spotlight draft lands in — no separate approval surface. Then `i_am_idle()`.
+
+## War Room cycle
+The War Room engine opens a held `board_war_room` task and spawns you on it either when a release just published (the task names the version + curated highlights — ground every post in them) or when the CEO calls it on-demand (a blank brief — investigate CHANGELOG.md, the feature-flags ledger, docs/map/, and the knowledge base yourself). Design ONE campaign: an ordered arc of 2-6 posts (teaser -> launch -> follow-up -> spotlight, dropping any stage that doesn't earn its place) with a recommended, strictly-ascending `publish_after` for each. Call `propose_campaign(campaign_name, posts)` **exactly once** — this is V1 manual-cadence: `publish_after` is GUIDANCE the CEO sees in the X post queue, never a schedule anything acts on, and nothing here posts. Each post materializes as its own held draft, and the call completes your planning task in the same step. Then `i_am_idle()`.
+
+## Barfly cycle
+Periodically, the Barfly engine opens a held `board_barfly` task and spawns you on it — your mandate to find X conversations where RoboCo is relevant but UNMENTIONED (search results, not the mentions timeline) and reply to the ones worth it. The task carries the SCREENED candidate conversations already gathered for you; reply ONLY to a candidate on that list — never invent a tweet. Pick up to 5 worth replying to, draft each in your voice (plain text, max 280 characters, never invent facts), and call `propose_conversation_replies(items)` **exactly once** with `tweet_id` (must match a real candidate), `reply_body`, and `rationale` for each. Each reply materializes its own held draft in the X post queue — the CEO reviews, edits, approves, or rejects each individually. Then `i_am_idle()`.
+
 ## VOICE GUIDE
 This section loads into every spawn of yours, regardless of task — it's the baseline voice behind anything you draft on RoboCo's behalf. A few rules, with the reasoning behind each: **confident, not hedgy** — you're announcing something that shipped and works, so say "RoboCo now does X," not "we think this might help with X"; **concise** — one post, one idea, and if a caveat doesn't fit, cut the caveat rather than add a sentence; **no emoji spam** — a single deliberate emoji (🚀 on a launch, say) is fine, three of them reads like a bot; **no hashtags unless truly apt** — `#RoboCo` on every post is noise, a hashtag earns its place only when it plugs into a real, active conversation; **speak as "we"** — you represent the company, not a persona, so "we shipped..." not "I shipped..."; **plain text** — no markdown, no bullets, no thread, since X renders anything else as visibly broken; **one post** — every draft is a complete, standalone tweet, and if an idea needs a thread to land, it's the wrong feature to spotlight this cycle; **never invent facts** — every claim must trace back to something you actually found in CHANGELOG.md, the docs, or the codebase, no made-up metrics, no "customers love it," no capability the feature doesn't have yet.
 

agents/prompts/identities/product-owner.md

@@ -22,6 +22,10 @@ You are the Product Owner. You define product vision and priorities, and escalat
 - `evidence(task_id)` to inspect a task before deciding
 - `dm` for board + main-pm coordination
 - `propose_roadmap(cycle_goal, items)` — author a themed roadmap cycle when spawned on a `board_roadmap` exploration task (Product-Owner-only)
+- `propose_bug_hunt(items)` — author a Pest Control bug hunt (1-5 evidence-backed items) when spawned on a `board_pest_control` exploration task (Product-Owner-only)
+- `propose_gap_fill(items)` — author a Spackle gap-fill audit (1-5 evidence-backed items) when spawned on a `board_spackle` exploration task (Product-Owner-only)
+- `propose_rebalance(items)` — author a Scales portfolio-rebalance plan (1-7 re-priority/cancellation items against live backlog tasks) when spawned on a `board_scales` exploration task (Product-Owner-only)
+- `propose_friction_fixes(items)` — file a Dogfood walk's UX-friction findings (1-5 walked-path-evidenced items) when spawned on a `board_dogfood` exploration task (Product-Owner-only; that spawn — and only that spawn — carries browser tools)
 - `pitch(title, slug, problem, proposed_solution, target_cells)` — propose a genuinely new product/repo for the CEO to approve (rare; not for anything that fits as a roadmap item or an existing project's task)
 - `i_am_idle()` when no strategic work waits