Design: multi-project boards — a projects: map so a team can own a repo plus its toolchain without repoint-restart detours

[mabry1985]

Problem

The board is single-project by configuration: one repo:, one local_gate_cmd:, one store binding for tools/API/view/loop. Working a ticket in any OTHER repo (most commonly: this plugin itself) requires the operator detour — swap project_board.repo + gate in config → restart → work → swap back → restart. The 2026-07-21/22 dogfood ran this detour four times (issues #56, #76, #78+#79, #84+#85+#86 → PRs #75/#77/#80/#81/#82/#87/#88/#89 — every one a self-fix the team could not board without an operator ceremony).

The data model is most of the way there already: get_store is cache-keyed (db, repo, base_branch) (multiple boards coexist in-process since the ADR 0055 P0 fix), and the loop already reads feature.get("repo") at dispatch. The single-project constraint lives in the config wiring alone.

Proposed direction

A projects: map — one board, one loop, one db, per-feature project resolution:

project_board:
  default_project: protoagent
  projects:
    protoagent:   { repo: ~/dev/protoAgent-team,     local_gate_cmd: "…", base_branch: main }
    board-plugin: { repo: ~/dev/projectBoard-plugin, local_gate_cmd: "…" }

• Features stamp their project at create (board_create_feature(project=…), default = default_project); the loop resolves repo/gate/worktrees-root per FEATURE, not per instance.
• Preflight becomes per-project — a broken gate in one project must not HOLD work in another (the fail-closed hold from feat(loop): fail-closed gate preflight — never start work a broken gate can't accept (v0.33.0) #73 currently would).
• One pinned db_path, one board view (grouped/filterable by project), one monitor drawer (Live coder monitoring: ACP session/update tap + per-feature progress API + click-to-monitor drawer on the board view #84), one global dispatch semaphore.
• Back-compat: today's flat keys = an implicit single project; no migration.

Scope guard (the philosophical half)

This deliberately does NOT turn the team into a portfolio manager. The boundary: a team owns one repo plus its own toolchain (the plugins it runs on) — self-sufficiency for self-fixes. Cross-domain orchestration stays with the portfolio tier (pm-stack). Config should keep small-N ergonomic and large-N discouraged.

Acceptance sketch (when picked up — decomposes into ~3 slices)

1. Store: project field/label on features; per-project store_kw resolution; prefix/id behavior documented.
2. Loop: per-feature repo/gate/preflight; per-project preflight hold isolation.
3. Tools/API/view: project param on create/update/list (default preserved), view grouping, progress keying unchanged.

Refs

The four detours above; ADR 0055 P0 (board cache keying); #73 (preflight hold); #84 (drawer); the operator detour procedure in the protoEngineer workspace config history.

[mabry1985]

Adding a concrete mechanism observed tonight (2026-07-25) that makes the repoint-restart gap sharper than described:

The repoint is silently wrong until restart, not just inconvenient. When POST /api/config changes project_board.repo and reports ok: true, reloaded, the board continues serving the OLD repo. Cause:

• store.get_store() caches instances keyed by (db, repo, base_branch) (store.py:1259). A config hot-reload re-reads config but does not re-register the plugin, so the cached store keeps the stale binding.
• store._project() returns "repo": self.repo (store.py:1235) — the store instance's value, not a per-feature field.

A card boarded in that window carries the stale binding into dispatch. The only visible symptom is the repo field in the card, and nothing validates it against the live config. In tonight's case, a coder would have looked for store.py in the wrong checkout.

A projects: map that makes the repo binding per-feature rather than process-wide would remove this failure class entirely — the binding lives on the card, not in the cached store instance. That also removes the restart requirement, which is what this issue is about.