The step contracts

One file per step. They all have the same skeleton, and they have it on purpose, so that you can compare them and so that, over time, the reflex of reading them becomes automatic: the header with the stretch, the when, the form and the size (mandatory or proportional); what it is for; (1) the required context, named generically; (2) the prompts, in English, each one preceded by a "Before sending the prompt" block (the files and the inputs you have to have made yourself before pasting it, with their content and their minimum state) and followed by the explanation of what I am asking the model for and why each clause is there; (3) the expected result, with its characteristics; (4) the completeness check, which you do without reading code; (5) the warning signs, the symptoms of a badly climbed step.

The English prompts are a single piece, identical in the eight versions of the document; node build/build.mjs extracts them to prompts/ and verifies that no translation has altered them. In the Spanish version each prompt carries its translation alongside, so that the reader can understand it; here the document is already in English, and the explanation under each prompt says what I am asking for and why. What gets pasted to the model is always the English.

I wrote them from what I did in three systems that are in production today; I have not executed them as-is yet. The first project that uses them end to end will correct several of them; that is part of step 23. When a contract cites a real case, it does so with a [Ref. N] mark that links to the references document; the procedure stays clean and the detail is one click away.

Stretches: start-up is climbed once per project; loop repeats with every change; operation once the system is alive. Step 23 returns to step 0 for the next project. The complete timeline, with what happens between one step and the next, is in Part B of the main document.

Step 0 — Can this project be run this way? (step contract)

Stretch: start-up. When: once only, before opening the repository and before anything else. Form: conversation: the agent evaluates and asks; you decide. Size: mandatory in every project, however small. Status: the exclusionary criteria X1 and X2 are closed; the weighted criteria (D1 to D10) I am still calibrating, and I mark them as hypotheses.

What it is for

Do not get into a project where the method cannot work. If the agent is not going to be able to verify itself end to end, or if there is no domain owner who decides, the method degrades into "programming with AI" and you end up reading code. This step is the entrance door: it is crossed once, and if it cannot be crossed, better to know it before than after.

And a background idea I want you to be clear about: the method does not work for every project, and that is not a defect. A method that promises to work for everything is saying nothing. What this step does is put the boundary in writing, so that the decision to go in or not is a decision and not a hope. The two exclusionary criteria come from projects I turned down, not from the ones I accepted Ref. 46.

1. Required context

What follows is the generic list. The concrete files you have to have made before each prompt, with their content and their minimum state, are in section 2, in the "Before sending the prompt" block that precedes each one.

Named generically; the agent evaluates whether it is enough and asks for what is missing.

• Survey of the request: what the client wants, for whom, and what happens today without the system.
• Technology survey: what technology exists or is proposed, whether there is a previous system, whether that system has a repository and how it is managed.
• Testability survey: whether the screens can be driven by a program and whether every element of the interface is accessible with its different methods (click, type, read its state), so that a test can walk the screen and verify the effect in the backend.
• Who the domain owner is and how much time they have to decide.
• What consequence an error has (money, health, operations, nothing).
• Environments and access: whether there will be a test environment, whether the agent can reach it, whether production can be queried read-only.

2. Prompts

The prompts are in English, which is the language in which models follow instructions with the most precision and the fewest tokens. In the Spanish version each prompt carries its translation; here the document is already in English. Below each prompt is the explanation of what I am asking for and why each clause is there. What you paste to the model is the English.

Opening:

What I am asking for: that it read the two inputs (the survey and the criteria sheet); that before answering it evaluate whether the survey is enough and, if it is not, ask instead of assuming (this is the central clause of every prompt in the method); that it fill in the sheet with the source of each answer, so that it can be traced later; that it mark the exclusionary criteria green or red; and that it not decide, because eligibility is decided by me. The last line asks it to reply in my language, because the prompt is in English but the conversation does not have to be.

Closing:

What I am asking for: that it leave the decision written with date and owner (step 6), with the conditions if there are any, and with the trail of questions and answers, which is the evidence that it assumed nothing.

3. Expected result

A file docs/ELIGIBILITY.md (or whatever name your project uses), one page long, with:

• Date and who decided.
• The two exclusionary criteria with their answer and their source:
• X1: there is an accessible repository managed in a standard way (or the project is new).
• X2: the interface can be driven by a program and every element is accessible with its different methods, with verification of the effect in the backend.
• The weighted criteria, each with answer, source and weight (once the weight is calibrated).
• The decision: go, no-go, or go under conditions, with the conditions written down.
• The questions the agent asked and the answers, so that the trail remains.

4. Completeness check (you do it, without reading code)

• Do the two exclusionary criteria have an explicit answer and a source? If either is red, is the decision "no-go", or does it carry a condition that resolves it?
• Is any criterion answered with "I suppose so" or "probably"? If there is one, the step is not climbed: the agent had to ask.
• Is the decision written with a date and a name?
• Are the conditions (if any) verifiable? ("Have read access to production before step 3" is; "the client cooperates" is not.)

5. Warning signs

• The agent filled in the whole sheet without asking a single question. Either the survey was perfect (it never is) or it assumed.
• The decision is "go under conditions" and there are more than three conditions. It is probably a "no-go" nobody wants to say out loud.
• Criterion X2 was answered "yes, with a little work". If the screens cannot be driven by a program today, that "little work" is the whole project.

Step 1 — The working agreement (step contract)

Stretch: start-up. When: once only, immediately after eligibility; revised when a hard lesson demands it. Form: one shot, with one adjustment round from you. Size: mandatory in every project. It is the cheapest step of all and the one that prevents the most frustration.

What it is for

Put in writing, before the first line of code, how you and the agent are going to work. It looks like a formality and it is not: it is what prevents the agent from "helping" by expanding the scope, leaving debt for later, or reporting as done what it believes it did. In my tool this file is called SQ.md (quality standards); the name does not matter, the content does.

Think of it this way: the agent is a new collaborator who arrives every morning with no memory of yesterday. The agreement is what you tell them on the first day, and what they will reread every day. If you do not write it down, you will have to say it every time, and you will say it differently every time. I wrote it for the first time when I had spent two weeks repeating the same things in every session Ref. 1, and nothing I put in it was new in systems engineering; what was new was having to write it for someone without memory.

1. Required context

What follows is the generic list. The concrete files you have to have made before each prompt, with their content and their minimum state, are in section 2, in the "Before sending the prompt" block that precedes each one.

• None from the project: it is the first file.
• From you: your working preferences (language, how you want to be asked, what you consider a waste of your time, what level of autonomy you give the agent).

2. Prompts

Opening:

What I am asking for: the six minimum rules, each with the failure it prevents (that is what makes them rules and not advice); that it propose rules of its own for the project but mark them as proposals, so that you accept or reject them; and that it ask whatever it needs to know about you. An agreement drafted without a single question is suspicious: the agent does not know the person it is going to work with.

Closing:

What I am asking for: that it close the agreement with a date and a version, and that it hook it into the project file so that it is read in every session. Without that hook the agreement exists but does not act.

3. Expected result

A file docs/WORKING_AGREEMENT.md (or SQ.md, or CONTRATO.md) with:

• Date and version.
• Each rule numbered, in one or two sentences, with the failure it prevents.
• The project's own rules, marked as such.
• A line at the foot saying that the agent proposes changes but does not edit the agreement on its own.

And a line in the project file (PROJECT.md or CLAUDE.md) ordering it to be read at the start of every session.

4. Completeness check

• Are the six minimum rules there, each with the failure it prevents?
• Is any rule written as an aspiration ("try to…", "whenever possible…")? If there is one, it is useless: rules are either followed or not.
• Does the project file order it to be read in every session?
• Did the agent ask you at least one question about how you work? If it drafted everything without asking anything, it is suspicious: it does not know you.

5. Warning signs

• The agreement has more than twenty rules. Nobody, neither human nor model, follows twenty rules; six or eight get followed.
• A rule says "the agent may modify this agreement when it considers it necessary". No.
• Two weeks later, the agent does something the agreement forbids and nobody notices. The agreement is not being read: check the hook in the project file.

Step 2 — The project definition, the semantic tree and mandatory reading (step contract)

Stretch: start-up. When: written once, after the agreement; the semantic tree and the living state are kept up to date throughout the project, with every block and every new decision. Form: conversation: the agent drafts, asks for what is missing, you correct. Size: mandatory in every project. In a small one the project file can be fifty lines and the semantic tree twenty nodes; what they cannot do is not exist.

What it is for

Every session of the agent starts from zero: it does not remember yesterday. Give it a map, a short one, that tells it what the project is, what state it is in and what decisions have already been made, and force it to read the map before touching anything. The failure it prevents is twofold: throwaway work from not reading the map Ref. 9, and the map that grows until it becomes unreadable Ref. 41. The practical rule: the project file is the programme, not the history. What happened goes somewhere else.

The map has two pieces, and the second one does the most work. The first is the project file: what the system is, for whom, what it is NOT, the decisions made. The second is the semantic tree: the system broken down as a tree, with the domains, and under each one its actors, its processes (the use cases), its entities with their states, its screens and its integrations; and hanging from each node, the pending items and the decisions that touch it. The tree comes out of the survey you did with the classic methods of requirements engineering (interviews, use cases, domain model), the agent builds it, you correct it, and it is what gives the model the exact context of the node it is going to touch without having to read the whole project. And it is what lets you verify, without reading code, that the system the agent understands is the one the business asked for.

1. Required context

What follows is the generic list. The concrete files you have to have made before each prompt, with their content and their minimum state, are in section 2, in the "Before sending the prompt" block that precedes each one.

• Business survey: what the client does, who uses the system, what problem it solves, what it must not do. With the interviews, the use cases or user stories you can name, and the business entities with their states, even if they are incomplete.
• The working agreement (step 1).
• If there is a previous system: read access to its code or its documentation.
• The decisions already made, if any, even if only spoken.
• The words the business actually uses for each thing, and who the different types of person who are going to use the system are. They are the two prior inputs of Annex H, and this step is where they get written: without them, the profile matrix of step 8 gets invented and the usability rules have nothing to compare against.

2. Prompts

Opening:

What I am asking for: that it evaluate the survey and ask before drafting; that the project file be short (the three-hundred-line cap is arbitrary but necessary: without a cap, it grows); that it say explicitly what the system is not, because what is left unsaid is what the model is going to invent; that the decisions carry a date; that it build the semantic tree with the full structure (domains, actors, use cases with their parts, entities with states and transitions, screens, integrations), which is the domain model of requirements engineering put in the shape of a tree; that it mark what it inferred, because that is where the inventions hide; and that it separate the living state into another file, so that the map does not turn into history.

And the two prior inputs of Annex H, which are what keeps step 2 from being only a map for the model. The user glossary is the list of words people actually use: "appointment", not "agenda booking"; "the front-desk girl", not "operational user". It is for two things that come later: naming the menu groups with user jobs, and making the text on the screens say what people say. The list of profiles is who each one is and what they come to do, and it is the column the matrix of step 8 comes from; if it is not written here, at step 5 it gets invented, and an invented matrix is the cause of somebody seeing a button that is not theirs. I explicitly ask it to ask for them rather than deduce them, because they are data of the business and not of the system; and to mark what it inferred, for the same reason as in the tree.

Closing:

What I am asking for: your corrections (above all to the nodes it marked as inferred), the date, and two new rules in the agreement: the one that protects the project file from becoming history, and the one that ties every pending item to a node of the tree, which is what keeps the tree alive and what lets you spot an out-of-scope pending item in ten seconds.

3. Expected result

• PROJECT.md (or CLAUDE.md): short, mandatory reading, with what it is, for whom, what it is not, modules, decisions with dates, and the order to read it together with the tree. Three hundred lines at most.
• docs/SEMANTIC_TREE.md: the semantic tree, with the inferred nodes marked until you confirm them, and, from the first block onwards, the pending items and decisions hanging from their nodes.
• docs/STATUS.md: living state, separate from the previous two.
• The two prior inputs of Annex H, written and named in PROJECT.md: the user glossary (the words people actually use for each thing) and the list of profiles (who each one is and what they come to do), with whatever was inferred marked. The method does not impose the names of those two files on you -- use the ones your project uses --; what it does demand is that they exist, that they can be found from the project file, and that they are there before step 5.
• In all three, a date of last update.
• In the agreement, the two new rules.

4. Completeness check

