The living knowledge base, doc by doc

Eleven documents that write themselves from your codebase's structure and your team's memory — and what each one is actually for.

The living knowledge base auto-writes a family of docs from your codebase's structure and keeps them current on every push. Here's the tour — what each doc is for, and where it comes from.

The map-derived docs

• Overview — the index: what the project is, the key decisions, where things live. The doc you read first.
• Architecture — the module map and how a request/data flows end to end.
• Modules — a per-module reference: purpose, key exports, its dependencies, the routes it defines, the tables it touches. Big modules break into sub-modules so apps/web becomes apps/web/app, apps/web/components, apps/web/lib.
• Dependencies — the module dependency map from the call graph: which modules are foundational (used by many) and which are leaves.
• API — every HTTP route, grouped by the module that defines it.
• Data model — the database schema, table by table, with columns, types and enums.
• Glossary — key exported symbols with a plain-English meaning each.
• Changes — a readable summary of recent git activity, grouped into themes.

The dependency map, API reference and data model are the ones no generic doc tool can auto-write, because they need the call graph, the routes and the parsed schema — structure SecondOS extracts and others don't.

The memory-derived docs

• Knowledge — the team's decisions, conventions and gotchas, turned into readable prose.
• Learnings — a running log of what the team has learned about the codebase.
• Onboarding — the lay of the land, conventions to follow, traps to avoid.

These fill in as your team records memories, and grow over time.

It maintains itself

You don't generate these by hand. On the first sync the applicable docs appear; every push refreshes them incrementally, rewriting only the sections whose map or memory changed. All from the structural map — never your source. Read the docs.