.projectstore / method / 2
The industry invented this long ago.
Agents made it cheap.
ADRs, reviews, a backlog, acceptance criteria, links from goal to code. Mature engineering teams have worked this way for twenty years. ProjectStore invents none of it.
Where each piece comes from
- 1969RFCs: decisions written down and numbered, then discussed in the open.
- 1992DO-178B: in avionics, every requirement must trace to code and to a test.
- 1995Scrum: the work as a backlog, ordered and visible.
- 1999XP: user stories, and acceptance criteria that say when one is done.
- 2007Kanban for software: a board that shows what is in flight.
- 2011ADRs, Michael Nygard: one short file per architectural decision.
- nowCoding agents: every step takes minutes. Without the artifacts, every session starts empty.
One project, many hands. The same ground for all of them.
An ADR says what was decided and what was rejected. A spec says how it must work. An epic and its stories say what is being built and when each part is done. The board shows what is in flight.
With them, an engineer who joins tomorrow, a reviewer from another team and an agent in a fresh session all start from what the first person knew. That is why teams that build large systems have kept these documents for decades.
The process was always valuable. What was expensive was people running every step of it.
The process works. Its documents are the most valuable thing a company keeps after a project: why the system is built this way, what counted as done, where each feature lives in the code. But when people run it by hand, it is slow. An ADR takes an afternoon to write and a week to get reviewed. Documents fall behind the code. The board stops matching reality. So teams cut corners, and "agile" becomes an excuse to write nothing down.
Where the artifacts are missing, it looks the same with people and with agents: settled questions come back, nobody can say why the code is the way it is, and every newcomer starts by guessing.
Agents are the opposite. Writing an ADR, splitting an epic into stories or checking a diff against criteria takes an agent minutes, not days. What an agent lacks is what people get for free: memory between sessions, context shared with colleagues, the link from a goal to the code. Every new session starts empty and decides again what was already settled.
people's process+agents' speed=ProjectStore
ProjectStore puts the two together. Agent speed makes the old process cheap for the first time. Its documents, kept in files beside the code, give agents what they never had: the project's context, linked up to the goals and down to the code. A second agent that did not write the draft reviews each step, by rule. Speed gets a memory, and memory gets a check.
Six stages, by hand and in ProjectStore.
| Stage | The practice and its age | Done by people | In ProjectStore |
|---|---|---|---|
| Decisionwhy | ADR, Michael Nygard, 2011. Before that, architecture boards and design review. | An afternoon to write, a week in the review queue. The rejected alternatives stay in someone's head. | The agent drafts it in a minute. A separate critic looks for weak spots. You approve. The result is a dated file that also records what was rejected. |
| Contracthow | Spec, design doc, RFC. RFCs have been numbered since 1969; design docs are the norm in large companies. | Takes a week to write and is stale by release. Nobody checks that the code still matches it. | A spec lists the expected behaviour as numbered rules. Its checks apply to every story it covers. A story cannot close while its spec is still a draft. |
| Backlogwhat | Product backlog from Scrum, 1995. User stories from XP, 1999. Kanban for software, 2007. | Grooming meetings. The board drifts from reality within a week because it is maintained by hand. | Each story file holds its own status. The board, indexes and link map are built from those files. If they drift, one command rebuilds them. |
| Planwhere | Technical design, impact analysis. The tech lead looks at where this lands in the existing code. | Knowledge of how earlier features landed in the code exists only in the tech lead's head. They are on holiday. | The planner looks at where earlier epics landed in the code. It says where the change belongs and what to reuse. The plan goes into the story. |
| Acceptanceproof | Acceptance criteria, Definition of Done. XP and Scrum, early 2000s. | A QA cycle at the end of the sprint. "Done" by declaration; criteria spot-checked. | The reviewer checks the diff against every criterion and asks for proof: a test, a command that was run, a line of code. No proof, no close. |
| Traceabilitylinks | Requirements traceability. Mandatory in avionics since DO-178B (1992) and in medical software. | An Excel matrix "requirement → code → test" that nobody updates after the second release. | Every story links up to its epic, ADRs and specs, and down to its code. Proof sits under each acceptance criterion. The link map and the code map are generated, so nobody maintains them by hand. |
The links an agent gets for free: from goal to proof
- goalEpicCHECKOUT · why we are doing thisepic:
- whyADRthe decision and the rejected optionsadr: [ ]
- howSpecthe expected behaviourspecs: [ ]
- whatStoryplan and acceptance criteriacode_refs:
- whereCodesrc/billing/cards/ · where earlier epics already live— evidence:
- proofEvidencetests/cards.test.ts:58 · per criterion
The links live in the header of each file, and the proof is a line under each acceptance criterion. The agent fills all of it in as it works. The link map shows what each document connects to. The code map shows where each epic's code lives. A new session, a new model or a new colleague starts from this chain, not from nothing.
Install the projectstore plugin from https://github.com/SmartAndPoint/ProjectStore and set it up for this project.