Living knowledge base
Bring a project in and SecondOS writes a whole family of readable docs about it — then keeps them current on every push, without anyone maintaining them. Your codebase's second brain.
What you get
Eleven documents, each written from a different slice of your project's map and your team's memories:
| Doc | Written from | What it covers |
|---|---|---|
| Overview | map + memory | The index — what the project is, key decisions, where things live, and pointers to the rest. |
| Architecture | map | The module map and how a request/data flows end to end. |
| Modules | map + graph + schema | A per-module reference — purpose, key exports, its dependencies, the routes it defines and the DB tables it touches. Big modules break into sub-modules. |
| Dependencies | graph | The module dependency map: which modules are foundational (used by many) vs leaf (depend on many). |
| API | routes | Every HTTP route, grouped by the module that defines it. |
| Data model | schema | The database schema — a section per table with its columns, types and enums. |
| Knowledge | memory | The team's recorded decisions, conventions and gotchas, turned into readable prose. |
| Learnings | memory | A running log of what the team has learned about the codebase. |
| Onboarding | map + memory | How a new engineer gets started — the lay of the land, conventions to follow, traps to avoid. |
| Changes | git | A readable summary of what changed recently, grouped into themes. |
| Glossary | map | Key exported symbols with a plain-English meaning each. |
How it works
- Bring a project in — sync it (
bunx @secondos/cli push .) or connect GitHub. On the first sync the applicable docs write themselves. - Every push refreshes them — each doc is split into sections, and each section is content-addressed by the slice of the map/memory that feeds it. A refresh re-runs the model only for the sections whose input changed; every untouched section stays byte-identical, at no cost.
- Memory-derived docs fill in over time — knowledge and learnings appear once the project has accepted memories, and grow as your team records more.
Why it's different
- It never rots. The docs are regenerated from the current code, so they can't drift out of date the way a hand-written
CONTEXT.mddoes. - It uses what only we have. The call/import graph, routes and DB schema mean the dependency map, API reference and data model are docs no other tool can auto-write.
- Your source stays home. Everything is written from the structural map — paths, signatures, routes, the module layout — never your source bodies (K‑S23).
- You maintain nothing. Connect once; the knowledge base stays current on its own.
- Every AI tool can read it. The docs are not just a web tab: the
read_living_docMCP tool serves the same map-derived architecture, overview, module and API docs straight into your agent, so it reads what someone already wrote down instead of re-deriving it. Read-only and free.
The living knowledge base is a Pro feature — the recurring generation runs server-side, so you don't need your own model credentials. Read it in the project's Knowledge tab, or generate any doc on demand.
Next
See the product overview for how memory and the graph fit together, the MCP server for how your AI tools read all this, or pricing.