Skip to content

Latest commit

 

History

History
44 lines (33 loc) · 1.41 KB

File metadata and controls

44 lines (33 loc) · 1.41 KB

Test On Your Codebase

What to test first

Do not start with the entire company. Start with one bounded system.

Good first candidates:

  • one application with a few repos
  • one service family with supporting docs
  • one product area with support content and code

Minimum viable source set

For a meaningful first test, aim for:

  • 1 to 3 repositories
  • 5 to 20 docs or support articles
  • one local Obsidian vault path
  • one local workspace path

What “success” looks like

You do not need everything on day one. A successful first run means:

  • the vault is scaffolded and navigable
  • research notes preserve provenance
  • there is a linkable path from documentation to code
  • the readiness report tells the truth about what is done and what is missing
  • you can explain what should become automated next

Suggested proving questions

After the first run, try asking:

  • What are the main product areas and how are they represented in the vault?
  • Which repositories implement this area?
  • What documentation appears stale versus the code?
  • What are the strongest bug or support signals?
  • What is still missing before engineers can ship confidently from this system?

Common first-run mistakes

  • skipping the manifest
  • starting with too many repos
  • importing notes without preserving raw sources
  • treating the vault like a dump instead of a synthesis layer
  • trying to automate everything before the manual path is proven