AI PROTOTYPE CONTINUATION
Understand the prototype before another AI-assisted build cycle
An AI-built prototype can look complete while its scope, architecture, active files, test state, deployment state, and documentation remain unclear.
PRACTICAL FRAMEWORK
Build a current-state record before continuing
Treat intended outcomes, observed behaviour, reported behaviour, technical context, and unknowns as separate inputs.
Describe what the product is intended to do.
Record what currently exists.
Separate observed behaviour from reported behaviour.
Identify the known technology stack and unknowns.
List the current failures or confusion points.
Review the available documentation and evidence.
Record assumptions, conflicts, and missing access.
Define the desired recovery or continuation outcome.
Require repository inspection before implementation.
CURRENT FRAMEWORK
Current-state map
- Intended outcome
What the product is meant to achieve
- Current prototype
What can be observed or demonstrated
- Supplied records
Documentation, reports, and environment summaries
- Uncertainty
Conflicts, missing access, tests, and deployment state
- Required review
Read-only repository and runtime inspection
Read visual as text
Map the intended product outcome to what currently exists, the available documentation and evidence, conflicts and unknowns, and the developer repository review required before implementation.
DECISION CHECKLIST
Continuation-readiness questions
The next cycle should begin only after the supplied project state and the required developer verification are clearly separated.
What outcome is the prototype intended to support?
Which behaviour has been observed directly?
Which behaviour is only reported?
Which files, environments, and records are understood?
Where does documentation conflict with the visible state?
What is known about tests and deployment?
Which assumptions could change the continuation plan?
Is the goal continuation, recovery, repair, refactor, rebuild, or product redefinition?
What must be verified in the actual repository before changes begin?
| Project area | Known or observed | Reported | Unknown or unverified |
|---|---|---|---|
| Product behaviour | Behaviour reviewed directly | Owner or user account | Unreproduced paths and edge cases |
| Technical context | Available records and visible stack | Described local setup | Active dependencies and configuration |
| Documentation | Records reviewed | Claims about current accuracy | Mismatches with implementation |
| Tests and deployment | Available results or summaries | Reported status | Actual runnable and deployed state |
CURRENT FRAMEWORK
Continuation or recovery flow
- Pause
- Record state
- Separate certainty
- Inspect read-only
- Choose path
- Authorise work
Read visual as text
The flow is stop the next build cycle, record the intended and current state, separate known reported and unknown information, inspect the repository in read-only mode, choose a continuation or recovery path, and authorise bounded work.
COMMON MISTAKES & RISKS
Risks before another AI-assisted cycle
Fast continuation can deepen uncertainty when the latest prompt is treated as the complete project state.
Continuing from the latest prompt without restating the intended outcome.
Treating documentation as a verified description of the active code.
Treating reported behaviour as observed behaviour.
Changing dependencies before the actual environment is reviewed.
Assuming tests or deployment are healthy without evidence.
Choosing repair or rebuild before the project state is inspected.
Beginning implementation without a defined continuation or recovery goal.
CURRENT PRODUCT MAPPING
How this framework maps to Airchor today
Work on Existing Project organises supplied repository context, evidence, source-of-truth records, manual findings, recovery planning, and handoff drafts.
CURRENT LIMITATION
Supplied context is not automated repository inspection
Airchor does not currently scan or inspect the prototype or repository automatically. A developer or authorised repository-analysis tool must verify the actual code and runtime state.
- No code or dependency analysis
- No automated diagnosis or failure reproduction
- No test execution
- No repair or repository import
NEXT ACTION