Six services, six sets of notes,
and no way to read them together.
The notes exist. Every service has a README worth reading, most have an architecture folder, and someone wrote a genuinely good document about how the payments flow works. It is in a repository you have not cloned.
Every tool that could present this asks you to pick one repository and write a navigation file for it. That model was built for a product with one documentation site, and it is the wrong shape for a platform team with thirty repositories and no appetite for thirty config files.
So the knowledge stays where it was written, is found by grep if at all, and gets re-derived in a meeting every few months by whoever was there last time.
Multi-repository is the part that is architecturally hard to copy: one repository, one site is an assumption that goes all the way down in every tool built for public documentation.
The parts that matter here
Not the whole feature list — the ones this particular problem turns on.
Many repositories, one workspace
A project holds as many repositories as you point at it. The tree shows them together, search spans all of them in one statement, and access is granted once at the project rather than per repository.
The folder structure is the navigation
Thirty repositories means thirty navigation files in any other tool. Here it means thirty connections and no configuration, because the structure you already have is the structure we read.
Documentation behind the code
A note naming a source path that changed after the note did becomes a finding. Across a platform this is the difference between knowing your architecture docs drifted and discovering it during an outage.
Diagrams that match the page
Mermaid renders in the product's live palette rather than a stock theme, and re-reads it when you switch theme. A sequence diagram in an architecture note is the point of the note.
Agents that cite rather than guess
A coding agent working in one service can read what the other five documented, with a URL a person can open — instead of inferring your architecture from the code it happens to have in context.
A move keeps its identity
Reorganising docs across repositories is normal on a platform team. A renamed or moved file stays the same document, so its review state, notes and health findings move with it instead of being silently dropped.
What actually happens
- 01Connect the services one at a timeEach takes about a minute and needs no configuration. Group them into a project named after the domain rather than the repository.
- 02The tree assembles itselfDocs roots found per repository, titles inferred, order applied, CHANGELOG and LICENSE collapsed out of the way. Nobody writes a sidebar.
- 03Search stops being per-repositoryOne keystroke across every service in the organization, ranked, with the path and review state beside each hit.
- 04Grant the project to a team, onceAccess is the project, not the repository, so onboarding somebody onto the platform is one grant rather than thirty.
- 05Point your agents at itA key scoped to that project, read-only, optionally with a review floor so an agent only sees documents somebody has validated.
- 06Watch the code move away from the notesPushes that touch source paths your documents name become findings. It is the only automatic signal in the product that a human did not have to file.
What this does not solve
Every page on this site carries one of these, for the same reason: a use-case page with no limits on it is a brochure.
- It does not read your code
- Nothing outside the docs root is ever fetched. We see the names of changed source paths from the push payload — never their contents — which is what makes the behind-the-code signal cheap and also what bounds it.
- It does not generate diagrams
- Mermaid you wrote renders properly. There is no inference of architecture from a dependency graph, and there is not going to be.
- One organization, not a federation
- Repositories group into projects inside an organization. Reading across two separate organizations from one view is not something this does.