Repository navigation
Atlas companion frontend: integration proposal for #1860 #1964
Description
Context
This follows the discussion with Martin about making a deliberate size exception for the Atlas work. I am opening the required design/tracking issue before proposing any upstream pull request.
I built a separate companion frontend against the current feat/atlas-r1 implementation from #1860. The work does not modify the CBM checkout yet, and I do not consider it merge-ready without maintainer review.
What exists
The companion currently includes:
- a read-only Monaco source reader backed by the CBM read surface;
- a semantic twin that follows the symbol under the caret;
- flow, entry-point, bug-hunt and change-scope reading modes;
- deterministic, source-cited answers with optional local-model wording;
- a persistent graph view with bidirectional focus following;
- live-agent visualisation from a local replay/bridge;
- explicit air-gap, provenance and index-limit messaging;
- an extensive offline acceptance and browser verification harness.
The exact reviewed candidate is BernhardJackiewicz/CodeAtlasWeb@1825f9c850ac794066e02606012508b9d393c6aa. The repository is private while licensing, provenance and the intended upstream shape are reviewed; a maintainer-only write invitation is being provided separately; no other external collaborator has write access.
Why this needs an architecture decision
The implementation is currently a standalone SPA consuming the read-only interfaces exposed by #1860. It has not been folded into graph-ui, and CBM currently has no documented source-level home for a second SPA under --ui.
Before preparing an upstream branch, I would like the maintainer to choose one of these directions:
- integrate the useful surfaces into the existing
graph-uiand shared Atlas chrome; - establish an official second-SPA/static-assets route under
--ui; - keep this as a separately versioned companion project and upstream only focused CBM fixes/read-surface improvements.
Proposed contribution shape after that decision
- Base any stacked draft PR on
feat/atlas-r1while CBM Atlas: the human interface to the code graph #1860 remains open, then retarget/rebase after CBM Atlas: the human interface to the code graph #1860 lands. - Keep CBM backend fixes separate from frontend product work.
- Transfer only upstream-relevant source, tests, documentation and license material; do not import the full private proof history or large recorded artifacts.
- Recreate upstream commits with conventional subjects and DCO sign-off.
- Keep the resulting PR in draft until Martin has reviewed the architecture and scope.
Current verification
The current companion candidate has passed:
- 2,024 unit tests;
- 213 frozen acceptance checks;
- a fresh two-model local evaluation and release gate;
- an independent re-audit with no remaining product/code release blocker;
- a 30-state Playwright interaction, text-plausibility and visual review with no findings, browser errors or outbound requests.
Those results demonstrate the review candidate; they are not a request to waive upstream review or CBM's own CI/security requirements.
Review requested
Martin: please choose the preferred integration direction above, or propose another one. Once that is settled, I will prepare the smallest reviewable DCO-signed draft contribution rather than treating the current standalone repository as a presumptive merge candidate.
Related: #1860
Activity
DeusData commentedon Sep 5, 2026
Bernhard, thank you. This is a remarkable piece of work, and the way you handed it over (the inventory, the asks list, the proofs, a private review candidate with a pinned commit, and the question of direction before any branch) made the decision easy to take and easy to act on.
Direction: CodeAtlasWeb becomes the Atlas frontend. Not folded into
graph-ui, not a second route, not a separate companion: it replacesgraph-ui. Our previous frontend is removed and yours takes its place as the one thing--ui=trueserves. That answers your Ask 3 as well: the official home for the frontend isgraph-ui/itself.The stacked PR is #2068 (draft, on
feat/atlas-r1, as you proposed). What it contains, so you can check it against your own rules:1825f9cimported verbatim (everything except the agent-instruction file, which this repository keeps out of its tree by policy), squashed withCo-authored-by: Bernhard Jackiewiczon the commits that carry your code, and the commit messages say whose work it is;npm ciwithout a browser download, dev port 5173 to meet our dev-proxy contract test,lang="en", and a CSP change you would have hit under the embed:connect-srcwas'self'only, which silently blocked the sidecar on 4141 and the bridge on 4142; it now admits exactly those two loopback origins, with a test that pins "nothing else";[p]rojectspanel (alt+p) in your idiom for the surfaces our previous frontend had and yours deliberately did not: index a repository, check or remove an index, the ADR editor, processes and log. I know this bends the read-only thesis; the panel names every route it uses, keeps every affordance honest, and the help page now says exactly what this window can ask the server to do. I would value your eye on its wording in particular.test-uiCI leg (scripts/ci/test-ui.sh) running your vitest suite, style gate, promise scan and the portable acceptance checks (the two release-binding files stay out, since they bind to your repository's commits).Asks 1, 2 and 5 stay open on our side as backend follow-ups; they are good ones.
Once #1860 and the stacked PR land, this issue closes with them. Thank you again.
feat(ui): replace graph-ui with CodeAtlasWeb by Bernhard Jackiewicz
ci(ui): test-ui lane gates CodeAtlasWeb; docs describe the new Atlas