Evaluate an optional visual cockpit (e.g. emdash) as a front-end over the headless pipeline

[robercano]

Context

This harness is headless / CLI-first: code-defined fan-out (feature-fanout.js), gate-as-code, adversarial multi-lens review, and autonomous operation (cron poll + scheduled wakeups). emdash (YC W26, Apache-2.0) covers the overlapping layer — "run N agents in worktrees + diff/review/merge UX" — with a polished desktop GUI, ~27 providers, SSH/SFTP remote, scheduled automations, and GitHub-check surfacing.

But emdash has no role-based orchestration, no local gate enforcement, no adversarial review, and no headless mode (providers live in a code registry; review is a human eyeballing a diff). So the two are complementary: emdash as a cockpit, this harness as the engine — not substitutes.

Suggestion

Spike whether emdash (or a similar GUI) can sit on top of the same worktrees as a visual front-end while this harness stays the autonomous engine. Document:

• the integration seam — both drive git worktrees, so coordinate to avoid branch/worktree clutter (pick one driver per session);
• what must exist for checks to show up in such a GUI (depends on the CI-workflow issue — server-side gates);
• what the harness keeps that the GUI can't replace: gates-as-code, defined roles, adversarial review, headless autonomy.

Outcome is a doc note / decision in docs/, not necessarily an integration.

Surfaced by a feature comparison with emdash while driving the template downstream (reDeploy).

[robercano]

🤖 Proposed implementation plan

Size: S (research spike → decision note, no integration) · Deliverable is a docs/ note + a go/no-go, not code.

Goal

Decide whether a visual cockpit (emdash or similar) can sit on top of this headless harness as a front-end, while the harness stays the autonomous engine — and write that decision down.

Deliverable

A new docs/COCKPIT.md (or an ADR under docs/adr/) with a recommendation. Expected outcome, based on what's already known: complementary, document-only, no integration now — but the spike confirms/refutes that.

Spike tasks (timeboxed)

1. Worktree coexistence — both emdash and this harness drive git worktrees. Establish the seam: one driver per session to avoid branch/worktree clutter. Document who owns .claude/worktrees/ when both are present.
2. Check surfacing — emdash monitors GitHub check runs, it doesn't run them (emdash.sh/docs/ci-checks). We now ship server-side gates via .github/workflows/gates.yml (Ship a CI workflow that runs gates.json gates on PRs (server-side gate enforcement) #8, closed), so checks already exist for a GUI to surface. Confirm the mapping and note branch-protection as the teeth.
3. What the harness keeps — enumerate what a diff-eyeballing GUI can't replace: gates-as-code, defined roles (orchestrator/implementer/reviewer), adversarial multi-lens review, headless autonomy (cron poll + scheduled wakeups). This is the "engine vs cockpit" boundary.
4. Recommendation — engine + cockpit are complementary, not substitutes; state the conditions under which an integration would be worth it (and that it isn't yet).

Acceptance

• docs/COCKPIT.md exists, markdownlint docs/ clean, linked from docs/ARCHITECTURE.md (the "three levers" / topology section).
• No dependency added, no harness code changed.

Cross-refs

• Builds on Ship a CI workflow that runs gates.json gates on PRs (server-side gate enforcement) #8 (closed) — server-side checks now exist, which was the precondition for any GUI to show pass/fail.
• References Per-worktree setup/teardown lifecycle hooks so isolated workers can run all gates #9 (both need worktree lifecycle coordination).
• Recommend labeling this question/spike and doing it last — its value is a decision, and it depends on the others being understood first.