STRUCTURED EXISTING-PROJECT ASSESSMENT
Airchor provides a repeatable Work on Existing Project route for organising supplied client context into a 10-document Assessment & Recovery Plan.
This page describes a planning and manual-assessment workflow. It is not checkout, booking, private-data intake, an automated repository audit, or a guarantee of delivery.
THE AUDIENCE PROBLEM
Client software often arrives with incomplete documentation, uncertain implementation state, conflicting reports, and pressure to estimate. A bounded assessment makes the available evidence, missing information, risk, and conditions for the next step visible first.
Use this route when software already exists and the main task is understanding, assessing, repairing, recovering, or rebuilding it.
Record reported repository context, access state, technology summary, known issues, deployment and testing status, source-of-truth records, evidence, assumptions, manual findings, risks, recovery goals, and constraints.
Assess before quoting implementation.
LIVE ROUTE MAPPING
Use Create New Project when the software does not yet exist or still needs to be defined. Use Work on Existing Project when an application, prototype, inherited repository, or deployed product already exists and requires structured assessment or continuation planning.
Use this route when software already exists and the main task is understanding, assessing, repairing, recovering, or rebuilding it.
A 10-document Assessment & Recovery Plan.
Current boundary: The assessment is based on supplied and manually reviewed context. Airchor does not currently inspect repository code, reproduce failures, run tests, or verify deployment state.
Explore Work on Existing ProjectUse this route when the main task is defining what should be built.
A 14-document Project Blueprint.
CURRENT WORKFLOW
Define the client decision and assessment boundary.
Record supplied repository, deployment, testing, and product context.
Review source-of-truth records and note evidence strength.
Complete the eight manual assessment categories.
Document findings, assumptions, gaps, blockers, and risk.
Frame repair-versus-rebuild options and their conditions.
Prepare a sequenced recovery roadmap.
Create the next implementation and developer-handoff drafts.
CURRENT OUTPUTS
The package records supplied context and manual review. Its conclusions remain advisory until verified by the responsible professionals.
Reviewable Markdown drafts based on saved inputs and deterministic rules.
SYNTHETIC EXAMPLE
An inherited Next.js, Node, and PostgreSQL booking application. The deployed sign-in flow redirects to an error, while local sign-in reportedly works. A README and sanitised deployment summary are available. Test coverage and migration state are unknown. The immediate goal is to determine whether the authentication path can be repaired safely without replacing the booking workflow.
Synthetic supplied-context scenario. Northstar Booking Portal is not a customer, repository, audit, or delivered repair.
Airchor can help make reported evidence, assumptions, gaps, and risk more visible. It does not provide formal technical due diligence, independent code verification, security certification, or a professional guarantee.
The planned platform extends a reviewed finding into an approved AgentTask, isolated execution, independent verification, and a reviewable pull request or preview.
This workflow is planned and is not available in MVP v1.0.
Airchor provides a repeatable Work on Existing Project route for organising supplied client context into a 10-document Assessment & Recovery Plan.
