Inherited codebase takeover¶
Trigger¶
The organisation acquires, inherits or repatriates a system nobody present built.
Intended outcome¶
A reviewed, measured, supportable system with a sequenced improvement plan.
Workflow steps and gates¶
| Step | Accountable role | Activity | Handover | Gate |
|---|---|---|---|---|
| 1 | Codebase Reviewer | audits against fixed criteria and reports prioritised findings | review report with located, measured findings | Criteria fixed before any code is read |
| 2 | Application Architect | assesses structure and defines module boundaries | boundary definition and refactoring roadmap | Boundaries enforced by automated checks, not prose |
| 3 | Test Architect | establishes how the system can be verified at all | test and environment strategy | Production-like data obtained lawfully |
| 4 | Software Modernisation Engineer | captures existing behaviour before changing it | characterisation test suite | Undocumented behaviour treated as a requirement until proven otherwise |
| 5 | Infrastructure as Code Engineer | codifies whatever it currently runs on | reproducible environment definition | Applies from clean; drift detectable |
| 6 | Observability Engineer | makes its behaviour visible before changing it | instrumentation and baseline signals | Baseline captured before the first change |
| 7 | Technical Lead | sequences the work so each slice ships independently | incremental delivery plan | No step requires a simultaneous big-bang cutover |
| 8 | IT Service Owner | accepts ownership with a cost and risk position | service definition, SLA, risk profile | A service with no owner is reported as ungoverned |
Running this workflow: operator and implementer boundary¶
In Claude Code or Codex CLI, use the prompt in the next section (or adapt it to your programme): it is a provider conversation request, not a shell program named after this workflow. You supply the source materials, actual owners, gate acceptance and any authorisation for changing real systems. The provider agent interprets the registered workflow stages and role contracts, calls supported tools if allowed, and returns explicit evidence and blockers. Stage completion in the diagram or metadata is not proof of a successful external tool call, an approved exception or a released system.
For consequential decisions explicitly start /layered (Claude) or $workflow-layered (Codex); this version does not force every direct/natural-language workflow invocation into Fabric. Human L0 authority remains separate, with Codex requiring the actual human to run any protected authority command in a trusted terminal. See the interaction model, layered engagement and human authority.
How to use this workflow¶
A practical prompt pattern is:
Apply the
codebase-takeoverworkflow to this situation. For each step, identify the current state, accountable role, required evidence, hand-over artefact, gate status and unresolved blocker. Do not skip a gate merely because the implementation is technically complete.
Operational interpretation¶
The workflow is most useful when the team keeps each hand-over explicit. The system can help generate or review the artefacts, but the accountable role and approval decision remain organisational responsibilities.