StaveWørk

Every person and every agent reads the same instructions. A rule file carries the conventions for one area, and the file closest to the code has priority. The set is one, and it does not arrive whole. A rule file names the paths it applies to, so it enters a session when the work touches those paths. A rule file that never enters has no effect, so we measure what a session loads. Each one carries a second file name, so all tools read one file and not two. A guard checks the set after each change. It fails the build when a rule file is missing, and when no parent points to it. Members keep no private copy of the instructions.

The rule files say which conventions apply. A knowledge graph says what enforces them. It records how the parts of the workspace connect, so an agent follows a route to one fact instead of reading a file to find it. The same guard rebuilds the graph after each change, so the graph cannot describe a tree that has moved.

The tasks are unique. The foundation is common.

A request arrives as one sentence, and the sentence carries less than the person means. An agent fills the difference with an invention, so we close the difference with questions first. The answers become a brief, and the brief sets the mode the task runs in.

The mode then selects the assets. An asset is a skill, a rule, or a hook the workspace already holds, and the knowledge graph is the route to it. The agent follows that route instead of reading the workspace to find one. An asset can also name the paths it serves. It then arrives on its own when the work reaches those paths. An asset the workspace lacks is a gap, and the gap goes to Improve.

The brief closes every question about the task. It does not close a question about practice, because nobody in the room settles which library or which version is current. The brief lists those questions instead, and it answers none of them.

A hook reads the first prompt, and it stops a task that declares no mode. So the choice of mode is a mechanism, and not a habit.

The brief states what the person wants. It does not state how the software behaves. That is the spec, and the spec comes after Research.

Research starts from the brief. The brief lists the questions the task cannot settle on its own, and Research answers that list and nothing else. A question the brief does not carry is research nobody asked for, and it costs the same as the research we need.

An agent repeats the content of its training data. Some of that content is old, and some of it is wrong. So every answer names a source, and the higher source wins when two sources disagree. The note also records the claims we tested and rejected, so a later session does not repeat the test.

Each answer changes one document, and a guard holds it there. The spec guard fails a requirement that rests on an outside practice and cites no source. The structure guard fails a convention that carries none. The note stays the parent of both, so a convention cannot outlive the source that set it.

Research also runs without a task. We adopt a language or a tool, and its conventions enter the instruction set before a feature needs them. We write each convention next to the behaviour it replaces. A default the agent already follows gets no convention, because a rule that changes nothing still costs context. A convention that names its paths costs context only in the part of the tree it names. The test stays what the convention changes.

A convention without a source does not enter the instruction set.

Each feature has a spec. The spec states the behaviour and the contract. The team reads the spec more often than any other document, so the spec carries the most discipline.

The spec also states what it does not cover. An agent fills a silence with an invention, so we close the silence in writing.

The keywords stay inside the spec. The instruction set states judgement instead, because an agent follows an emphatic rule too literally. A spec describes the software. An instruction set describes the work.

One guard holds the shape. An agent then drafts the spec, a second agent reads it against the parent, and the author re-issues it. A spec with an open question stays in review. A spec with a closed contract goes to Decide.

If you cannot name the parent document, the scope is invented.

Two measures set the threshold. The first is the cost to undo the choice. The second is how much later work rests on it. A choice goes unrecorded only when both are low, because the next commit undoes it and nothing notices.

A decision record states the price of the choice, and not only the choice. It names what the decision makes easier, and what it makes harder, so a later reader can price it. It names the alternatives we rejected, so nobody argues them a second time. Last it names the signal that would show the decision is wrong. We then reopen the choice on purpose, and not by accident.

A record for every choice teaches a team to skip records. So the threshold is fixed, and a rule states which choices meet it.

The plan lists the steps in order. Each step names the files it changes, the test that proves it, and the requirement it satisfies. A step with no test is either trivial or too vague, and you decide which before you start.

Each step also declares its model tier and its effort. The precision of the plan sets the cost of the work. A step that leaves nothing open runs on a small model, and judgement stays on the largest one.

The shape of the dispatch is a choice with a price, so the plan states which shape it uses. The cost is then a decision, and not an accident.

An executor does not replan. A step that meets an unknown returns to the plan, and the plan changes at the tier that wrote it.

We write the failing test before the code. The guards then run twice. The first run happens after each write, so the error appears next to the keystroke that caused it. The second run happens in the pipeline, so the same rule applies to every person and every tool. We write a guard only for a condition a machine can decide. Judgement stays in prose. A guard that reports a false error teaches the team to ignore guards.

Each document records the content hash of its parent. A parent is any document the work rests on: a parent spec, a decision record, or a research note. A guard recomputes that hash after every change. A change to the parent marks each child document as stale, and a stale document fails the build. The guard then shows the exact difference since the last check. The author reads the difference and signs the document again. So a document does not stay in the workspace and read as current after the design moved under it.

The workflow reports on itself. A report at the end of a session names each file the work changed that the plan does not carry. A second report names the configuration that moved away from its committed state. A mechanism has a trigger, and the trigger can fail while the document stays correct. So we test the mechanism, and we do not test the document alone. A correction that repeats becomes a skill, so the next session starts with the answer. An answer that two tasks needed becomes an asset, so a third task does not research it again. A new model generation starts a review of every instruction we hold. Guidance written for an older model can cost quality on a newer one. The instruction set improves from use. The team does not maintain it by memory.