• Does PROJECT.md fit in a five-minute read? If not, it is wrong: it is the programme, not the history.
• Does it say explicitly what the system does NOT do? (What is missing is what the agent is going to invent.)
• Walk the semantic tree as if you were the client: are all the actors you know there? Does each entity have the states the business uses, no more and no less? Is there any node you do not recognise? That one is an invention: correct it now.
• Are the inferred nodes marked? Did you confirm or correct all of them?
• Does each decision have a date and who made it?
• Did the agent ask anything about the business before drafting? If it asked nothing, check what it assumed.
• Is the living state in another file?
• Is the user glossary written, with the words people actually use for each thing? Read it and look for a word you would not say: if it is there, the system wrote it and not the business.
• Is the list of profiles written, saying who each one is and what they come to do? Count the profiles on the fingers of your business: if one is missing, a row of the matrix of step 8 is missing, and a batch of manual test cases of step 10.
• The reading test: close the session, open a new one, and ask it what the system does NOT do and which node of the tree a given screen hangs from. If it answers with the map, the hook works.

5. Warning signs

• The project file grew more than 20 % in a month. Something that is not programme is getting in.
• The agent starts a session proposing something that was already decided and written down. It did not read the map: the mandatory-reading hook failed.
• The "what it is not" section is empty or says "nothing in particular". Every system has boundaries; if they are not written down, the model is going to cross them.
• There are pending items that do not hang from any node of the tree. Either the tree went stale or those items are out of scope; both things have to be looked at.
• An entity in the tree has a state the business never named. The model invented it because it seemed logical, and it is going to build on top of it.
• The user glossary has the same words as the semantic tree. That is not a user glossary: it is the vocabulary of the system copied twice. Ask the business what they call it.
• The list of profiles has a single profile, "user". It almost never is true, and it is the most common way to arrive at step 8 with a one-row matrix that protects nothing.

Step 3 — Size before designing the architecture (step contract)

Stretch: start-up. When: once, after the definition and before building the skeleton; redone if the business changes scale. Form: conversation: the agent computes and presents options; you choose. Size: always mandatory, but proportional: in a small project the sizing can be half a page and a single decision ("it fits in SQLite for years"). What it cannot be is skipped, because the question "how much is it going to grow?" costs five minutes and the wrong answer costs weeks.

What it is for

Make the structural decisions —which database engine, whether the interface is synchronous or asynchronous, how much concurrency— with numbers and not with taste. It is the step that costs the most to skip, and I say so from experience: in one of my systems I started with JSON files and when I measured it turned out it was going to generate 3.4 million rows per year; changing the interface afterwards cost a whole stage of re-engineering Ref. 15.

There is a key point worth keeping in mind: there is data that only the business has (how many entities, how many events per entity, how many operators at the peak, how much has to be kept) and the model cannot infer it. What it can infer is what is derived. That is why the prompt requires it to evaluate whether the primary data is complete and to ask for what is missing, instead of estimating it with a straight face. The one who knows what it lacks in order to compute is the model, not a form.

And a second idea I want you to take away: asymmetric decisions. There are decisions that cost very little if you make them and they turn out unnecessary, and a great deal if you do not make them and they turn out necessary. The asynchronous persistence interface from line one is the canonical example: if the engine ends up synchronous, one await was superfluous; if it ends up asynchronous and you did not plan for it, everything has to be rewritten. Make those decisions whenever they are cheap, even if they are not needed today.

1. Required context

What follows is the generic list. The concrete files you have to have made before each prompt, with their content and their minimum state, are in section 2, in the "Before sending the prompt" block that precedes each one.

• Volume data survey of the business, named generically: main entities and their growth, events per entity, simultaneous operators and peak hours, data retention time, exceptional loads (campaigns, closings), expected growth. The survey is incomplete by nature; the agent evaluates and asks.
• If there is a previous system: read access to its database to get real numbers instead of estimates.
• PROJECT.md and the semantic tree (step 2): the entities in the tree are the ones to size.

2. Prompts

Opening:

What I am asking for, clause by clause: distinguish primary from derived (it is the distinction that prevents the invention); ask for the missing primary figures and never estimate them; use real numbers from the previous system when there is one, with their source; compute what is derived with the arithmetic in plain sight, so that you can redo it; the "times ten" scenario, which is what reveals what breaks first; three options with the cost of migrating between them, because the decision is not only "which one" but "how much does it cost to be wrong"; and that it neither choose nor write code, because this step is about deciding, not building.

Closing:

What I am asking for: the complete record, with sources and arithmetic; the chosen option and the reason; and the asymmetric decisions written down, because if they stay implicit they are not respected.

3. Expected result

A file docs/SIZING.md with:

• Date and who decided.
• Table of primary data: value, source (reported by the business / measured in the previous system), date. None with source "assumption".
• Table of derived data: value, which primary figures it comes from, the arithmetic.
• The "times ten" scenario: what breaks first.
• The three options, numbered, with the cost of migrating between them.
• The chosen one and the reason, in one or two sentences.
• The asymmetric decisions, listed.
• The questions the agent asked and the answers.

4. Completeness check

• Is there any primary figure with source "assumption" or with no source? If there is, the step is not climbed: the agent had to ask for it.
• Does each derived figure show which primary figures it comes from and with what arithmetic? Can you redo one calculation by hand and get the same result?
• Are there three options and one chosen with a written reason?
• Does it say what happens if the volume is multiplied by ten?
• Are the asymmetric decisions written down, or did they stay implicit?
• Did the agent ask? If it presented numbers without having asked a single question, be suspicious.

5. Warning signs

• The three option scenarios lead to the same conclusion. The agent had already chosen and built the other two to comply.
• A derived figure has more precision than the primary figures it comes from ("1,234,567 rows" from "about 5,000 families"). The precision is false.
• The "times ten" scenario says "nothing happens". Something always happens; if it did not find it, it did not look.

Step 4 — The skeleton with its gates (step contract)

Stretch: start-up. When: once, at the close of the start-up stretch, after the sizing and before any functionality. This is where all the initial infrastructure and the integration and deployment pipeline get built. Form: one long shot, with your visual approval at the end. Size: mandatory in every project that is going to have users. In a throwaway prototype it can be skipped; but if the prototype survives (they always survive), this step is the first thing that has to be paid for.

What it is for

Make the system start, test and deploy EMPTY before it has any functionality. Discovering deployment at the end is hugely expensive: in one of my systems it arrived a month after the start and cost five pending items in a row Ref. 32. If the skeleton is deployed during start-up, those blows land with zero functionality at stake.

The general idea behind it: the path to production is part of the product, not a formality at the end. A system that works on the programmer's machine and cannot be deployed is not a system; it is a demo. And the only way to know the path works is to walk it while there is still nothing to lose. That is why this step sets up everything the loop is going to use later: the repository with its structure, the test environment, the continuous integration that runs the test suite on every push, and the automatic deployment to the test environment.

1. Required context

What follows is the generic list. The concrete files you have to have made before each prompt, with their content and their minimum state, are in section 2, in the "Before sending the prompt" block that precedes each one.

• docs/SIZING.md (step 3): the chosen option defines the skeleton.
• Environments survey: where it is going to run (cloud, own server), whether there is a test environment and a production one, who has access, how it is deployed today if there is anything.
• The credentials of the place where it is going to be deployed, even if it is a free service.
• The kind of project: new, correction, or evolution of something existing.

2. Prompts

Opening:

