BRÈCHE
Codebase takeover evidence pack
Guide: /guides/codebase-takeover-checklist
Updated: 2026-09-25

Give the incoming developer a working baseline and reproducible failures before asking for a repair or rebuild estimate.
Fill this in locally. Nothing is sent to BRÈCHE.
Do not include passwords, API keys, wallet recovery phrases or private customer data.

1. Running product
Name the production environment, repository and deployed revision. Mark any uncertainty about how these match.
Your notes:


2. Setup and test access
Link to setup notes, test accounts and service documentation. List missing access and its owner. Keep credentials out of this document.
Your notes:


3. Reproduction record
For each blocker: starting state, sanitised input, numbered actions, expected result, observed result and relevant error reference.
Your notes:


4. Baseline checks
Record the commands or user journeys that currently pass. Keep their environment and revision so a change can be compared fairly.
Your notes:


5. Compatibility boundaries
List existing API consumers, integrations, customer URLs, data formats and operational routines that must keep working.
Your notes:


6. Access gaps and hypotheses
Separate observed failures from possible explanations. For each hypothesis, name the next check that could confirm or reject it.
Your notes:


7. Change options
For repair, partial replacement or rebuild, state supporting evidence, unknowns, migration work and rollback constraints.
Your notes:


8. Next release
Choose the blockers to resolve first. Record acceptance evidence, review owner and any deadline with its reason.
Your notes: