DEVELOPER HANDOFF
Give the next builder a project they can understand, implement and continue.
A responsible handoff connects product intent, project decisions, technical context, scope, acceptance criteria, ownership and evidence. It should remain useful after the first implementation task is complete.
WHY HANDOFFS FAIL
Files and feature lists rarely explain the complete project.
A handoff can include designs and requirements while omitting why decisions were made, which assumptions remain open, what evidence supports the architecture, who controls the providers or how the result will be accepted.
The developer then has to reconstruct the project before meaningful work can begin.
PRODUCT INTENT AND SCOPE
Explain the outcome before the implementation detail.
State the users, problem, intended outcome, supported scenarios, current product stage and explicit exclusions. Connect each major feature to the outcome it supports.
Scope should identify what is fixed, what can be proposed and what requires a separate decision.
PROJECT MODEL AND EVIDENCE
Preserve the accepted facts, decisions and unresolved questions.
The handoff should include the current Project Model: sources, accepted requirements, decisions, assumptions, risk, missing information, architecture and release state.
Evidence and provenance help the developer distinguish a confirmed constraint from an inherited claim.
ARCHITECTURE AND TECHNICAL CONTEXT
Provide enough technical context to make responsible changes.
Include the current stack, component boundaries, data model, interfaces, environments, providers, deployment path, known constraints and operational dependencies where they are known and authorised to share.
Do not hide uncertainty behind a polished architecture diagram.
TRANSFER MANIFEST
Developer Handoff Manifest
Product intent and scope
Users, problem, outcome, supported scenarios and explicit exclusions
Project Model
Sources, accepted facts, decisions, assumptions, risk and missing information
Architecture and technical context
Stack, boundaries, data, interfaces, environments and known constraints
In active development Build Specification
Outcome, scope, exclusions, dependencies, permissions and acceptance criteria
Access and ownership
Authorised control, approvers, provider boundaries and custody decisions
On the roadmap Acceptance and verification
Tests, build evidence, review steps, independent verification and Tested Preview
Continuation
What changed, what was approved, what remains unresolved and what happens next
Record who controls repositories, provider accounts, domains, data, deployments and billing decisions.
Do not embed credentials, tokens or private keys. Identify which actions the developer may perform and which require the owner or another approver.
BUILD SPECIFICATION
Define the next implementation as a reviewable contract.
A Build Specification should include the outcome, scope, exclusions, acceptance criteria, dependencies, permissions, ownership targets, validation requirements and expected evidence.
It should be versioned, approved before material execution and updated when the accepted project state changes.
ACCESS, OWNERSHIP AND PROVIDERS
Make operational responsibility explicit.
Record who controls the repository, provider accounts, domains, data, credentials, deployments and billing decisions. Identify which actions the developer can perform and which require the owner or another approver.
Credentials and private keys should never be embedded in the public handoff document.
VERIFICATION AND PREVIEW
Define how the result will be checked and reviewed.
Acceptance criteria should connect to the relevant tests, build evidence, review steps and preview expectations. Agent or developer completion should not automatically become project completion.
Independent verification and Tested Preview are roadmap capabilities in Airchor’s Control Plane direction.
CONTINUATION
Update the project state after the delivery decision.
A useful handoff records what changed, what was verified, which decisions were approved, what remains unresolved and what should happen next. The Project Model can then support the next release without rebuilding context.