What I am asking for: that it verify it has the access before starting (without that the skeleton stays on the agent's machine); the exact list of what a skeleton is (structure, start-up, one test, continuous integration, deployment to test); the gates written down; a real screenshot of the test environment, which is the only valid evidence that it was deployed; and the explicit prohibition on adding functionality, because the model tends to "while I am at it" and that breaks the exact scope.

Closing:

What I am asking for: leaving the three commands where the next session will find them, and proving that the deployment is repeatable (running it twice without breaking anything). That second run is the proof that the procedure is a procedure and not luck.

3. Expected result

• The repository with the structure, the server and the screen starting up.
• A smoke test in green and the test suite running in continuous integration (with the link to the green run).
• The deployment to the test environment working, with the URL, and run twice.
• docs/GATES.md: the list of gates, each with the condition to pass.
• A screenshot of the empty system running in the test environment.
• docs/STATUS.md updated with the three commands (run, test, deploy).

4. Completeness check

• Can you open the URL of the test environment and see the empty screen? (You do it, not the agent.)
• Is there a link to a green continuous-integration run?
• Was the deployment run twice, and did the second run break nothing?
• Are the gates written down, each with a verifiable condition?
• Is there any functionality you did not ask for? If there is, the agent violated the exact scope.

5. Warning signs

• The skeleton "works locally" but the deployment "we will see later". No: the deployment is the skeleton.
• The screenshot is from the agent's machine, not from the test environment. Ask for the URL.
• The gates say things like "the code has good quality". A gate is a verifiable condition: "the test suite is green", "the deployment to test worked".

Step 5 — The plan is the pending items: the detailed specification lives in each one (step contract)

Stretch: loop. When: the register is created when the first functional block opens, as soon as the start-up ends; every new block starts by turning the client's request into specified pending items; the routine is used in every session throughout the project; the documentation of the finished item is written when it is closed, in the same session. Form: one shot when opening each block; afterwards, a routine of every session. Size: mandatory in every project. It is the step that makes all the others traceable: without numbered, specified pending items there is nowhere to hang either the specification or the evidence.

What it is for

Have a single work queue, ordered and gated, that is the truth of the project. There is no "plan" on one side and "tasks" on the other: the list of pending items IS the plan. It prevents the long specification that gets overtaken in two weeks and becomes obsolete Ref. 17, and the work nobody knows why it was done Ref. 7.

But there is more, and it is what distinguishes this step from any old task list. In the classic method there was a requirements specification document, a long one, that described everything the system had to do and that aged before it was finished. Here that document is decomposed: the detailed specification lives in each pending item. A well-written pending item carries: the node of the semantic tree it hangs from; the user story or use case that originates it, in the client's words; the detailed description; the applicable business rules, with their decision and date; the data in and out; the screens affected, with the prototype if there is one; the edge cases and exceptions; the acceptance criteria in the form "given, when, then"; and how it is verified. The sum of the pending items is the specification of the system, and traceability (requirement → pending item → test → commit) is not a separate matrix: it is the pending item itself.

And the third thing, which closes the circle: closed pending items are documentation. When a pending item is closed, it is neither deleted nor filed empty: it stays with its specification, the decision that originated it, the evidence it was closed with (the red and green counts, the screenshot, the measured number), the commit and the date. The queue of closed pending items is the functional history of the system: what was built, why, when and how it was tested. From there come the changelog, the new sections of the manual, and the answer to "why does the system do this?" six months later.

1. Required context

What follows is the generic list. The concrete files you have to have made before each prompt, with their content and their minimum state, are in section 2, in the "Before sending the prompt" block that precedes each one.

• The client's request for the block, in prose, just as they would say it, with its ambiguities. If you wrote use cases or user stories during intake, better: they are the natural unit of a block.
• The semantic tree (step 2), to hang each pending item from its node.
• The audits and the findings of human testing, if there have been any.
• PROJECT.md and docs/STATUS.md.

2. Prompts

To open a block:

What I am asking for: that it turn the request into verifiable items and that it ask when the request is not enough to write a verifiable one (ambiguity is resolved by asking, not by choosing); the complete specification of each pending item, field by field, which is classic requirements engineering decomposed into small units; the node of the tree it hangs from, which is what lets you spot an out-of-scope pending item; the business rules with their decision or marked as missing, which is the hook into step 6; the acceptance criteria in the classic form, which are the script of the end-to-end test of step 8; and a proposed order with its reason, so that you confirm it or change it.

Routine of every session (goes in the working agreement):

What I am asking for: the discipline of every session: announce what is being taken and reread the specification (the agent starts without memory, and the specification is its memory of the pending item), cite the pending item in every commit, close with evidence, document the finished item in the same register, and log instead of doing whatever shows up outside the list. That last clause is the one that protects the exact scope when the model "sees something more".

3. Expected result

docs/PENDING.md (or whatever tool your project uses) with, per pending item:

• Number, title, status (open / in progress / closed), opening and closing date.
• The node of the semantic tree.
• The story or use case of origin, in the client's words.
• The detailed specification: description, business rules with decision and date, data, screens, edge cases, acceptance criteria, how it is verified.
• On closing: the evidence, the commit, the date, the decisions taken along the way.

And the routine in the working agreement.

4. Completeness check

• Read the specification of a random pending item as if you were the client: does it describe what you asked for, in your original words? Are the acceptance criteria the ones you would use to say "that is right"? Is there an edge case you know of that is not there?
• Does each pending item hang from a node of the tree? Is any hanging from a node you do not recognise?
• Does each pending item say how it is verified? A pending item without verification cannot be closed.
• Are there business rules marked "missing, asked" that nobody asked you about?
• Are there "closed" pending items without evidence or commit? If there are, reopen them. Do the closed ones keep their specification and their closing documentation?
• Take three commits at random: do they cite their pending item?
• Did something show up in the code that has no pending item? That is where the agent stepped out of scope.

5. Warning signs

• A pending item has been "in progress" for more than three sessions. Either it is three pending items, or it is stuck on a decision nobody made (step 6).
• There are more pending items closed in a day than commits that day. They are being closed without evidence.
• The specifications are one line long. The agent wrote them to comply, not to build on them; it is going to invent what is missing at build time.
• The list has more than fifty open pending items. That is not a plan, it is an inventory of anxieties: prioritise and archive.
• Someone asks why the system does something and the answer is in no closed pending item. The documentation of what was done is not being written.

Step 6 — Decisions are written next to the code (step contract)

Stretch: loop. When: in every session of the loop, every time the agent runs into an unwritten business rule or a fork that changes what the user sees. There are usually two or three per block. Also during start-up (steps 0 and 3) and at go-live (14 and 15). Form: short conversation: the agent detects that there is a decision, asks, and leaves it written down. Size: mandatory in every project. In a small one the register can be a ten-row table; what matters is that the business rules have an owner.

What it is for

Make every business rule and every structural decision have an owner, a date and a place. If not, in six weeks nobody knows whether "approved plus balance goes back to the queue" was a decision of the client or an idea of the agent. And avoid the worst: the agent inventing domain rules because they seemed reasonable.

This has a consequence I want to say out loud: the model, when it runs into a gap in the rules, fills it. It does not stop; it completes with what seems most likely to it, and it does so with the same naturalness with which it writes everything else. That is why the routine of this step is not "write down the decisions" but "stop and ask when one is missing". The second is the hard part, and it is what has to be demanded in the agreement. The practice of leaving the rule written in the commit, with my words and the date, I imposed at the Health Fund Ref. 29, and the practice of freezing decisions before building comes from my tool Ref. 5.

1. Required context

What follows is the generic list. The concrete files you have to have made before each prompt, with their content and their minimum state, are in section 2, in the "Before sending the prompt" block that precedes each one.

• The conversation with the owner: it is the only context. The agent cannot decide business rules.
• An agreed place where decisions are written: the commit message, the pending item's specification, and a register docs/DECISIONS.md.

2. Prompts

Routine (goes in the working agreement):

What I am asking for: that it stop at an unwritten rule or a visible fork; that it ask with a recommendation and an alternative (so that you decide in ten seconds, not ten minutes); that it record the decision in your exact words in the three places (the commit, the pending item, the register), not in an "improved" paraphrase; and, for when you do not answer, the most reversible option marked "by omission", which is what allows moving on without the decision disappearing.

Closing (each decision):

What I am asking for: the minimum format of a decision: the exact rule, who, when. Three things; without any one of the three it is not a recorded decision.

3. Expected result

• docs/DECISIONS.md: one line or one paragraph per decision, with date, who decided, the exact wording, the pending item or commit where it was applied, and whether it was "by omission".
• In the specification of each affected pending item: the rule with its decision and date.
• In every commit that implements a business rule: the sentence of origin.

4. Completeness check

• Open three commits that touch business rules: does each cite who decided and when?
• Are there "by omission" decisions still unconfirmed? Confirm them or revert them; do not leave them.
• Is there any rule in the system you do not recognise as yours? If there is, the agent invented it: it is a failure of the step, it is written up as a pending item and reviewed.
• Are the sentences exact or "improved" by the agent? They have to be yours.

5. Warning signs

• A week of work went by and the decisions register did not grow. Either the work was purely mechanical (rare) or the agent decided on its own.
• The recorded decisions are all written in the same polished style. They are paraphrases by the agent, not your words.
• A user of the system asks "why does it do this?" and nobody can find the decision.

Step 7 — Measure before building, with an instrument that is itself verified (step contract)

Stretch: loop. When: every time a pending item depends on a number or on a hypothesis about a cause, BEFORE building. In the start-up stretch, sizing is the first case. In a small project, "measuring" is counting with a command and writing the number down with its date. Form: one shot per measurement; sometimes a conversation, when the hypothesis is yours. Size: proportional. The ratchet and the query budget are for systems with volume. What does not change with size: no number that decides anything comes from an impression.

What it is for

Make every number that feeds a decision come from a program with a test, and not from a text search, from an impression, or from "I think there are about a hundred". And make the instrument itself get audited, because meters lie: one of mine did not see 84 calls with the counter at zero, and another said 27 when there were 44 Ref. 35, Ref. 36. The five rules I wrote after that are: a guarded meter; if the instrument does not exist, it gets built; it is audited in both directions; what is approximate gets marked; and the one who executes verifies the numbers of the one who planned.

This is the step that took me longest to formalise, and for a reason worth telling: I took it for granted that a model would apply on its own something as basic in engineering as "measure before touching". It does not. The model is very good at producing claims with a number in them ("there are about 120 loops of that kind") and those claims sound exactly the same when they have been measured and when they have been estimated. You have no way of telling them apart by the tone. The only way is to demand the instrument: "what did you measure it with? show me the command". If there is no command, it is an impression, however many decimals it has. I imposed the rules myself in session, correcting the agent, before they became doctrine Ref. 45.

1. Required context

What follows is the generic list. The concrete files you have to have made before each prompt, with their content and their minimum state, are in section 2, in the "Before sending the prompt" block that precedes each one.

• The hypothesis, yours or the agent's: "I think the problem is X", "there must be about a hundred".
• Access to what is to be measured: the code, the database read-only, the log.
• The meters that already exist in the repository, if there are any.

2. Prompts

Opening:

What I am asking for, clause by clause: the meter in the repository (not a loose command that gets lost); the meter's test against a known case (the guard); the completeness clause in its form for measuring (ask for the access, do not approximate silently); mark what is approximate with its margin; the number with the command that produces it, so that you can run it; the audit in both directions, which is what unmasked my two lying meters; and the order: first measure, then propose.

When there is a budget:

What I am asking for: that the budget be the measured value plus a little, not a round number, and that it has a test that fails if it is exceeded. That way a performance regression shows up in the test suite and not in production Ref. 37.

When the one who planned gave numbers (rule five):

What I am asking for: that the one who executes does not trust the numbers of the one who planned, even if it is the same model in another session. In my case, three of the four claims in the plan were wrong; where there was an instrument, the number was exact.

3. Expected result

• The meter in the repository (tools/measure_*.py, scripts/meter-*.mjs or similar), with its test.
• The number, with the command that produces it and the date.
• The two-direction audit, written in two or three lines.
• What is approximate marked as such, with its margin.
• If there is a budget: the value, the margin, and the test that protects it.
• In the commit: "measured: [number] with [meter]".

4. Completeness check

• Can you run the meter's command yourself and get the same number? (You run it; you do not need to understand it, only to execute it.)
• Does the meter have a test? Against which known case?
• Is there any number in the report without a meter behind it? Ask where it came from.
• Is what is approximate marked?
• If the plan carried numbers, did the agent verify them before executing and tell you which did not match?

5. Warning signs

• A number changed between two reports without the code changing. One of the two was not measured.
• The meter reads zero. It is almost never zero; it is almost always that the meter is not seeing something.
• The agent proposes to build "while measuring", to save time. The order is the method: first the number, then the plan.

Step 8 — Tests as locks, proved red (step contract)

Stretch: loop. When: with every pending item, when closing it: the test red and green, the regression of the neighbours and the end-to-end test of the flow touched. The complete end-to-end suite of every flow, at the close of each block and before every deployment to production. Form: one shot; the agent executes and reports, you read the report. Size: mandatory in every project. It is the heart of the method: if there is one step that cannot be negotiated, it is this one.

What it is for

A test you never saw fail, you do not know whether it proves anything. The rule here is not "write tests": it is "demonstrate that the test turns red against the old code, and then green with the new one". It prevents the tests that pass because they prove nothing, and the green that hides a bug Ref. 44.

Why this matters more with a model than with a human programmer: the model writes the code and the test in the same session, with the same understanding. If it misunderstood the request, the test is going to test what it understood, and it is going to pass. The red against the old code is the only cheap way to check that the test is looking at what matters: if the old code passes it, the test does not tell before from after, and so it is useless. The case that shows it best is the one of the counters that did not match Ref. 26.

There is a serious objection to this step, and I want to leave it written down because people are going to use it against it: the same agent that writes the test and the code can fake the red. A study published in August 2026 measured that, when an agent is asked for the test-first cycle, it sometimes skips the red, reports it without having run it, or implements before the test so that it passes from the start (it is in Part F of the main document, the one on related work). My answer has three pieces, and all three are on the ladder. The first one, here: the red is not a story, it is a receipt: the exact command, the identifier of the version it ran against, the count of failing tests and the exit code, all pasted as they came out, so that you can run it again with a single command without understanding what it does. The second, in step 13: the audit by another session reruns a sample of those receipts. The third, in step 9: mutation testing, which plants bugs on purpose and counts how many of them the tests catch; it is the only measure that, in that same study, told the tests that watch from the tests that decorate.

And the second half: the end-to-end tests. A test that verifies from the screen (clicks, types, reads) and checks the effect in the backend (the row is there, the state changed) is the one that replaces your reading of the code. The acceptance criteria of the pending item ("given, when, then") are its script. And they run three times at three scales: the flow touched with every pending item, every flow at the close of each block, and every flow with the exact version before production.

1. Required context

What follows is the generic list. The concrete files you have to have made before each prompt, with their content and their minimum state, are in section 2, in the "Before sending the prompt" block that precedes each one.

• The change already implemented (by default tests come after implementing; "test first" stays as an option for small, well-defined scopes).
• The pending item that originates the change, with its acceptance criteria and its "how it is verified".
• The existing test suite and the command to run it (step 4).

2. Prompts

Routine (goes in the working agreement; applied on every change):

The red of the first block. In the first block of a new project there is no previous code: the new test fails because the module does not exist, and that failure does not prove the test tells behaviour apart. So, when the previous version does not have the module, the red is proven by mutation: the agent plants a deliberate defect in the function it just wrote, shows the test red against that defect (the receipt carries the diff of the defect, so you can see it was not trivial), reverts it and shows the green. One mutant per pending item, run and recorded like any other receipt; mutation testing over the whole codebase stays the optional reinforcement of step 9. (Decision D-037, from the Turnera practice: six red receipts that only said "the file does not load".)

What I am asking for, clause by clause: (1) the test, guided by the acceptance criteria of the pending item; (2) the red demonstrated as a receipt (command, version, counts, exit code), which is the clause that distinguishes this method from "write tests" and the one that keeps the red from being a story; (3) the green; (4) the regression of the neighbours in the same session, because a change breaks things next to it; (5) the end-to-end test of the flow touched, with the backend effect in plain sight; (6) not mocking the very thing being tested; and the completeness clause adapted to this step: if something is missing to test end to end, ask for it, do not simulate it. The commit message with the counts leaves the evidence where the code lives.

At the close of each block and before every deployment to production:

What I am asking for: the second and third scales of the end-to-end tests, with the exact version (not "the latest"), with the backend effect per flow, and with the completeness clause: what is not covered is declared and becomes a pending item, it is not passed off as covered.

When the agent says it cannot be tested:

What I am asking for: that "it cannot be tested" not be the end of the conversation but the beginning of a pending item. Non-testability is debt, and debt gets recorded.

3. Expected result

• The new test in the repository, named after the pending item it closes.
• In the agent's report and in the commit message: the red output as a receipt (the command, the version it ran against, how many fail, the exit code), the green output, and the regression in green with its counts.
• The end-to-end test of the flow touched, with the evidence that the backend changed (the row, the record, the state).
• At the close of each block and before production: the complete end-to-end suite in green, per flow, with the exact version.

4. Completeness check

• Does the report show the red? With numbers: "4 of 8 fail against the old criterion". If it only shows green, the step is not climbed.
• Is the red a receipt or a story? It has to have the exact command, the version it ran against, the counts and the exit code. Once per block, pick a pending item at random and run that command yourself: the red has to show up again.
• Did the regression run in the same session? How many tests, how many green?
• Is any part "mocked" right where the change is? Ask the agent what it mocked and why.
• Does the commit cite the pending item and say "proved red"?
• Does the screen test also verify the effect in the backend?
• At the close of the block: are all the flows in the end-to-end suite, or is there one that "is covered by the unit tests"?

5. Warning signs

• Every new test of the week passed green on the first try, and no red was ever shown. Either the agent is skipping the step or the tests prove nothing.
• The test suite takes longer and longer and nobody knows why. It is usually that the end-to-end tests were being replaced by mocks "so that it runs fast".
• The agent reports "the tests pass" without saying how many. Always with numbers.
• The red comes told in prose ("the test failed as expected") with no command, no version and no counts. A red without a receipt is worth the same as none.
• You reach go-live and the complete end-to-end suite runs for the first time. The block closings were missing.

Step 9 — Code quality verified by machine, with a gate (step contract)

Stretch: loop. When: it is set up once, when the first functional block opens (as soon as the start-up stretch finishes), and from then on it runs on its own on every commit, as a gate of continuous integration; every pending item is closed with quality green, after the red test (8) and before the manual test case (10). At the close of every block and before every deployment, the quality report is read with the owner. In a legacy system, the first run is the baseline and the findings enter the backlog with their speed mark. Form: one shot to set it up; afterwards, a routine of every change and a reading per block. Size: mandatory at its minimum level in every project (a linter and a size limit in the chain); complete, mutation testing included, in any project with users. Mutation testing stays an optional reinforcement only when there are no real users (an internal tool, a prototype nobody else runs).

What it is for

The owner does not read the code, and that is the point of the method. But the code exists, somebody is going to maintain it (the next agent, the next developer), and code that works today and is unreadable tomorrow is debt that gets charged in month three. If nobody reads it, a machine has to look at it: tools that, on every commit, measure what a human reviewer would look at and turn it into a number with a limit. I did this in all my projects, without naming it as a step, and a quality audit handed me back a component of more than two thousand lines and a project file of almost ten thousand Ref. 41: neither of the two would have passed a written size limit. The static ratchet, which prevents a quality number from getting worse Ref. 35, is the shape I give this step.

What gets measured by machine, in order of importance: that the code respects a single style (the linter and the formatter); that no function and no file goes over a size; that the complexity of each function stays under a limit; that there is no duplicated code and no dead code; that the dependencies are declared and used; that the coverage of the tests never drops (the ratchet); and, if the language allows it, that the types close. None of this replaces the red test: impeccable code can be wrong. What it prevents is correct code that nobody can ever touch again.

And the piece I stop treating as an optional reinforcement in any project with users: mutation testing. I left it as "optional, recommended" in an earlier version of this document, and an outside evaluation of the method pointed out the contradiction: if Part F says mutation is, as far as I know, the only measure that in the 2026 studies told the tests that prove apart from the tests that decorate, it makes no sense to leave it out of "complete" exactly in the projects where one more decorative test hurts someone. A tool plants bugs on purpose in the code (changes a "greater than" into a "greater than or equal", deletes a line, flips a condition) and runs the tests; every bug the tests do not catch is a surviving mutant, and the proportion caught is the score. It is the measure that complements the demonstrated red of step 8: the red proves that one test watches today's change; mutation measures how much the whole suite watches. And it is, as far as I know, the only one that in the 2026 studies told the tests that prove from the tests that decorate (Part F of the main document).

If you are a beginner. A linter is a program that reads the code and marks what is badly written or dangerous (a variable that is not used, a comparison that always gives the same result), like the spell checker of a word processor. A formatter arranges it with a single style (indentation, spaces) so that all the code looks as if it were written by the same hand. The complexity of a function is how many different paths it can take (every "if" increases it); a function with forty paths is understood by nobody. Duplicated code is the same block copied in two places: the day one of them is fixed, the other one stays wrong. Coverage is what percentage of the code is executed by some test. And a ratchet is a mechanism that only lets things improve: today's number is tomorrow's floor. Mutation testing is a program that breaks the code on purpose, one small change at a time, and looks at whether any test notices; if none does, that piece of code is not being watched.

1. Required context

What follows is the generic list. The concrete files you have to have made before each prompt, with their content and their minimum state, are in section 2, in the "Before sending the prompt" block that precedes each one.

• Continuous integration running on every push (step 4).
• The first functional block open, with at least one pending item built: without code there is no quality to measure.
• Your decision about the limits, or the willingness to accept the ones the agent proposes, with a reason.
• The previous audit (13, or N3 in a legacy system), if there was one.

2. Prompts

Opening (setting up the gate):

What I am asking for: the five checks a human reviewer would do, done by machine and with the build in red as the consequence, because a check that does not block is a piece of advice; the limits with their measured value, so that the limit comes out of the number and not out of an opinion; the coverage ratchet, which is the piece that keeps quality from degrading on its own; and not fixing anything yet, because in a system with code already written the first run always comes out red and the decision about what gets fixed now and what gets tolerated with a date is mine.

Routine (goes in the working agreement):

What I am asking for: that quality be part of the close of every pending item and not a separate task; the ban on silencing (a model facing a red linter tends to add the exception instead of fixing, because it is faster) and on raising the limit; and the reading per block, which is the only moment when you look at the numbers.

Mandatory in any project with users (optional only without real users): mutation testing.

What I am asking for: the measure that coverage does not give (coverage says which code was executed; mutation says which code is being watched); the scope narrowed to the lines changed, which is what makes the cost payable on every pending item; not fixing anything yet, because deciding which mutant matters is mine; and the score at the close of every block, next to the coverage, with a drop treated as red.

3. Expected result

• The linter, the formatter, the limits, the detection of duplication and dead code, the coverage with its ratchet and the types, running on every push and red when they should be.
• docs/CODE_QUALITY.md with tools, configuration, limits with their measured value, and the list of what fails with its pending item or its date.
• The gate in docs/GATES.md and the routine in the agreement.
• In any project with users: the mutation score in docs/CODE_QUALITY.md, per block, next to the coverage, and a pending item for every surviving mutant in code that matters.

4. Completeness check (you do it, without reading code)

• Ask it for the link to the last run of the chain: is quality green?
• Ask it to put, on purpose, on a branch, a function of a hundred lines and an unused variable: does the chain go red for both things?
• Is today's coverage greater than or equal to the one at the close of the previous block? Ask for both numbers.
• Are there any linter exceptions in the code? Ask for the list; each one has to have a written reason.
• Did any limit go up since the first run? With what reason and who decided it?
• If the project has real users: is mutation testing running? If not, what written reason justifies not having it?
• If there is mutation testing: how many mutants survived in the last block, and does each one have a pending item or a written reason?

5. Warning signs

• Quality passed green on the first try on code already written. It is almost never true: the limits are too loose.
• The agent proposes "disabling this rule because it is too strict". Sometimes it is right; it always has to go through you with the reason written down.
• Coverage goes up because tests that prove nothing were added (the green that hides a bug, step 8). The ratchet measures quantity; the demonstrated red measures quality. They go together.
• A file grew up to the limit and was split into two files with the same content. That is duplication disguised as compliance.
• Coverage is high and the mutation score is low. Those are tests that execute the code without verifying anything: the exact case the demonstrated red of step 8 tries to prevent.
• The project has real users and nobody ran mutation testing or wrote down why not. "It is optional" stopped being a valid reason for a project with users.

Step 10 — Manual test cases are written together with the functionality, and people execute them (step contract)

Stretch: loop. When: with every pending item, when closing it, after the red test (8) and quality (9): the agent writes the manual test cases of the flow it touched. They are executed by people at three moments: at the close of every block (the human tests), before the first deployment to production (the acceptance tests with the owner), and after every deployment, in a read-only pass. Every execution that fails reinjects a requirement into the loop as a corrective pending item. Form: a routine of every pending item; afterwards, human execution per cycle. Size: mandatory in every project with users: the manual test case is the only test the model neither writes nor runs.

What it is for

The method has automated tests to spare: the red test, the regression, the end-to-end on three scales. The model writes and runs all of them, and all of them test what the model understood. What is missing is the test a person does with their own eyes and their own hands, following a written script, and which finds what no test finds: the button that is where it should not be, the message that cannot be understood, the flow that technically works and humanly is useless. The human view and the human tests were already in the timeline; what was missing was that they have a script, and that the script be written by the same one who built the functionality, at the same moment, out of the acceptance criteria of the pending item. Without a script, the human test is "play with the system for a while", and what gets found depends on the mood of the day. With a script, it is executed the same way every time, what happened gets recorded, and what fails comes back into the loop as a requirement. It is the closing of the circuit that the process diagram shows: the manual execution of the test cases reinjects requirements into development.

A manual test case always has the same shape: an identifier; the pending item that originates it; the precondition (what has to exist beforehand: a patient, an appointment from yesterday); the steps, numbered, each one with what the person does and what they must see; the expected result at the end, including the backend effect a person can verify (a record that appears, a message in the fake inbox); the test data to use; and the space for the result of each execution: date, who, passed or failed, observation.

If you are a beginner. A manual test case is a recipe for a person to test a piece of functionality: what to prepare, what to do step by step, and what has to happen at each step. It is written so that anyone can follow it the same way, without knowing how the system is built. To execute a case is to follow the recipe and write down whether it passed or failed. A precondition is what has to exist before starting. And to reinject means that whatever the person found wrong comes back to the list of pending items as a new request, in their words.

1. Required context

What follows is the generic list. The concrete files you have to have made before each prompt, with their content and their minimum state, are in section 2, in the "Before sending the prompt" block that precedes each one.

• The pending item that is being closed, with its "given, when, then" acceptance criteria (step 5): they are the raw material of the case.
• The test environment with data, so that the steps can really be followed.
• Who is going to execute the cases (the owner, a trusted user) and when (close of block, acceptance, after every deployment).

2. Prompts

Routine of every pending item (goes in the working agreement):

What I am asking for: that the case come out of the acceptance criteria (so that it tests what was asked for, not what the model understood); that it be written for somebody who does not know how the system works, which is the difference between a test case and a technical note; that it include the backend effect verifiable by a person, so that the manual test also looks at the other side of the screen; that the cases be maintained in the same commit, just like the documentation; and that the model never execute them, because executed by the model they are one more test, and the whole point is that a person executes them.

For an execution (close of block, acceptance, after a deployment):

What I am asking for: the reinjection made operative: every human failure is a corrective pending item, with the person's words (not the model's) as the reproduction, and hanging from the tree; the comparison with the previous execution, which is what tells you whether the system improves or degrades between blocks; and the distinction between "the case is badly written" and "the system is wrong", which are two different pending items.

