AUTO-TABLE inventory
Coined hereA per-PR-rebuilt structured table of entities × layers × invariants × tests × last-touched, generated automatically so that every Claude Code session opens against the same architectural snapshot of the codebase.
AUTO-TABLE is Code Majesty’s term for the generated index a Claude Code agent reads at the start of every session. Each row maps an entity (table, aggregate, controller, feature) to the layers it touches, the invariants it must hold, the tests covering it, and the last commit that modified it. Because the table is rebuilt on every PR, agents never operate against a stale mental model of the codebase.
A row looks like this:
| Entity | Layers | Invariants | Tests | Last touched |
|---|---|---|---|---|
Order | Api, Domain, Infrastructure | total ≥ 0; no delete after dispatch | 14 (3 integration) | a41f2c9 — 2026-07-18 |
Three properties distinguish it from the wiki generators. Per-PR rebuild: Devin Wiki and DeepWiki regenerate on a schedule or on demand; AUTO-TABLE regenerates in CI on every pull request, so the diff of the table is the architectural diff of the PR. The invariant column: wiki generators summarize what the code does; the invariant column records what must stay true — which is what a reviewing agent, or a regulator, actually needs. Deterministic generation: the table is produced by Roslyn analysis, not by an LLM summarizing. The same commit always yields the same table, which is what makes it usable as audit evidence.
When to use
- Multi-feature .NET solutions where any single change risks invariant regressions across layers.
- Onboarding a fresh agent session into a codebase with more than ~30 entities.
- Generating per-PR architectural diffs auditable by humans and regulators.
Compare with
Devin Wiki (commercial), DeepWiki (open-source) — both generate human-readable wikis. AUTO-TABLE differs by being agent-readable, regenerated per-PR, and invariant-centric.