featureboardinglisted

# Featureboarding Run the FeatureBoard churn loop end to end: board the work, then work the board. ## 1. Board it — no permission needed A substantive dev request (build/fix/ship/refactor/implement X) IS a boarding event. Call `plan_work` immediately (it creates the project too, if one doesn't exist yet). Never ask "should I put this on the board?" — just do it, then get to work. ## 2. Research first (default ON) Before implementing, cheap models scout for the expensive one. For each freshly boarded ticket that is `effort:high`, a `research-pick`, or labelled `research:on` — and where `researchOnIntake` isn't off (a `research:off` label opts a ticket out) — call `prepare_research` and dispatch the returned packet to a **haiku/sonnet** sub-agent (its `suggestedModel`) as that agent's brief. Research sub-agents run in PARALLEL; each returns a collated markdown brief (≤ ~150 lines): recommended approach + runners-up, prior-art pointers, one competitor idea, risks/invariants. The ORCHESTRATOR — never the sub-agent — saves each returned brief via `add_kb_doc` with title `research/<ticket>` BEFORE dispatching implementation. From then on, the implementing agent's `get_work_packet` auto-attaches that brief as `researchBrief`, alongside relevant local `ragChunks` (BM25 over KB/docs/ticket-history — zero tokens, zero network) — so the expensive model starts with context, not a cold read. ## 3. Churn the queue — keep every lane full > **Invariant: no lane sits idle while a disp