3. Expected result

• docs/MANUAL_TESTS.md with one case per flow touched by every closed pending item, in the format, written for a person.
• The executions recorded, with date and who, in every cycle.
• One corrective pending item for every failure and for every observation.
• The routine in the agreement.

4. Completeness check (you do it, without reading code)

• Take a case at random and follow it yourself in the test environment without asking the agent anything: could you? If you had to ask, the case is not written for a person.
• Does every closed pending item that touches a screen have its case? Ask for the list of pending items without a case.
• Does the case say what effect to verify on the other side of the screen, and how a person verifies it?
• Does the last execution have a date and a name in every case? Is there any "passed" without a date?
• Does every failure of the last execution have its pending item, with the person's words?

5. Warning signs

• The agent marked the cases as executed. It executed them, which is the same as not executing them.
• The cases are copies of the automated test in prose. A manual case has to look at what the test does not look at: what is seen, what is understood, what is annoying.
• All the cases pass in every execution. People always find things; if they find nothing, they are not following the script or the script does not ask them to look.
• The failures get "fixed" on the spot, without a pending item. The person's words and the trail of what repeated get lost.

Step 11 — Producer/consumer symmetry, and the anti-pattern register (step contract)

Stretch: loop. When: with every pending item that touches a contract between two parts of the system. The map of contracts is built when the second functional block opens, once there is a screen and a server. The anti-pattern register grows every time something breaks for the second time. Form: automatic inside the loop; plus a file that grows with every blow. Size: symmetry is always mandatory; the producer/consumer map is optional in a single-module project, and mandatory as soon as there is a screen and a server that are separate.

What it is for

When you change one end (the server, the robot, the database schema), make the other end (the screen, the counter, the consumer) change in the same commit. If you do not, sooner or later they diverge, and the user sees one number on one side and another number on the other Ref. 26. And the mistakes you have already paid for once, write them down so you do not pay for them twice Ref. 2.

The general principle behind this, which I imposed at the Health Fund and which holds for every system Ref. 27: every list has a single owner. The columns of a table, the possible states of an order, the reasons why something is waiting: one single part of the system (the producer) defines them and all the others read them from there. As soon as there are two copies of the same list, one of them is out of date; the only thing left to find out is which. The semantic tree of step 2 is the first place where those lists are declared: the states of an entity are there, and the code has to read them from a single source.

1. Required context

What follows is the generic list. The concrete files you have to have made before each prompt, with their content and their minimum state, are in section 2, in the "Before sending the prompt" block that precedes each one.

• A map of which parts of the system consume what: which screens read which services, which processes write which tables. If it does not exist, the first prompt builds it.
• The anti-pattern register docs/GOTCHAS.md, even if it is empty.

2. Prompts

To build the map (once):

