What Happens to the Documents? (Do We Delete Them?)
We've built the whole thing now: Inception planned the Class Library Loan Tracker, Construction built and tested it, and Operations put it in front of Ms. Sharma and her students. Along the way, aidlc-docs/ filled up with real files — requirements, a code generation plan, aidlc-state.md, audit.md — plus whatever we kept for Operations ourselves.
The feature is done and working. So... do we tidy up and delete the planning documents now that the real code exists?
Short Answer: No — We Never Delete Them
The Inception doc doesn't get thrown away when the app is done. It gets archived alongside the code, not deleted.
Why Keep the Inception Document After the App Is Built?
The code tells you what the software does. It does not tell you why it does it that way. Six months from now, someone (maybe you, maybe a teammate, maybe a future Robo session helping with a new feature) will look at the code and wonder:
"Why can a student only borrow 2 books at a time? Was that a real requirement, or just a random number someone picked?"
Without the Inception document, that answer is lost. With it, the answer is right there: Ms. Sharma asked for it during the Inception review, because books were going missing. That's the whole reason these documents get written in the first place — losing them after the fact throws away exactly the value they created.
Concretely, keeping them helps with:
- Onboarding — a new contributor (human or AI) can read the story of why the system looks the way it does, instead of reverse-engineering it from code.
- Future changes — when Ms. Sharma's due-date reminder idea kicks off a new Inception, that new document can directly reference the original one instead of starting from zero.
- An audit trail — a clear record of what was decided, when, and why, which matters more the longer a project lives.
- Picking up where someone left off —
aidlc-docs/aidlc-state.mdtracks exactly which stages are done, skipped, or in progress. Push it to a shared repository, and a teammate — or a future AI session — can pull it down and continue from your exact spot, instead of starting over or guessing what's already been decided.
So What DO We Do With Them?
We keep them, but we mark them as finished and organize them so they're easy to find later:
1. Update the status line.
Status: Approved — Ready for Construction
becomes
Status: Completed — Shipped in v1
2. Keep them next to the code they describe, so the "story" of a feature stays together:
library-loan-tracker/
├── aidlc-docs/ <- the whole story, kept forever
│ ├── aidlc-state.md <- what's done, in progress, or skipped
│ ├── audit.md <- every decision, timestamped
│ ├── inception/ <- the plan
│ └── construction/ <- how it was built
├── src/ <- the actual application
└── tests/
3. Let version control keep the full history. If the project uses git, every edit from Draft v1 to Approved v2 is already preserved in the commit history — nothing is ever truly lost, only added to. You can always look back and see exactly how the plan evolved.
A Simple Rule of Thumb
| Type of File | Delete? | What To Do Instead |
|---|---|---|
| Scratch notes / a quick throwaway experiment | Okay to delete | Fine to delete once its useful parts are folded into the real document |
Anything in aidlc-docs/inception/ |
Never | Keep it — mark status as Completed |
aidlc-state.md and audit.md |
Never | Keep — the full record of every stage and every decision |
| Operations Notes / incident logs | Never | Keep — genuinely useful for debugging later and for writing the next Inception |
The Full AI-DLC Story, All Together
flowchart TD
I["Inception\naidlc-docs/inception/"] --> C["Construction\naidlc-docs/construction/\n+ real source code"]
C --> O["Operations\nyour own notes, for now"]
O -.-> I
I --> IK["kept forever"]
C --> CK["kept forever"]
O --> OK["kept forever"]
classDef phase fill:#e1bee7,stroke:#7b1fa2,stroke-width:2px;
classDef kept fill:#c8e6c9,stroke:#388e3c,stroke-width:1px;
class I,C,O phase;
class IK,CK,OK kept;
The dotted arrow is feedback becoming the next small Inception — the same loop from the last lesson.
| Phase | Kid Analogy | What You Produce | Do You Keep It? |
|---|---|---|---|
| Inception | Planning the treehouse | An agreed-upon plan document | Always |
| Construction | Building the treehouse, piece by piece | Real source code + a progress log | Always |
| Operations | Living in and caring for the treehouse | Deployment + monitoring notes + feedback | Always |
That's the whole loop: plan it, build it, live with it, learn from it — and keep the record of all three, because that record is what makes the next round faster and smarter than the last.
What's Next
Everything so far has been the concept, told through Robo and a treehouse. The next two lessons switch gears completely: how to actually set this up on a real computer, using AWS's real open-source AI-DLC rules — and the day-to-day habits that make it work well once it's running.
Continue to: Setting It Up For Real