Projects

A project is a folder with files in it and a standing instruction attached. That is the whole product feature, and the honest version of this unit says so and then spends its words on the one idea underneath.

Term 1 put prompting at the floor of line B: an instruction that binds for one turn and is then gone. A project changes exactly one property of that, and it is worth naming precisely which. Not a capability, not a protocol, not somewhere new for the model to look. A scope change. Some instructions become resident: they enter every turn of a run rather than one.

The mechanism

src/project.ts loads every markdown file under project/ in relative-path order, hashes each one, and concatenates them into a standing instruction. assembleTurn stamps a turn with the hashes it carried, so "the same standing instruction reached every turn" is a checkable claim rather than an assumption. Names would not do: a file can change between turn three and turn four without its name moving.

The receipt

artifacts/04-projects.json, over twenty turns of ordinary registry work:

project: 3 standing file(s), 248 tokens resident per turn

20 turns
  resident     4960 tokens  (248 x 20)
  ephemeral     160 tokens  (the turns' own instructions)
  residency is 96.9% of the run

Residency is not free and its price is not small. Nineteen of those twenty turns had no use for the extraction conventions and paid for them anyway. That arithmetic is the entire reason term 12 caches and term 20 discloses late, and neither argument is available to a reader who has not seen the number once.

Break it first

Four mutations, and what each one costs:

mutation                                tests                  demo
residency never records drift           2 failed | 11 passed   exit 0
load order taken from the walk          1 failed | 12 passed   exit 0
standing charged once, not per turn     1 failed | 12 passed   exit 0
a turn carries only the first file      2 failed | 11 passed   exit 1

Two of those rows are worth reading twice.

The ordering test needed a specific fixture to work at all. A depth-first walk with sorted names produces path order for almost any tree, so the first version of that test passed whether or not the ordering rule existed. It only bites on a layout where the two disagree: a_b.md against a/b.md, where depth-first yields the nested file first and path order yields the underscore first.

The demo stays green when residency stops recording drift, and that is correct rather than a gap. The data really was stable, so a function that lies about stability and a function that reports it agree. The demo re-performs the comparison itself instead of printing what residency claims, which is why the last row exits non-zero: there, the data actually drifted.

Where it overlaps

Line B is instruction packaging and this is its second rung, one scope up from term 1. Term 8 puts the standing instruction in a file the harness reads without being asked; term 14 makes it trigger semantically; term 20 stops loading it when nobody needs it. Line A is context economics, and residency is where a standing instruction becomes a permanent line on the bill.