What I am asking for: the inventory of contracts with their two sides, and the completeness clause in its form for this step: what cannot be seen is declared, not omitted. A map with hidden holes is worse than no map at all.

Routine (goes in the working agreement):

What I am asking for: symmetry as a reflex (look for the other side before closing), the rule of the list with a single owner, and that the map maintains itself as it gets used.

When something breaks for the second time:

What I am asking for: the fixed format of an anti-pattern (smell, root cause, fix, early detection) and, above all, the automatic check: an anti-pattern that is written down but not automated will repeat itself when the person or the session changes.

3. Expected result

• docs/PRODUCER_CONSUMER_MAP.md: the list of contracts with producer and consumers.
• In every commit that touches a contract: the consumers updated, named in the message.
• docs/GOTCHAS.md: one entry per anti-pattern, with the four parts (smell, root cause, fix, how to detect it beforehand), and the date of the first time.

4. Completeness check

• Pick a contract from the map and ask the agent to show you where each consumer reads it. If any of them keeps its own copy of the list, there is debt.
• Is there a number that is shown on two different screens? Compare: do they match?
• Does every GOTCHAS entry have the four parts?
• Did a mistake that was already in GOTCHAS repeat itself? If so, the automatic check is missing.

5. Warning signs

• The same value appears hand-written in more than one file ("PENDING", "APPROVED" on the server and on the screen). Two copies; one will diverge.
• A change to the server was closed with the server test green and nobody touched the screen.
• GOTCHAS has entries without the "how to detect it beforehand" part. Those are anecdotes, not anti-patterns.

Step 12 — Honest verification and proportional reporting (step contract)

Stretch: loop. When: in every report, of every pending item, throughout the whole project. It is the shape that everything the agent tells you has to have. Form: routine; it is the shape every report from the agent must have. Size: mandatory in every project, without exception. It costs nothing and it is what lets the owner not read code.

What it is for

If you are not going to read code, the agent's report has to be reliable. Not optimistic, not "complete in appearance": reliable. This is the genuinely new thing about the method: the author of the code also manufactures the evidence, and does so with the same confidence in its voice when it is right and when it is wrong. That is why the evidence has to prove itself, and the report has to separate what was verified from what is believed. I wrote the rule in June Ref. 8, and I needed it again in October, when an authentication error was reported with the label "success" Ref. 43.

Understand why the model tends to over-report. It is not bad faith: it is that it was trained to be useful and complete, and a report that says "I could not verify this" feels less useful than one that says "done". So ask it explicitly for the bad news, the blind spots and what it did not do. If you do not ask, it does not give it to you, not because it hides it but because it does not consider it part of the answer.

1. Required context

What follows is the generic list. The concrete files you have to have made before each prompt, with their content and their minimum state, are in section 2, in the "Before sending the prompt" block that precedes each one.

• The work done and the pending item that asked for it.
• The working agreement (step 1), which already forbids announcing what was not done.

2. Prompts

Routine (goes in the working agreement; applies to every report):

What I am asking for, clause by clause: the three blocks, which are the structure that makes a report honest (what was verified with its proof, what is believed with the reason why it was not tested, what it cannot see); coverage item by item, so that nothing "gets forgotten"; the proof next to every claim; the ban on a bare "done"; and the bad news first, because the model tends to leave it for the end or for never.

When you say "it is still broken":

What I am asking for: that faced with an "it is still broken" it does not diagnose again from scratch but first compares versions. Half of the "still broken" cases are fixes that are in the repository but not in the place where you are looking Ref. 45.

3. Expected result

Every report from the agent with:

• The three blocks (verified / believed / blind spots), even if one of them is empty.
• One line per item requested, with its status.
• For every "verified": the command and the output, or the test and its result, or the number and its meter.
• What went wrong, at the beginning and not at the end.

4. Completeness check

• Are the three blocks there? If "believed" and "blind spots" are always empty, the agent is not being honest: there is always something it did not see.
• Pick a claim from the "verified" block at random: does it have its proof next to it? Can you reproduce it?
• Does it cover every item you asked for, or is there one that "got forgotten"?
• Is the bad news at the beginning?
• Did it ever say a bare "done"? That is a breach of the agreement.

5. Warning signs

• Ten reports in a row without a single blind spot. Nobody sees everything; the block is empty out of habit, not out of truth.
• The "verified" block has phrases like "it should work". That is "believed" in disguise.
• The report is longer than the change. A proportional report says what needs to be said; an inflated one is covering something up with volume.

Step 13 — The periodic audit as input to the plan (step contract)

Stretch: going live. When: mandatory before the first deployment to production; it opens the go-live stretch. Afterwards, in operation, every one or two months depending on the pace of change, and at the close of every large stage. Form: one long shot, ideally to an agent different from the one that builds. Size: mandatory before the first deployment to production, in any project; afterwards, proportional to the pace of change (a system that changes every week is audited every month; a stable one, every six).

What it is for

Look at the whole system with fresh eyes every so often, and turn what you see into pending items. The audit is not a report that gets filed: it is plan. It avoids the password written into the code that nobody had seen, the queries that read whole tables Ref. 18, the known vulnerability in a dependency, the component of thousands of lines Ref. 41. And it is the independence of quality control taken one step further in: the one who audits is not the one who built.

On independence: you do not need another company or another tool. Another session, with another instructions file, that did not take part in the construction is enough. What you are after is that the auditor does not share the builder's assumptions. A model that built a module "knows" that the hardcoded password was provisional; a model that sees it for the first time reports it as what it is. That is how two administrator doors that the builder had left in a single day were detected Ref. 40.

If you can choose, make it also a different model from the one that built, not just another session of the same one: a 2026 study measured that a clean session with a different model finds more errors than two sessions of the same model (arXiv 2610.01471). It is not a hard gate, because sometimes the builder's model is the only one available; it is a preference worth exercising when you can, and the more critical the system, the more worth exercising it.

1. Required context

What follows is the generic list. The concrete files you have to have made before each prompt, with their content and their minimum state, are in section 2, in the "Before sending the prompt" block that precedes each one.

• The complete repository, read-only.
• Production or the test environment, read-only (database, logs).
• The previous audit, if there was one, to measure what changed.
• The scope: integrity, security, performance, code quality, or all of them.
• docs/PENDING.md with the pending items closed in the last cycle and their receipts, so the auditor can pick which ones to reproduce.

2. Prompts

Opening (to an agent different from the builder, if possible):

What I am asking for, clause by clause: read-only (the auditor does not fix; it proposes); the completeness clause in its form for auditing: what could not be verified is declared, not approved by omission; all of the code and not a sample, because the serious findings are usually where nobody looks; the literal reproduction of two or three receipts, so the audit verifies evidence instead of just reading it (this is the clause that closes the D-033 gap: a red that is told is not a red that is audited); every finding with location, risk, evidence and priority, so that it is actionable without re-reading the report; grades per dimension, to compare with the previous audit; and the P0 findings already turned into proposed pending items.

Closing (to the builder):

What I am asking for: that the audit turns into pending items (otherwise it is a report that gets filed), and that disagreement be explicit and backed by evidence, not silent.

3. Expected result

• docs/AUDIT_[date].md with: the scope, what could be verified and what could not (and why), the findings with location, risk, evidence and priority, a grade per dimension, the result of reproducing two or three receipts from the last cycle, and the list of proposed pending items.
• In docs/PENDING.md: one pending item for every P0 and P1, citing the finding.

4. Completeness check

• Does the report say what it could NOT verify? If it says it verified everything, be suspicious.
• Pick two findings: do they have file and line, and evidence you can reproduce?
• Does the report say which receipts it reproduced, with the command and the result, or does it only say it read them?
• Does every P0 have its pending item open before the audit is considered closed?
• Will the grades per dimension be comparable with the previous audit?
• Did the same agent that built also audit? If so, ask for a second look at the P0 findings.

5. Warning signs

• The audit found no P0 at all. In a system more than three months old, that is almost never true; more likely the scope was small or the auditor shared the assumptions.
• The findings have no file line. They are opinions, not findings.
• The report says the receipts "were reviewed" without showing the command that ran or its output. A receipt that was read and one that was reproduced are not the same, and only the second one closes the D-033 objection.
• Two weeks went by and the P0 findings still have no pending item. The audit got filed.

Step 14 — Fail-closed, locks and zero silent harm (step contract)

Stretch: going live. When: in the go-live stretch, BEFORE building any functionality that charges, sends, approves or deletes; revisited with every new consequential action. New automations start in dry-run mode and are enabled after watching their log for a few days. Form: conversation: the agent lists the consequential actions, you confirm which ones get a lock and of what kind. Size: mandatory as soon as the system does anything irreversible (charging, sending, deleting, approving). A read-only system can skip it; the moment it gains its first button that acts on the world, this step becomes the most important one.

What it is for

Make the system, when in doubt or on failure, NOT act, and say so. It sounds obvious and it is the opposite of what software does by default, which when in doubt carries on. It avoids the double charge, the automatic approval that never went past a human, the git add -A that uploads a credential, and the deletion of the client's data. The locks I put in at the Health Fund are the model: the panic button with a double safety, the auto-approver in dry-run mode, the watchman with guards Ref. 28; and the reflex that a failure leaves a row without its button instead of breaking the whole listing Ref. 25.

The principle has a name, "fail-closed", and it comes from physical security: a security door that stays shut when the power goes out. The opposite, "fail-open", is the door that opens. In software most things are fail-open by default: if the validation fails, the code carries on; if the service does not respond, everything is assumed to be fine. The method inverts the default: when in doubt, no. And it applies both to the system and to the agent that operates it.

1. Required context

What follows is the generic list. The concrete files you have to have made before each prompt, with their content and their minimum state, are in section 2, in the "Before sending the prompt" block that precedes each one.

• Survey of consequential actions, named generically: what the system does that charges, sends, approves, deletes, or notifies someone outside; what happens if it is done twice; what happens if it is done wrong; how it is undone. The business knows it; the agent evaluates whether the list is complete and asks. The semantic tree helps: every consequential process is there.
• Which actions the agent itself can take on the system (if it is embedded).

2. Prompts

Opening:

What I am asking for: the cross-check between what the business said and what the code does (that is where the actions nobody remembered show up); the completeness clause in its form for this step: the differences between the two lists are asked about, not resolved; for every action, reversibility, lock and way back; and the general fail-closed rule written into the prompt, so that it ends up in the table and in the code.

Closing:

What I am asking for: the test per lock proved red (without the lock, the action happened; with the lock, it does not), which is step 8 applied to safety; the final table; and the dry-run rule for every new automation, which is what lets you see what it would have done before letting it do it.

3. Expected result

• docs/LOCKS.md: one row per consequential action: what it does, whether it is reversible, the lock, the way back, who approved it and when.
• One test per lock, proved red, which verifies that when in doubt the action does not happen.
• New automations starting in dry-run mode, with the log of "would have done".
• If the agent is embedded: its permissions written down (what it can read, what it can change, what requires approval).

4. Completeness check

• Is every action that charges, sends, approves or deletes in the table? Think of one that is not there and ask.
• Does every lock have its red test? ("Without the lock, the action happened; with the lock, it does not.")
• Does every irreversible action have a written way back? If it does not, it needs a double safety.
• Did the new automations start in dry-run mode? Did you see the "would have done" log before enabling them?
• What happens if the embedded agent tries something outside its permissions? Ask it to try and show you the rejection in the log.

5. Warning signs

• An automation went from "does not exist" to "runs on its own" without a dry-run period.
• The log has no entry at all of "action not executed due to doubt". Either the system never doubts (impossible) or when it doubts it carries on.
• A lock can be skipped with a parameter "for testing". That parameter will end up set in production.

Step 15 — Continuous integration, environments, secrets and deployment as part of the product (step contract)

Stretch: going live. When: the integration chain and the deployment to the test environment are set up in step 4. The closing towards production — the real environment, secrets on the server, promotion, tested rollback, lock against secrets — is done in the go-live stretch, after the audit and the locks. The routine of every deployment applies throughout operation. Form: one shot to set it up; routine for every deployment. Size: mandatory in every project with users. In a small one, "continuous integration" can be a single GitHub action and "environments" can be two folders on the same server; what is not negotiable is that the tests run on their own, that the configuration is not in the repository, and that there is a rollback.

What it is for

Make reaching production a reproducible package: the tests run ONCE, the configuration lives outside the repository, and the secrets are not floating around. It avoids the tests run three times per commit and the burned quota Ref. 39, the deployment hardened one pending item at a time because it was discovered late Ref. 32, and the secrets pasted into the chat Ref. 42.

On secrets there is a rule to adopt as a reflex, with no exceptions: a secret that was seen in a chat, in a log or in a commit is no longer a secret. It does not matter whether "nobody saw it" or whether "it was deleted afterwards". It gets rotated. Rotation costs ten minutes; finding out whether somebody used it is impossible.

