01 / Project recovery
Inventory the project that actually exists
Begin with the filesystem and manifests, not the prompt that produced them. Identify the primary folder, related repositories, package or solution files, environment templates, Compose configuration, migrations, and the commands that have actually run.
AI-generated code does not need a special project category. It needs an explicit boundary that shows which local folders are operated and released together.
- Keep repositories in their existing locations.
- Give related folders role-based names.
- Separate generated suggestions from commands you have verified.
02 / Project recovery
Make every recurring command reviewable
A command without its working directory and runtime target is incomplete. Record the executable, arguments, folder, and whether it runs on the Windows host or inside a container before turning it into a reusable task.
If several processes form one environment, capture their dependency order and readiness checks. Do not treat one successful launch as proof that the path will remain repeatable after a reboot or dependency change.
- Keep secrets out of visible arguments.
- Start dependencies before consumers.
- Use bounded checks before long-running processes.
03 / Project recovery
Keep evidence from the last real run
Record Git, toolchain, Docker, database, and recent-run state separately. Detecting a framework does not prove that its executable, engine, service, or connection is currently available.
When something fails, retain the exact task, directory, target, exit state, and output. That evidence is more useful than asking a new chat session to guess what changed.
