Lock with David before code:
| Decision | Recommendation | Why |
|---|---|---|
| Where the side app lives | New app in the same monorepo (apps/solo) — a second web client of apps/application | Shared contracts/types/CI; the application layer is already the web↔agent seam. Fresh repo re-solves auth, types, deploy for zero gain |
| Share | DB + RLS · auth + agent-JWT · agent runtime + fleet · connector engine · retrieval · job queue | The mass and the moat; re-implementing any is wasted cycles and re-opens solved safety surfaces |
| Fork fresh | Web shell chrome, chat surface chrome, the entire /data + attention UX | This is where "under-perfected" lives; contracts stay identical so the fresh UI drops onto existing routes |
| Freeze | Team Hub, /map, /pipeline, /outputs, /workflows, voice, billing nav | Code stays, nav dies. No deletions in Phase 0 |
apps/solo shell rendering against live routes.apps/solo proceeds as a second web client of apps/application. Phase 0 is unblocked.Same monorepo (apps/solo) | Fresh repo | |
|---|---|---|
| How sharing works | Direct imports: DB + RLS, auth + agent-JWT, agent runtime, connector engine, retrieval, job queue, typed API contracts | Everything shared becomes an over-the-wire API or copied code; the application API isn't published as a stable external contract today — that would have to be built first |
| Spine improvements | Land in both apps automatically — one fix, two clients | Double-ship every change, or maintain a versioned SDK — pure tax at our team size |
| Type safety / drift | Compile-checked against the live API; drift impossible | Contract drift guaranteed without published packages + version discipline |
| CI / deploy / secrets | Existing pipelines and previews just work | Second pipeline, second secret store, second deploy story — day one |
| Speed to first render | Scaffold + point at live routes | Re-solve auth, env, contracts before the first screen renders |
| Clean-room feel | Must be engineered: import boundary + shell starts empty | Free — nothing old in sight |
| Spin-out optics | Weaker separation; extraction later is real work if solo becomes its own company | Clean separation from day 1 |
| Strangler fit | Exactly the pattern: strangle the old shell, keep the organs | Takes the organs out of the body — the opposite of the strategy |
The call: same monorepo. The only genuine fresh-repo arguments are psychological (no gravity) and corporate (spin-out optics). The first we get with a lint-enforced import boundary (apps/solo may import packages/*, never apps/application UI) and an empty shell where components earn their way in; the second isn't a Milestone-1 problem — extraction is possible later if solo earns it. Everything else — sharing, drift, CI, speed — points one way.
Exists: inline proposal cards from main chat, generalized proposal spine, write-through rail. Build: a data_file proposal variant · the proactive trigger (agent notices data-layer-worthy info mid-conversation, proposes a drafted MD doc) · inline edit in the card · approve → auto-filed with provenance.
| Stage | Job | Substrate |
|---|---|---|
| Compile | Extract entities/structure from new docs + conversations | Librarian scan passes — persona removed, jobs kept |
| Link | Propose wiki-links between related files | Entity graph + graph retrieval exist; link-proposal pass is new |
| Lint | Dedupe, contradiction detection, staleness → attention queue | Consolidation + dedup exist; contradiction write-path is the known gap (seam reserved) |
| Synthesize | Merge fragments into coherent docs, propose restructures | New pass, same proposal rail |
Everything flows through the same approval rail — the user never sees "the system," only proposals and a clean tree. Runs nightly + on-ingest.
Engine exists and is mature (16–17 connectors, OAuth, freshness, grant-health, write-safety). This is selection and polish, not build:
"We beat everything that exists by using everything that exists in the best possible way."
How it composes with the moat: the claim stays "it already knows, and it stays right" — the curated data layer is the substrate no frontier vendor has. The harness is how the agent stays frontier-best at execution. Together: best substrate (their data, curated) × best execution (every frontier capability, composed).
| Who | Owns |
|---|---|
| David | apps/solo scaffold + chat port + latency (Phases 0–1), connector polish (Phase 3) |
| Rook + agent swarm | Wiki-engine passes (direct port of patterns we run internally), proposal-loop extension, ontology seed, P2 polish sweeps, benchmark authoring + run |
| Thomas | Phase-0 sign-off · weekly use-it-daily feedback from the first shell onward — the polish bar is judgment, not tickets |
Cadence: demo against the milestone bar at every phase exit. Phases are sequence, not schedule — with agents on the build, phase clocks run in hours and days; the chat port is the fastest lane (it's the best code in the repo).