1. Required context

What follows is the generic list. The concrete files you have to have made before each prompt, with their content and their minimum state, are in section 2, in the "Before sending the prompt" block that precedes each one.

• Survey of environments and access, generically: which environments there are (test, production), where they run, who has access, how something is promoted from one to the other, which secrets exist and where they live today, how much continuous integration quota there is. The agent evaluates whether it is enough and asks.
• The skeleton with its continuous integration and its deployment to test (step 4).

2. Prompts

Opening:

What I am asking for, clause by clause: the access before starting; the tests a single time per commit (running them three times is what burned the quota); the deployment that only packages; the configuration outside the repository; promotion as a repeatable procedure; the rollback tested, with its data plan (a rollback that was never tested does not exist, and a schema or data migration does not get undone by reverting the commit); the lock against secrets in commits; and the documentation for a person, which is step 20 applied to infrastructure.

Routine of every deployment:

What I am asking for: the three preconditions (test green with the same version, rollback ready, configuration changes announced) and the two checks afterwards (the version running and an end-to-end check without writing anything).

If a secret showed up in the chat or in a commit:

What I am asking for: immediate rotation, an inventory of everywhere else it was, and the check that would have detected it, so that next time it does not reach the chat.

3. Expected result

• Continuous integration running a single time per commit, with the link to a run.
• The deployment that waits for the integration and only packages; measured: how long it takes before and after.
• The configuration outside the repository; in the repo, only an example without values.
• docs/DEPLOYMENT.md: how to deploy, promote and roll back, step by step, for a person.
• The rollback tested at least once, with its evidence.
• The anti-secrets check active (an attempt to upload one, rejected).
• A record of the continuous integration quota consumed per month.

4. Completeness check

• How many times does the test suite run per commit? It has to be one. Ask for the link.
• Is there any real configuration value (a key, a password, an internal URL) in the repository? Ask the agent to search and show you the empty search.
• Could you follow docs/DEPLOYMENT.md on your own, without the agent? Read it with that question in mind.
• Was the rollback tested? When? What evidence is there?
• If there was a schema or data migration: is there a written plan to undo or compensate it, besides the code rollback?
• Was any secret pasted into the chat during the project? If so, was it rotated?
• Do you know how much continuous integration quota is left this month?

5. Warning signs

• The deployment to production is done "by hand, quickly, because it is a small change". Small changes are the ones that break production, because nobody tests them.
• The configuration example file has values that look real. They probably are.
• Nobody can say when the rollback was last tested.
• A migration changed data or schema and "the rollback" being talked about is only the code's. For that migration there is no rollback: there is, at best, a plan to compensate it.

Step 16 — Total observability and traceability, with a configurable level (step contract)

Stretch: going live. When: in the go-live phase, after step 15 (there is already a deployment chain and configuration per environment) and before the performance tests (19), because without observability the performance tests do not say what broke. In a legacy system, the minimum level (structured log records with a configurable level and a correlation id) goes into the safety belt (N4); the complete level, here. The rule that "every new module logs and propagates" applies throughout operation. Form: one shot; the agent builds it and demonstrates it; you read one real trace. Size: mandatory at its minimum level in every project that is going to have users; complete in any project with consequences.

What it is for

When something fails in production, and it will, I want to be able to follow an action from the screen to the database and to every external call, with a single identifier, without opening the code and without asking the agent to "have a look". And I want to be able to raise the level of detail of the log records in production, in a minute, without redeploying, and lower it afterwards. That is observability: seeing what the system does. And the second thing is traceability: that every consequential action (charged, sent, deleted, approved) leaves a trace of who, when, what, from where and with which outcome, in a record the application cannot edit. Without this, the resident agent of step 23 operates blind, the monitoring of steps 21 and 22 has nothing to feed on, and every incident is diagnosed with hypotheses instead of with evidence. The orphan turn that stayed alive for an hour and forty-three minutes was found through the log, not through the code Ref. 16; and the resident agent started, precisely, by reading logs Ref. 13.

"Configurable level" is the clause that distinguishes this from "putting in logs": the level (error, warning, info, debug, trace) is changed by configuration on the server, per environment, without touching code and without deploying, and production runs at info except when something is being investigated.

If you are a beginner. A log record is a line the system writes every time it does something: "10:42:13, scheduling module, user reception1, appointment 17 cancelled". Structured means that every line has the same parts in the same order, so that they can be searched by machine. The level is how much detail is written: at "error", only what failed; at "trace", every step. The correlation id is a unique number given to each action when it starts (you pressed "cancel") and that travels attached to everything that action provokes (the query to the database, the message to the patient), so that afterwards you search for that number and the complete story appears. And the audit trail is a list, which cannot be edited, of the important actions: who did what and when.

1. Required context

What follows is the generic list. The concrete files you have to have made before each prompt, with their content and their minimum state, are in section 2, in the "Before sending the prompt" block that precedes each one.

• The deployment chain and the configuration per environment (step 15): the level is configured there.
• The table of locks (step 14): every consequential action is an entry of the audit trail.
• The initial survey with the personal data marked: the log records cannot contain them.
• Where the log records and the metrics are going to live (a rotated file, a service): you decide.

2. Prompts

Opening:

What I am asking for: the five pieces, and two demonstrations that are the evidence of the step: one real identifier followed through every layer (if it cannot show that, the propagation is broken somewhere) and the level changing without deploying (if you have to deploy, it is not configurable). The audit trail of consequential actions has to be immutable from the application, because a trace the application can delete is not a trace. And the masking of personal data goes in the same prompt because the log records are the place where most personal data leaks without anybody deciding it.

Routine (goes in the working agreement):

What I am asking for: that the observability does not degrade with every new module, which is what always happens if it is not a rule: the module of month three logs nothing and it is exactly the one that fails.

3. Expected result

• Structured log records with a level configurable per environment, changed without deploying.
• A correlation id in every record, propagated from the screen to the database and to the external calls.
• An immutable audit record of the consequential actions.
• Health and metrics endpoints or files, documented.
• No personal data in the log records.
• docs/OBSERVABILITY.md and the routine in the agreement.

4. Completeness check (you do it, without reading code)

• Ask it for the identifier of a real request and search for it yourself in the log records: does it appear on the screen, in the backend, in the database and in the external call, if there was one?
• Raise the level to debug in the test environment, do an action, look at the records, lower it. Did you have to deploy? Then the step is not climbed.
• Search for a test name or phone number in the log records: it must not be there.
• Do a consequential action in the test environment (cancel, send to the fake inbox): did it end up in the audit trail with who, when, what and outcome?
• Is docs/OBSERVABILITY.md enough for you to find a record on your own at three in the morning?

5. Warning signs

• The agent shows "logs" but each module writes in a different format. It is not structured; nobody is going to be able to search them.
• The identifier appears in the backend but not in the external calls or in the scheduled jobs. Those are exactly the places where incidents get lost.
• The production level was left at debug "for now". The disk fills up and data leaks.
• The audit trail of consequential actions lives in the same table as the rest of the data and the application can delete it.

Step 17 — Optimization of the persistence layer, measured before and after (step contract)

Stretch: going live. When: in the go-live phase, after step 16 (you need to see the queries in order to measure them) and before step 19 (the performance tests are run on an already optimized persistence layer; otherwise they measure the problem that was already known). It is repeated when a block adds a large table or changes a critical flow, and when the monitoring (21) shows a query out of range. In a legacy system, the measurements come out of N6 and most of what is found is paid "when touched", except what is already out of range. Form: two shots: measure and propose; apply with before and after. Size: proportional: in a small project, the indexes of the real queries and the end of the N+1 loops; in one with consequences, complete, with budgets per path.

What it is for

The persistence layer is where systems die slowly: they work well with a hundred records, acceptably with ten thousand, and at a hundred thousand every screen takes twenty seconds, and nobody knows when it started. This step exists so that this gets decided with numbers and before production, not with complaints and afterwards. And so that it gets decided with the method of step 7: every query the system makes is counted and timed with a meter that has a test, what the numbers say gets changed, and it is measured again on the same data. The first audit of queries without an index on a live system Ref. 18 and the query budget tightened to the measured value Ref. 37 are the origin of this step; the decision of the asynchronous interface from line one Ref. 15, its antecedent at the start.

What it is not: it is not "rewriting the data access layer", nor choosing another engine. Step 3 decided that. It is adjusting what is there (indexes, pagination, batching, retention, pool size) on the basis of what the real queries do.

If you are a beginner. The persistence layer is the part of the system that stores and reads the data, almost always a database. An index is like the index of a book: without it, to find an appointment the database reads the whole table (that is a full scan); with it, it goes straight there. An N+1 loop is a very common mistake: to show a hundred appointments, the system makes one query for the list and then a hundred more queries, one per appointment, instead of just one. Pagination is showing twenty at a time instead of everything at once. Retention is how long each piece of data is kept before archiving or deleting it. And the connection pool is the number of "open lines" the system has with the database at the same time. None of this requires you to read code: it requires you to look at numbers before and after.

1. Required context

What follows is the generic list. The concrete files you have to have made before each prompt, with their content and their minimum state, are in section 2, in the "Before sending the prompt" block that precedes each one.

• The sizing and the volume data (step 3, or N6 in a legacy system): the volumes to measure at.
• The producer/consumer map (step 11): what consumes each table.
• The observability (16): every query visible with its time.
• The test environment loaded with data at the expected volume.

2. Prompts

Opening (measure and propose):

What I am asking for: measuring with the method of step 7 (a meter with a test, audited in both directions, a number with its command) before proposing; proposing query by query, with the gain and the risk, and with the consumers of the map that each change touches (a new index touches nobody; a retention policy per table touches everybody who reads that table); and not changing anything until I approve, because optimization is the place where what nobody asked for gets "improved" the most.

Closing (apply with before and after):

What I am asking for: one commit per change, so that the before and the after are attributable; the same meter on the same data (if the data changes, the number says nothing); the budget with a test, which is what stops the N+1 loop from coming back in three months; and the symmetry of step 11 applied to persistence.

3. Expected result

• The query meters in the repository, with a test.
• docs/PERSISTENCE.md with the before and after table per change, the budgets per path and the retention per table.
• The indexes, the pagination, the batching and the retention applied, one commit each, with the regression suite and the end-to-end suite green.
• One test per budget that fails if it is exceeded.

4. Completeness check

• Run a meter yourself before and after (the agent gives you both commands): do they match the table?
• Is there any query that reads a whole table in a critical flow? Why was it left?
• Does every table have a written retention policy, even if it is "forever"?
• Do the budgets have tests? Ask it to exceed one on purpose and show you the red.
• Does the slowest screen, with the data at volume, take as long as the sizing expected?

5. Warning signs

• The measurements were done with the skeleton's sample data. Everything is fast with ten rows.
• The agent proposes "migrating to another database" or "rewriting the data layer". That is step 3, and if you have to go back to it, it is a decision of yours, not an optimization.
• The number improved but the end-to-end test of a flow stopped passing. An index does not break a flow; a retention policy or a pagination does: a consumer of the map was missed.
• There are no budgets. Without a budget, the optimization lasts until the next block.

Step 18 — Scanning and fixing vulnerabilities, in the chain and on a schedule (step contract)

Stretch: going live. When: in the go-live phase, after step 15 (the scan runs in continuous integration) and before the first deployment: no open P0 gets promoted. Afterwards, on every push, and with a schedule of its own (weekly) even if there are no pushes, because new vulnerabilities appear without you changing anything. In a legacy system, the first run is part of N3 (the security dimension of the audit) and the findings go into the backlog with their speed mark. Form: one shot to set it up and run it; afterwards, automatic, with a report that you read. Size: mandatory in every project that is going to have users: the dependency scan and the secrets scan are not negotiable; the static analysis and the configuration baseline are proportional.

What it is for

The audit of step 13 looks at the system with fresh eyes every so often; this step looks at a single thing, security, all the time and by machine. They are complementary: the audit finds what requires judgement (an administrator door nobody should have Ref. 40); the scan finds what requires persistence (the dependency that yesterday had no known vulnerability and today does Ref. 41). The first formal security audit convinced me that security is a periodic routine and not a list you tick once Ref. 23; this step is that routine turned into a machine.

And a rule I want written down: a dependency upgrade is a change, and it comes in through the loop like any other. "I bumped the version to close the vulnerability" without a regression suite or an end-to-end suite is the most common way of breaking production on a Friday.

