Existing codebases
Onboarding code you already have, and handing authority over.
Most teams do not start from nothing. They have code, a CLAUDE.md that grew over months, a folder of ADRs and some requirement documents. This section is about bringing a solution like that under CorPole without stopping work, and without pretending the existing code is automatically right.
Onboarding is the solution's “Onboard …” initiative. It reads each repository, and what it finds in code, documents and tests becomes design drafts of that repository's component — modules as TDR drafts, behaviour as FDR, rules as BDR, qualities as NFDR — describing what the solution is today. Objectives, needs and constraints stay requirement drafts. People confirm a draft as the design, turn wrong behaviour into a defect, or reject it; nothing binds until a person says so. Until a module has been reviewed, agents ask before changing it, or wait, depending on the tenant's setting.
Handover moves authority from the old sources to CorPole in tiers. In Shadow, CorPole is read but the repository still leads; in Shared, CorPole wins where it has an Authority record; in Full, CorPole is the only source and the old documents point to it. /corpole:handover inventories the sources and turns them into proposals.
Start with the onboarding guide if you have code but no requirements; start with the handover articles if you have rule files and documents you want to retire.
Articles in Existing codebases
- GuideOnboarding an existing codebaseFor solutions that started without CorPole: the coding agent reverse-engineers the code, tests and documents into design drafts; people confirm what the solution is; governance grows module by module. The work runs as the solution's "Onboard …" initiative.
- ConceptAuthority handover: Shadow, Shared, FullFor solutions with existing sources, CorPole takes over authority step by step.
- How-toMove CLAUDE.md, ADRs and docs into CorPole`/corpole:handover` inventories what governs the solution and proposes it as records.