The desktop app opens any folder as a “vault.” Point it at a git repo and three things already work with zero changes: it discovers the claude sessions you ran in that repo’s terminal, it launches new agents with the repo as their working directory, and it never touches your git tree (no worktrees, no branches, push is a manual button). What’s not generic is everything layered on top — the instructions injected into every agent, and the Plan/Canvas workflow, all assume an HTML-Docs document vault. The plan below is a four-phase path to gate those behind a “repo mode.”
There is no separate “project” concept. You pick a folder; that folder’s absolute path is the single key everything derives from. For a code repo the app auto-detects it (it sees package.json, Cargo.toml, go.mod, pyproject.toml…) and switches to repo-aware indexing so it never treats your source .html as documents.
Every Mission Control subsystem, graded for “drop it on an arbitrary git repo today.” Green needs nothing; amber degrades or needs gating; red is a genuine blocker for the intended experience.
| Subsystem | Status | Behaviour on a plain code repo (no .html) |
|---|---|---|
| Folder picker → open vault | Generic | Native OS folder picker; any directory is valid. Repo auto-detected via manifest files, switches to repo-aware indexing. |
| Terminal-session discovery | Generic | Reads ~/.claude/projects/<slug>/*.jsonl for the repo path. Works with zero hooks. Title, working/idle, and todo progress all derived from the transcript. |
| New-session launch | Generic | Spawns claude -p with cwd = repo root, chosen model + permission mode. Direct & Ask modes are content-neutral. |
| Git handling | Generic | Read-only status + diff meter; degrades cleanly in a non-git folder. Never creates worktrees/branches; push is user-gated. |
| Usage / cost analytics | Generic | Token accounting reads the same transcripts; caches to .htmldocs/usage-cache.json under the repo. |
| Injected system prompts | Blocker | Every agent is told it’s in an “HTML-Docs vault,” to write deliverables as self-contained .html into plans/ debriefs/ canvas/, in a fixed brand design system. Wrong instructions for a code task. |
| “Plan first” mode | Needs work | Functionally works, but the plan is a plans/*.html vault document (regions, versions, comments) rendered in the editor — not a repo-native artifact a dev would commit. |
| Editor / Docs screen | Degrades | Only indexes .html in doc folders; on a code repo the Docs list is simply empty. Harmless, but a dead surface. |
| Session Canvas (stage/debrief) | Needs work | Non-plan sessions are told to keep a canvas/*.html visualization; the rich stage view depends on .claude/canvas/ hooks being installed. |
| Per-vault storage | Cosmetic | Session records + title cache live in .htmldocs/ inside the repo — should be gitignored or relocated so it doesn’t litter the tree. |
| Cloud sync (html-docs.com) | Independent | A separate, manual, opt-in Drive-style screen. Not required by Mission Control; simply leave it unused on a code repo. |
The launch mechanics are clean. The coupling is (a) the text injected into agents and (b) the assumption that a “plan” is a vault HTML document. Fix those two and the rest is cosmetics.
Three prompt builders are appended to every agent’s system prompt. All assume an HTML-Docs vault: write deliverables as self-contained .html into plans/ · debriefs/ · canvas/, obey a fixed clay/serif design system, emit hd-options buttons. A code agent should get repo-native guidance instead.
“Plan first” creates a plans/<slug>.html through the vault document model — regions, version snapshots, comment threads, freeze-on-approve. Elegant for docs; foreign to a dev who wants a Markdown plan they can read in the diff and commit.
The Editor and Cloud screens are built for .html documents. On a code repo they’re empty, not broken — but they’re dead rail entries that make the app feel mis-targeted.
.htmldocs/ (session records, title cache) and any .claude/canvas/ state get written inside the working tree. On a shared repo that’s noise in git status unless ignored.
One policy to flag: the deliverable prompt tells every agent to commit locally but never git push, and says this overrides any repo instruction that says to push. On your own repo that’s intentional; on someone else’s repo, imposing it silently is a decision worth surfacing (see Decisions).
Phase 1 alone makes the app genuinely useful on any repo — it’s a prompt-gating change, not new infrastructure. Later phases add polish and isolation. Each phase ships independently.
isRepoVault signal as an explicit workspace kind (docs | repo), surfaced through the vault info and settable in the picker.deliverablePrompt / canvasPrompt / planSystemPrompt conditional: in repo mode, swap in a code-native system prompt (respect the repo’s own CLAUDE.md, use its conventions, no html/design-system/hd-options instructions).plans/<slug>.md or .claude/plans/) instead of a vault HTML document — reviewable in the diff, committable.lastVaultPath today) and add a quick switcher — the natural shape for someone hopping between repos..htmldocs/ into the tree and never ignores it today — write a .htmldocs/.gitignore containing * on first use (one-line fix), or relocate the state entirely.git worktree and surface per-session branches.Each changes the shape of the work. My recommendation is marked on each.
The deliverable prompt currently forbids git push and explicitly overrides the repo’s own “push after tasks” instruction. That’s a sensible guardrail, but silently overriding another project’s stated workflow is a stronger stance on a repo you don’t own.
Recommend: keep “commit locally, never push” as the repo-mode default, but make it a visible, per-workspace toggle rather than an invisible hardcode.
The HTML plan gives you live regions, version history and inline comments for free — genuinely nice. But it lands as an .html file a code reviewer won’t want in the tree, and it couples plan mode to the whole vault document engine.
Recommend: Markdown in repo mode; keep HTML documents for docs-mode vaults. Same state machine, different backing file.
In-place execution means parallel agents on one repo fight over the working tree. Worktrees fix it but add real complexity (creation, cleanup, branch surfacing, discovery-path implications since each worktree is a different cwd slug).
Recommend: defer to Phase 4. Ship the single-agent experience first; most repo work is one agent at a time.
Open one of your non-html repos as a vault and drive a Direct session end to end. You’ll see the plumbing already works and feel exactly where the injected prompt fights the task. That firsthand list is the spec for Phase 1, and it’ll confirm the core claim of this plan: the fleet, discovery, launch and git-safety are done — only the words we put in the agent’s mouth are wrong.