If you are a beginner. A vulnerability is a defect somebody can use to get in, steal data or make the system do something it should not. There are four kinds that this step searches for by machine. In the dependencies: the pieces of other people's software your system uses (there are public databases that list which ones have known defects, identified with a CVE number). In the code: static analysis reads the code without running it, looking for dangerous patterns, such as an injection (a user writing into a form something the database interprets as an order). In the history: a secret (a password, a key) that was once committed to the repository is still there even if it was deleted afterwards. And in the configuration: open ports that were not needed, default passwords, missing security headers (instructions the server sends to the browser to protect it).

1. Required context

What follows is the generic list. The concrete files you have to have made before each prompt, with their content and their minimum state, are in section 2, in the "Before sending the prompt" block that precedes each one.

• Continuous integration (steps 4 and 15), where the scan runs.
• The survey of environments: which server, which container, which ports, for the configuration baseline.
• The previous audit (13, or N3), so as not to report what is already known.
• Your criteria about what is a P0: what lets somebody in, what exposes personal data, what allows charging or sending without control.

2. Prompts

Opening (set up, run, propose):

What I am asking for: the four layers of scanning (dependencies, code, secrets in the history, configuration), in the chain and on a schedule, because new vulnerabilities do not wait for your next push; the report with the shape of step 13, with the "not scanned" clause instead of "clean"; the P0 criteria given by me; and the ban on upgrading without going through the loop, which is the one that avoids the broken Friday.

Closing (fix and turn into a gate):

What I am asking for: one pending item per fix, with the red of step 8 where it is possible (a vulnerability fixed without a test comes back with the next refactor); the repeated scan as evidence; and the conversion into a gate, which is what keeps this step alive when nobody is looking at it.

3. Expected result

• The four-layer scan running on every push and weekly.
• docs/SECURITY_[date].md with the findings and what was not scanned; docs/SECURITY.md with the policy, the schedule, the gate and the coverage.
• The P0s and P1s fixed, each with its pending item and its test where it applies.
• The gate in docs/GATES.md.

4. Completeness check

• Ask it for the link to the last run of the scan: is it green, and what date is it from?
• Does the report say what it did NOT scan?
• Does every P0 have its pending item closed with evidence, or open with a date?
• Ask it to introduce on purpose a dependency with a known vulnerability on a branch: does the chain go red?
• Do you know when the next scheduled scan runs?

5. Warning signs

• The scan came out clean on the first try on a system more than a month old. It is almost never true: a layer is missing, or only the branch was scanned and not the history.
• Ten dependencies were upgraded in one commit "to close the findings". That commit has no before and no after; it is the broken Friday waiting to happen.
• The scan is there but it is not a gate: it produces reports nobody reads.
• There is an "accepted" P0 with no pending item, no date and no signature.

Step 19 — Performance tests at volume and the breaking point (step contract)

Stretch: going live. When: in the go-live phase, after step 16 (without observability you do not know what broke) and after step 17 (on an already optimized persistence layer), and before the first deployment to production. It is repeated before every deployment that changes the architecture, the persistence layer or a critical flow, and when the sizing changes (it is sold to another client, the volume doubles). In a legacy system, it is run with the volumes measured in N6, before the first deployment after the normalization. Form: one shot; the agent loads, measures and breaks; you read the numbers and the breaking point. Size: proportional: in a small project, one run at the expected volume and one at "times ten"; in one with consequences, complete, with the breaking point found and the thresholds recorded for the monitoring.

What it is for

Step 3 sized the system with calculations; this step checks the calculations with the real system running. I want to know three things before the first user comes in: how the system behaves at the volume the business stated (does the most used screen respond within what the owner would tolerate?), how it behaves at "times ten" (does it hold, or what stops holding first?), and where it breaks: the exact load at which something gives way, and what that something is (the database connections, the memory, a queue, a lock). The breaking point is the most useful number of the whole stretch, because the alert thresholds of step 21 come out of it: an alert set "by eye" warns too late or warns always; an alert set below the measured breaking point, with a margin, warns while there is still time. The scale patterns I took from a system in production Ref. 12 and the test suite that was dying by memory and looked like a failed test Ref. 44 are the two antecedents: the first, about measuring the real load; the second, about a breaking point not found in time disguising itself as something else.

If you are a beginner. A load test is a program that simulates many users using the system at the same time, to see what happens. Throughput is how many actions per second it holds. Latency is how long an action takes to respond; you look at the median (half of the actions took less than this) and the 95th percentile (95 % took less than this; the remaining 5 % are the users who complain). The breaking point is the amount of load at which something stops working: not "it gets slow" but "the database connections ran out" or "the memory filled up". And a threshold is a limit number above which the monitoring warns.

1. Required context

What follows is the generic list. The concrete files you have to have made before each prompt, with their content and their minimum state, are in section 2, in the "Before sending the prompt" block that precedes each one.

• The sizing (step 3 or N6): the expected volume and the "times ten".
• The observability (16) switched on, to see what breaks.
• The optimized persistence layer (17) with its budgets.
• A test environment similar to production in resources, or the awareness of how it differs.
• The critical flows (the ones in the semantic tree, or the ones in the characterization in a legacy system).

2. Prompts

Opening (load, measure, break):

What I am asking for: a load script that is one more meter (it lives in the repository and has a test, because a load script that does not exercise the flow measures thin air); three runs (expected, times ten, until it breaks); the numbers with their commands; the comparison with the budgets, the business's tolerance and the sizing assumptions, which is where you discover that step 3 got something wrong; and no optimizing yet, because optimizing without reading the diagnosis is changing what was not the problem.

Closing (thresholds and pending items):

What I am asking for: the alert thresholds derived from the breaking point, which is the hook into step 21; the bottlenecks as pending items with the number as the criterion (that way they are closed with evidence and not with "it runs better now"); and the load test as an archived gate, so that in six months you can compare.

3. Expected result

• The load script in the repository, with a test.
• docs/PERFORMANCE_[date].md with the three runs, the numbers, the breaking point and the diagnosis; docs/PERFORMANCE.md with the thresholds and the gate.
• One pending item per bottleneck below the volume decided.
• The load test as a gate before the deployments that require it.

4. Completeness check

• Does the most used screen, at the expected volume, take less than the owner's tolerance? If not, there is a pending item open with that number.
• Does the breaking point say what broke and at which load, or does it say "the system got slow"?
• Are the thresholds of docs/PERFORMANCE.md below the breaking point and above the expected volume?
• Run the script yourself at the expected volume with the command it gave you: do the numbers look similar?
• Does the test environment differ from production in resources, and is it written down how?

5. Warning signs

• "It holds the times ten with no problem" without a breaking point. If it did not find where it breaks, it did not raise the load enough.
• The load script hits the API but does not go through the screen, in a system where the screen is what loads. It measures something else.
• The results come from a run on the agent's machine, not on the test environment.
• Bottlenecks were fixed during the test, "while we were at it". Now you do not know which number corresponds to which version.

Step 20 — Living documentation and manuals a person can follow without AI (step contract)

Stretch: going live. When: the user manual grows with every functional block, at its close, with the new screens; fed by the closed pending items, which are the documentation of what was done. The three complete manuals are generated in the go-live stretch, after step 15, and the test with a person who does not program is done before the first deployment. The same-commit routine applies throughout operation. Form: routine; plus one long shot when the manuals are generated. Size: proportional. A small system needs, at minimum, the infrastructure and recovery manual; the user manual can be one page. What does not change: if the person who built it disappears, somebody else has to be able to carry on.

What it is for

Make the system usable, maintainable and recoverable without the agent and without you. If on the day there is no agent it cannot be deployed, it is not finished. In the classical method documentation was expensive and it aged; here regenerating it is free, so the rule becomes "in the same commit" and "reproducible by hand". The manuals I wrote for the Health Fund with that criterion are the model Ref. 24; and the project file that turned into a history of thousands of lines is the counterexample Ref. 41.

A quality criterion for the recovery manual, which lets you judge it without being technical: a trusted person who does not program has to be able to follow it, at three in the morning, with the system down and the agent offline. If at any step it says "check with the developer" or "depending on the case", that step is incomplete.

And that test leaves three things written down, because if it leaves nothing, the gate is fulfilled without measuring anything -- which is the cheapest way to have a decorative gate. The three are: the measured time end to end (when the person started, when the system was working again), the exact point where they got stuck (the step of the manual, in their words, not in yours), and every word they did not understand. The three go with a date and the name of whoever ran the test. And every word they did not understand opens a pending item: either the manual explains it, or the thing gets renamed across the whole system. That list of words is, on top of that, the best input for the user glossary of step 2, and the retrospective of step 23 uses it as a proposed change.

Without these manuals, said in one word that needs no explanation: the owner is not an owner, they are a tenant. They have the system, they pay for it, and they cannot get in without asking permission from whoever built it.

And a source you must not waste: the closed pending items. Each one carries its specification, its decision, its evidence and its date. The user manual is not written from scratch at the end: it is assembled, block by block, from the pending items that were closed, and the changelog comes straight out of them.

1. Required context

What follows is the generic list. The concrete files you have to have made before each prompt, with their content and their minimum state, are in section 2, in the "Before sending the prompt" block that precedes each one.

• Who the readers of each manual are: the end user, the one who maintains, the one who operates the infrastructure. The business knows; the agent asks if it is not clear.
• The system running in the test environment, to take real screenshots.
• The closed pending items of the block, with their closing documentation (step 5).
• docs/DEPLOYMENT.md (step 15) and docs/LOCKS.md (step 14), which are inputs.

2. Prompts

Routine (goes in the working agreement):

What I am asking for: the same-commit rule, which is the only one that keeps a manual up to date; the close of the block as the moment when the closed pending items become manual and changelog; and the question when it is not clear which manual it goes to.

To generate the manuals:

What I am asking for: the three manuals with their readers; real screenshots from the test environment (not drawings or descriptions); the three-in-the-morning criterion for the recovery manual; the completeness clause in its form for documenting: what only the business knows is asked, and no gap is left and nothing is invented; and date and version, so that it is known which system each manual corresponds to.

3. Expected result

• docs/USER_MANUAL.md (or HTML), with real, embedded screenshots, which grew block by block.
• docs/MAINTENANCE_MANUAL.md.
• docs/INFRASTRUCTURE_AND_RECOVERY_MANUAL.md: step by step, for a person.
• docs/CHANGELOG.md, fed by the closed pending items.
• Each one with a date and the version of the system it documents.
• In the commits that change screens, operation or deployment: the manual updated.
• The record of the recovery-manual test, with four things: the date and the name of whoever ran it; the measured end-to-end time; the exact step where they got stuck, in their words; and the list of words they did not understand. Plus one pending item opened for each of those words. Where it gets written is your choice -- at the end of the recovery manual itself is enough --; what is not optional is that it exists.

4. Completeness check

• Open the user manual at a random screen: does the screenshot match what is in the test environment today?
• Could you, or a trusted person who does not program, follow the recovery manual? Read the "it went down" section: does it say what to do, in order, with the commands?
• Did the recovery-manual test leave its record: how long it took, where the person got stuck and which words they did not understand, with a date and a name? And of those words, did every one open a pending item? If the record says "the test was done" and nothing else, the test cannot be repeated or compared: the gate is fulfilled on paper.
• Pick a recent commit that changed a screen: did it touch the manual?
• Does the changelog have one entry for every pending item closed in the last block?
• Is there a gap of the kind "[to be completed]" or "check with the person responsible"? There the agent had to ask.
• Does each manual say which version of the system it is valid for?

5. Warning signs

• The user manual has screenshots of a version that no longer exists. It was generated once and not maintained: the same-commit rule is not in the agreement or is not being applied.
• The recovery manual starts with "open a session with the agent". If the agent is a prerequisite, it is not a manual for a person.
• Nobody outside the builder ever read the recovery manual. Ask somebody to follow it in the test environment; whatever gets them stuck is what has to be fixed.
• The test was done and was not recorded, or was recorded as "it went fine". Then nobody can say how long it took nor where it came close to not working, and next time you start from zero.
• The record does not have a single word on the list of the ones that were not understood. It happens now and then and it is true; it happens always and it means nobody asked.

Step 21 — Monitoring of resources, functions and queries out of range, with a cyclic report (step contract)

Stretch: operation. When: it is set up in the operation phase, with the first deployment to production, with the thresholds of step 19 and the metrics of step 16; from then on it runs on its own, and the cyclic report is read with the owner every cycle (weekly in a system with consequences, monthly in a small one). Every out-of-range event enters the loop as a corrective pending item. In a legacy system, the same, with one difference: the first reading of the report is the baseline, and whatever was already out of range on the first day turns into pending items with their speed mark. Form: one shot to set it up; afterwards, a cyclic routine. Size: minimum in a small project (one monthly report, one disk alert and one database error alert); complete in one with consequences (thresholds per function and per query, alerts, weekly report).

