A working AI project needs memory outside any single chat window. Models forget, sessions degrade, collaborators arrive mid-stream. Parts II and X gave the answer: durable Markdown context — specifications, tasks, decisions, and operating rules — that any agent or human can read first. This lesson builds that memory for your final project.

Why chats are not memory

Every long AI session follows the same arc from Lesson 9 on context windows: sharp start, crowded middle, confident drift. Fixes compound, specs blur, yesterday's decision gets re-argued. File-based memory breaks the cycle. The essential state lives in versioned files; sessions become disposable. When a window crowds or a branch diverges, you preserve state, start fresh, and have the new session read and orient first.

Six files carry the load. Add Skill files only where they add real value — a repeated procedure worth packaging, not a souvenir from every tutorial:

• README.md — orientation. What this project is, who it serves, where things live, how to run and verify it. The first file any newcomer reads.
• CONTEXT.md — evidence and background. The domain facts, sources, constraints, and links the work depends on. What is true, what is assumed, what is unknown.
• SPEC.md — product and technical requirements. The outcome, users, flows, data shapes, interfaces, acceptance criteria. What "done" means.
• TASKS.md — current work. The small task list with status: now, next, done. The only file that changes daily.
• DECISIONS.md — choices with reasons. Each decision, options considered, reason, date. Prevents re-litigation.
• AGENTS.md — agent operating rules. What agents may read, write, propose, and never do; review gates; stop controls. Pairs with Lesson 90.5.
• Skills — only if valuable. A SKILLS/ file per repeatable procedure (e.g., brief-qa.md, filing-fetch.md) with inputs, steps, and checks. No skill without three real uses.

Each file has one job. README orients. CONTEXT grounds. SPEC constrains. TASKS sequences. DECISIONS remembers why. AGENTS bounds. When a file tries to do another's job — tasks hiding in SPEC, decisions buried in chat — coherence rots.

Clean restarts: the orient-first habit

Teach every collaborator, human or model, the same opening sequence:

1. Preserve — update TASKS.md and DECISIONS.md with what just happened. 2. Start fresh — open a new session or branch for the next unit of work. 3. Read — README, then CONTEXT, SPEC, TASKS, DECISIONS, AGENTS, in that order. 4. Orient — ask the session to summarize the project, the next safe task, and what it must not assume — before it edits anything. 5. Change small — one task, one branch, review, commit.

The orient step is the test. If a new agent can explain the project, identify the next safe task, and name what it must not assume, your memory works. If it invents architecture or rewrites unrelated files, the memory is thin — usually SPEC or AGENTS is vague.

For the running examples: Sonariq's CONTEXT holds tickers, filing sources, and peer lists; its AGENTS file forbids autonomous publishing. The Classroom's SPEC holds lesson structure and editorial checks; DECISIONS records why search beat social as the first route. The launcher's TASKS holds one flow at a time — form, calendar, notify, review — never all four at once.

Exercise: create PROJECT-MEMORY/ and fill it

Create FINAL-PROJECT/PROJECT-MEMORY/ with a concise, current first version of every file. Use these minimum shapes:

# README.md — [Project], [date]
- One-paragraph job (from 90.1): …
- Who it serves / buyer: …
- Repo/file map: …
- How to run + verify locally: …
- Where to ask / who owns: …

# CONTEXT.md
- Domain facts + sources (linked): …
- Assumptions (marked as such): …
- Open unknowns: …

# SPEC.md
- Outcome + first flow: …
- Data shapes / interfaces: …
- Acceptance criteria (testable): …

# TASKS.md
- Now: [1–3 tasks] / Next: […] / Done: […] with dates

# DECISIONS.md
- [date] Decision: … Options: … Reason: … Revisit when: …

# AGENTS.md
- May read: … May write: … Must propose first: … Must never: …
- Review gate + stop control: …

Add a Skill file only if one procedure already repeated three times. Name its trigger, inputs, steps, and verification check.

Finish line: six filled files plus zero-or-more justified Skills, current as of today — complete enough that a new agent can explain the project, name the next safe task, and list what it must not assume.

Verify: open a fresh session, point it at PROJECT-MEMORY/, and ask for the three orient answers without editing. Fix whatever it gets wrong at the source file, not in chat. Then check staleness: every file carries a date; anything older than your last real change gets re-read or rewritten.

Common failure mode: the aspirational archive — long SPECs describing a future company, empty TASKS, DECISIONS with no reasons. Memory earns trust by being short and current. Its mirror is skill-hoarding: a dozen Skill files copied from tutorials, none used. Each unused skill is a lying instruction. Delete it.

What good looks like on day 30

Good memory gets shorter as the project gets clearer. Week one CONTEXT is long because unknowns dominate; by week four the same file is tighter because three unknowns became facts with sources and two became explicit non-goals. TASKS churns fastest — done items accumulate with dates, proving velocity — while DECISIONS grows slowly, one entry per real fork. If README still describes the project accurately after a month of builds and two context restarts, the set works. If every session begins by re-asking what the project is, the set failed regardless of length. Treat the orient test as a standing weekly check, not a one-time exercise.

Check your understanding

1. What belongs in CONTEXT versus SPEC versus DECISIONS — and what breaks when they mix? 2. Why must a new session orient (summarize + name limits) before editing? 3. When does a procedure earn its own Skill file, and when should it stay inline?

Next

Memory makes work coherent across sessions. Lesson 90.4 makes the technical choices equally explicit — the minimum stack with stated permissions, costs, and boundaries.