Tracking Files & the P7 Discipline

Claude Rules Workflow

Chapter 7 · Tracking Files & the P7 Discipline

Rules files describe how content should be generated. A separate, smaller set of files tracks what's actually been generated — and unlike a rules file, a tracking file's whole value depends on staying perfectly in sync with the real state of content/. This chapter covers what each tracking file is for, and a real, concrete example — from this very session — of what happens when that sync breaks.

The Five Tracking Files

completed_courses.md
A chapter-level index of every finished course. Archived into numbered files (completed_courses_1.md, _2.md...) once it grows too large — the current file was closed off and archived once already, at 754 lines.
course_bucket_list.md
Only what's still outstanding. A finished course's entry is removed entirely, never left marked "done" in place — this course's own bucket-list entry was already rewritten this way the moment rules1 stopped being "not yet started."
course_folder_mapping.md
The authoritative prompt-prefix → folder-path map. Every course, including this one, gets a real row here the moment its outline is fleshed out — not deferred until chapter generation begins.
course_name_index.md
A flat prefix → full course name lookup, existing purely to support P11's own rule from Chapter 3 (cross-chapter references use the real course name, never the bare prompt shorthand).

A fifth file, sidebar-pages.md, covers the same job specifically for Sidebar content — already covered in Chapter 6.

P7 Itself

The actual rule is short: when the final chapter of a course is generated, completed_courses.md and course_bucket_list.md both get updated in the same turn — not deferred, not batched up for later. That single word, "immediately," is the entire discipline this chapter is named after.

What Happens When P7 Doesn't Hold: A Real Example

This isn't hypothetical. Earlier this same session, three PHP courses — Fundamentals, Intermediate, and Advanced — were found to have real, surviving combined PDFs, each one looking exactly like proof of a finished course... while the actual chapter HTML behind two of them had been completely lost, and the third had only one of ten chapters left. The tracking files and the real content in content/ had quietly drifted apart at some point, and nothing caught it until a direct verification sweep compared what the mapping files claimed against what actually existed on disk.

The fix mirrored P7's own discipline exactly
Reconstructing all three PHP courses this session ended with the identical step every other completed course gets: course_folder_mapping.md, completed_courses.md, and course_bucket_list.md were all updated in the same turn each course's own final chapter and PDF were finished — not as a separate cleanup task done later, but as the direct, immediate consequence of P7 being followed correctly this time.
A tracking file that says "complete" is a claim, not a fact
The PHP example shows exactly why: course_folder_mapping.md can say a course is finished while the actual chapter HTML genuinely doesn't exist anymore, if the files and the tracking record are ever allowed to fall out of sync. A tracking file is only as trustworthy as the discipline that keeps updating it — which is precisely why P7 insists on "the same turn," not "eventually."

A Worked Example: This Course's Own Future Chapter 10

When this course's own capstone (rules1-10) eventually generates, P4 (Chapter 3) fires the combined PDF, and P7 requires all of the following to happen in that same turn: course_folder_mapping.md's rules1 row gets updated from "10/10 chapters outlined" to "complete"; a new dated section is appended to completed_courses.md naming every chapter; and — since this entry currently sits under a fleshed-out-outline heading rather than "Course Regenerations Needed" — the corresponding section of course_bucket_list.md gets removed entirely, the same way the original stale "Claude Rules Workflow" bucket-list entry was replaced back in Chapter 3's own P9 story.

Coding Challenges

Challenge 1

Explain, using this chapter's own PHP example, exactly what kind of mistake becomes possible when a tracking file is trusted without verifying it against the real content on disk.

📄 View solution
Challenge 2

A course finishes its final chapter, but course_bucket_list.md is left with the course still marked as "in progress" rather than removed, with a plan to "clean it up at the end of the week." Explain specifically which part of P7 this violates, and why "later" isn't an acceptable substitute for "the same turn."

📄 View solution
Challenge 3

Explain why course_name_index.md exists as its own separate file rather than being folded into course_folder_mapping.md, given that both files map a prompt prefix to information about a course.

📄 View solution

Chapter 7 Quick Reference

  • completed_courses.md — chapter-level history of finished courses, archived into numbered files once too large
  • course_bucket_list.md — only what's outstanding; a finished entry is removed, never marked done in place
  • course_folder_mapping.md — the authoritative prefix → folder-path map, updated the moment an outline exists
  • course_name_index.md — prefix → full course name, existing to support P11's cross-reference rule
  • sidebar-pages.md — the same job, for Sidebar content (Chapter 6)
  • P7's actual discipline: update the tracking files in the SAME turn a course finishes — never deferred
  • A real example this session: three PHP courses' tracking files claimed completeness that the actual content on disk no longer matched — found and fixed by verifying against reality, not by trusting the record
  • Next chapter: the auto-memory system, and when it's the better fit instead of a rules file