What it is for

The tests of step 19 say how the system behaves on one day, with a load I chose. Production is every day, with the load the users choose, with the data growing, and with changes coming in every week. What was in range in October goes out of range in March without anybody changing anything, just because the table grew. This step exists so that this is seen before the user sees it: resource usage against capacity, the response time of every function, every endpoint, every job and every query, compared with the thresholds of step 19 and with its own history; an alert when something goes out of range; and a cyclic report that I read with the owner, where every deviation has a cause or a pending item. The ceiling tightened to the measured value Ref. 37 is the underlying idea: the range is not an opinion, it is the measured number plus a margin; and the continuous integration quota that was burned without anybody looking Ref. 39 is the failure it prevents: a resource that is consumed without monitoring is discovered when it runs out.

Two rules I do not negotiate. An alert that fires and nobody reads is a defect of the alert, not of whoever did not read it: it gets adjusted or removed. And a threshold is not raised to silence an alert without a measured reason written down.

If you are a beginner. To monitor is to watch the system all the time by machine and warn when something goes outside the normal. The resources are what the system consumes: processor, memory, disk, database connections, and also the quotas of external services (how many messages per month your provider lets you send). "*Out of range*" means above a threshold (a fixed limit, which came out of the tests of step 19) or very different from the baseline (what that same number had been giving over the last few days). An alert is the warning at the moment; the cyclic report is the summary that is read calmly every week or every month.

1. Required context

What follows is the generic list. The concrete files you have to have made before each prompt, with their content and their minimum state, are in section 2, in the "Before sending the prompt" block that precedes each one.

• The observability (16): the metrics and the log records it feeds on.
• The thresholds of step 19 and the budgets of step 17.
• Production deployed (15), with read-only access for the monitoring.
• The alert channel and the report cycle: you decide them with the owner.

2. Prompts

Opening (set up and demonstrate):

The window of the measurement. The cyclic report compares the rows observed per year against what step 3 declared. A correct number with a wrong window opens a false pending item: in the inherited Turnera practice, 30,000 rows of three years were passed as if they were one. So the measurement carries its verifiable window: the first and the last record read from the database or the log, not a number typed by hand. If the tool cannot read the database, it declares it as a blind spot; a window typed by hand is marked as such in the report and only warns, it never opens a pending item on its own. (Decision D-039.)

What I am asking for: collection with history (without history there is no baseline, and without a baseline there is no "out of range"); alerts against two references, the absolute threshold of step 19 and the relative deviation from its own history; the cyclic report with the shape of a report of step 12 (every deviation with a cause or a proposal, no "everything normal"); the conversion of every deviation into a pending item with a number; and the two demonstrations: the first report and a provoked alert.

Routine for every cycle (goes in the working agreement):

What I am asking for: that the report be read and decided on, with a trace; and the threshold rule, which is the one that keeps the monitoring from going silent little by little.

3. Expected result

• Collection of resources and response times with history, without personal data.
• Alerts by threshold and by deviation, to a channel a person reads.
• The cyclic report, generated on its own, with every deviation given a cause or a proposal.
• docs/MONITORING.md with thresholds, channel, cycle and how to silence with a reason.
• The routine in the agreement; the deviations as corrective pending items.

4. Completeness check

• Ask for a threshold to be exceeded on purpose in the test environment: did the alert reach you, through the agreed channel, with the identifier?
• Read the last report: does every out-of-range event have a cause or a proposal? Did any end up with nothing?
• Is there a pending item for every deviation you decided to attend to, with the number as the criterion?
• Did any threshold go up since step 19? With what written reason?
• Does the report mention the quota of the external services (messaging, continuous integration)?

5. Warning signs

• The alerts fire every day and nobody reads them. Their number has to come down until each one means something, not get used to.
• The report says "everything normal" three cycles in a row. Either the system has no users, or the report is not looking at what matters.
• A threshold went up "so that it stops warning". That is step 21 dying in silence.
• The monitoring stores personal data "so we can diagnose". That is a leak on a schedule.

Step 22 — Error monitoring and cyclic report: no error without a pending item (step contract)

Stretch: operation. When: it is set up in the operation phase, with the first deployment, together with step 21, on the log records of step 16; from then on it runs on its own, with alerts at the moment and a cyclic report that is read with the owner. Every new error enters the loop as a corrective pending item and is closed with the test that reproduces it in red. In a legacy system, the first reading is the baseline: the errors that already existed on the first day turn into pending items with their speed mark, and none is left as "known" without a pending item that says why it is tolerated and until when. Form: one shot to set it up; afterwards, a cyclic routine. Size: mandatory in every project with users: the centralized capture and the report are not negotiable; the alerts at the moment, proportional.

What it is for

A system in production produces errors no user reports: the one who saw a blank screen and tried again, the one from the nightly job that failed and nobody looks at, the one from the external call that returned an error and the code swallowed. If I do not capture them, they do not exist until they exist too much. This step is the counterpart of step 21: that one watches performance, this one watches errors, and both end up in the same place, the loop, as corrective pending items. The underlying rules are two. No error without a pending item: a new error opens one, and it is closed with the test that reproduces it in red, as the corrective mode of the evolutive path demands. And there is no such thing as a "known error" without a pending item that says why it is tolerated and until when; "that error was always there" is the sentence with which a system rots. The authentication error reported as a success Ref. 43 and the four rounds to the root cause Ref. 22 are the two antecedents: the first, about errors hiding if they are not captured by machine; the second, about an error without a reproduction being fixed several times.

If you are a beginner. An error is anything the system tried to do and could not: a screen that did not load, a nightly job that was cut short, a call to another service that failed. An unhandled exception is an error the code did not foresee and that cuts short what it was doing. To capture an error is to store it with all its data (when, in which version, with which identifier, the stack, which is the list of the program's steps up to the failure) in a single central place, instead of letting it get lost on a user's screen. To group is to join the thousand times the same error happened into a single entry with a counter. And the error rate per flow is, out of every hundred times somebody booked an appointment, how many failed.

1. Required context

What follows is the generic list. The concrete files you have to have made before each prompt, with their content and their minimum state, are in section 2, in the "Before sending the prompt" block that precedes each one.

• The observability (16): the errors arrive with a correlation id, a version and an actor.
• The table of locks (14): the errors in consequential actions are an immediate alert.
• Production deployed (15), with the user's browser included in the capture.
• The alert channel and the report cycle, shared with step 21.

2. Prompts

Opening (set up and demonstrate):

The tool's errors are not the system's errors. Centralized capture separates by source: the errors of the system and those of the tools that watch it (the panel, the resident agent, the monitoring itself) are stored under different sources, the report lists them in separate sections, and only the system's errors open pending items. In the Turnera practice, the first cyclic report opened six "bugs" that were the Forge panel talking to a server that was off. (Decision D-038.)

What I am asking for: the capture in the three places where errors hide (backend, jobs, browser), with the identifier of step 16 so that they can be followed; the grouping, without which the report is a list of ten thousand lines; the three alerts that matter (new, recurring and growing, with consequences); the report with the rate per flow, which is the number the owner understands; the two rules; and the end-to-end demonstration, from the browser to the report.

Routine for every cycle (goes in the working agreement):

What I am asking for: the discipline of the cycle, and the rule of the error that disappears, which is the most counter-intuitive and the most valuable: an error that went away on its own comes back on its own.

3. Expected result

• Centralized capture of errors in the backend, the jobs and the browser, grouped by cause, without personal data.
• Alerts for a new error, for a recurring one that grows, and for one with consequences.
• The cyclic report with the error rate per flow.
• docs/MONITORING.md complete (together with step 21); the routine in the agreement.
• One pending item for every open error; none "known" without a pending item.

4. Completeness check

• Provoke an error yourself in the browser in the test environment (an action you know fails): did it appear in the capture with your identifier, and did the alert reach you?
• Read the last report: is there any recurring error with no pending item and no reason?
• Take a "fixed" error from the report: does the pending item have the test that reproduced it in red?
• Is the error rate per flow there, and did it go down or up against the previous period?
• Search for a piece of personal data in the error capture: it must not be there.

5. Warning signs

• Zero errors in production during a month with real users. There is no such system; the capture is not seeing the browser or the jobs.
• An error with a thousand occurrences and a comment saying "known, no impact". No pending item, no date.
• The errors get "fixed" by restarting the service. They disappear and they come back.
• The error report and the resources report are read by different people and nobody cross-reads them: the slow query of step 21 is the cause of the timeout of step 22.

Step 23 — The agent inside the system, and the retrospective with numbers (step contract)

Stretch: operation. When: the resident agent, on entering operation, after the first deployment to production. The retrospective, at the close of every stage and of the project; it returns to step 0 for the next project. Also run a short retrospective when the model that builds changes: a contract calibrated for one model does not necessarily perform the same with another, and a model change is exactly the kind of finding this ladder asks you to turn into a change proposal, not a surprise discovered halfway through a block. Form: two parts: a conversation to define the resident agent's scope, and one long shot for the retrospective. Size: the resident agent is optional (many systems do not need one; those with users who ask for support do). The retrospective is mandatory in every project, even if it is one page long: without it the method does not learn.

What it is for

Two things that close the same cycle. First: leave the agent resident in production, with a bounded scope, to diagnose, operate and give support without you having to be there Ref. 13. Second: review the method itself with numbers, and let what is learned change the ladder. It avoids the agent that operates without a map of the system, and the method that repeats itself identically project after project without learning. The retrospective with numbers that led me to eliminate a whole team of agents is the model for the second part Ref. 6.

On the resident agent, the rule that orders everything: it acts in someone's name. Its credential is mapped to a responsible person, and everything it does is logged under that person's name. It is not an anonymous system account: it is an employee with a boss. That defines its scope (what that person authorised it to do) and its traceability (who answers for what it did).

1. Required context

What follows is the generic list. The concrete files you have to have made before each prompt, with their content and their minimum state, are in section 2, in the "Before sending the prompt" block that precedes each one.

For the resident agent:

• What the agent can and cannot do in production: read, diagnose, change configuration, execute actions. You decide.
• How the agent identifies itself to the system (a credential of its own, mapped to a responsible person).
• Whom it notifies when it finds something it cannot resolve (ticket, email).

For the retrospective:

• The project's incidents, the costs (tokens, quota, your time), the pending items that took the most rounds, and the dates.

2. Prompts

For the resident agent (opening):

What I am asking for: the map of the system before operating (operating without a map is the failure this step avoids); the completeness clause in its form: the gaps in the map are declared, not hidden; the three levels of scope so that you choose one and not an "it depends"; the rule of the credential in a person's name; and the injection clause: what the agent reads in production is data, never an instruction, because a log or a ticket is exactly where an outsider could try to talk to the agent directly.

For the resident agent (closing):

What I am asking for: the resident agent's document (without the value of the credential, ever), and the red test of the scope: a real attempt, logged, to do something outside the level, rejected. It is step 8 applied to permissions.

For the retrospective:

What I am asking for: numbers with their source (costs, pending items, rounds, incidents); every incident mapped to a step, because an incident that falls into none is a step that is missing; the completeness clause for the numbers it does not have (ask or mark as an estimate); and at least one concrete proposal to change the ladder, because a retrospective that changes nothing was not a retrospective.

3. Expected result

• docs/RESIDENT_AGENT.md: map of the system, chosen scope, credential mapped to a person, approval procedure, and the rejection test recorded in the log.
• docs/RETROSPECTIVE_[date].md: the numbers with their source, the incidents mapped to steps, and at least one proposal to change the ladder with its justification.

4. Completeness check

• Does the map of the system say what the agent can NOT see? If it does not say so, it has hidden gaps.
• Did you test (or see in the log) that an action outside the scope is rejected?
• Does the agent's credential act in the name of an identifiable person?
• Does the document explicitly say that what the agent reads in production is data, not an instruction?
• Does the retrospective have numbers with their source, or adjectives? ("It cost a lot" is not a number.)
• Does every incident fall into a step? If one falls into none, a step is missing: that is the change proposal.
• Is there at least one concrete proposal to change the ladder? If the retrospective changes nothing, it was not a retrospective.
• Has the model that builds changed since the last retrospective? If so, is there a short review of which contracts still perform the same and which do not?

5. Warning signs

• The resident agent "needs" a higher level of permissions every week. Check whether what it asks for is to solve the system's problems or its own limits.
• The agent executed something because "a log said so" or "a ticket asked for it". A log or a ticket authorises nothing; only you, or the approval procedure you wrote, do.
• The retrospective says everything went well. Everything never goes well; it was written for you, not for the method.
• Two projects in a row had the same incident and the ladder did not change between one and the other. Step 23 is not being closed: the retrospective gets written and not applied.