Recover an unfinished AI project

Begin with an inventory, not an installation

List the repository, archive, live URL, handoff notes, issue tracker, deployment records and database information that are actually available. Record who supplied each item and whether it is current, historical or unverified.

Do not run an unknown repository merely to see what happens. First inspect its manifest, lockfiles, scripts, environment references and deployment configuration. Credentials belong in a separate secret channel, never inside the evidence register.

• Repository or archive location
• Live and staging URLs
• Handoff and requirement documents
• Known data stores
• Named owner for each access gap

Give every source a clear authority level

A product brief may explain intent, a commit can prove code existed, and a live test can prove a behaviour was reachable at one moment. None of those sources proves all three things by itself.

Use simple labels such as source-backed, observed live, test-verified, reported only and unknown. This prevents confident language from replacing evidence.

One feature can have four different states

A feature may have been requested in a chat, partly implemented in code, deployed to a server and still fail its acceptance test. Record each state separately instead of compressing it into a single percentage complete.

For every material feature, link the request, relevant file or route, observed live behaviour and test result. If any layer is missing, say so. An honest unknown is safer than a fabricated completion claim.

• Requested outcome
• Code location
• Live route or process
• Verification evidence
• Current owner

Treat contradictions as work items

When the handoff says a feature is finished but the live route returns an error, preserve both facts. The contradiction itself becomes a defect that must be resolved with evidence.

Prioritise contradictions involving authentication, payments, data durability, permissions and deployment because a polished screen cannot compensate for an unsafe boundary.

Use a disposable environment for unknown code

Run inherited dependencies, build scripts and tests away from production secrets and user data. Prefer a fresh container, worktree or temporary machine with the minimum network and filesystem access required for the check.

Start from the checked-in lockfile and documented runtime. Record every command, version and failure message. If the project only works after an undocumented manual change, that change is part of the defect evidence.

Reduce the failure before repairing it

Find the smallest input, route or command that consistently reproduces the problem. A bounded reproduction protects unrelated behaviour and gives the eventual fix a precise regression test.

Do not disable authentication, security headers or validation globally just to make a test pass. Create a test-specific fixture or controlled local configuration instead.

A checkpoint needs more than a version label

Record the exact commit, migration state, deployment configuration, environment variable names, service versions and public health checks. Store secrets separately and record only their required names and ownership.

For systems with durable data, verify that a backup exists and that its restoration scope is understood before a risky migration. A backup that has never been checked is evidence of intent, not proof of recoverability.

• Commit or archive hash
• Database migration state
• Backup owner and scope
• Health endpoint
• Rollback trigger and command

Freeze the behaviours that must survive

Write acceptance checks for the features that currently work, especially login, owner-only data, payments, file access and background jobs. Run those checks before and after the repair.

The checkpoint protects useful behaviour without pretending the project is complete. Defects and unknowns remain attached to it as part of the record.

Choose the smallest release that changes the outcome

Rank work by user harm, security, data loss, blocked journeys and dependency order. Avoid mixing a recovery fix with an unrelated redesign or new commercial feature; each added concern expands the rollback and verification surface.

For the chosen release, state what will change, what will remain untouched, the acceptance checks and the freeze boundary. Deferred work belongs in the roadmap, not hidden inside a broad completion claim.

Close the release with a handover

After deployment, record the live revision, migration result, health checks, key journeys and rollback availability. Keep failed checks visible until they are resolved or explicitly accepted by the owner.

The recovery cycle ends when the new checkpoint is more trustworthy than the old one—not merely when code has changed.