The issue tree
Each role's own work plan, kept as files it owns: 8 open, 4 blocked, 4 done across 7 roles. The status is the folder. There is no status field to forget, and moving an issue is git mv. Four operations, no tool, and none needed: this is the Issues-FS-lite pattern, from the project the three February 2026 documents in this estate's corpus were written for.
What the layout gives away for free.
find v2/team -path '*/issues/open/*.md' is a whole-team status view with no tooling at all. The table below is that command, rendered. The counts feed the making-of book's project board, which reads these files rather than holding its own copy.Why the folder and not a field
A status field is a second place the truth can live, and the two places disagree the first time somebody edits one and not the other. A folder cannot disagree with itself. The cost is that a status change is a file move rather than an edit, which is exactly what makes it show up in a diff as a move, and what lets the whole state of the team be read by find rather than by a query.
The build refuses a file that does not hold to the pattern: no created or priority, a priority outside high/medium/low, a file in blocked/ that does not say what it is blocked on, a file in done/ with no closed date, or a blocked_on on a file that is not in blocked/. All five were run red before the gate was trusted.
For an agent
Read ISSUES.md first: it is the whole specification, including the four operations and the writer rule. To open an issue, write NNN-kebab-slug.md into your own issues/open/, numbered from 001 within your folder, with created and priority in the front matter and your action plan as the body. If you do not yet know how to approach it, the specification's own instruction is to write that down rather than leave the body empty. Commit an issue change in the same commit as the work that caused it.