Démarrer un cas

Onirion · first case worksheet

A method by Alexis Boyer · version 4.0 · September 22, 2026

Run the method once, end to end, on a case nobody depends on. The application is the one shipped beside this file, at sandbox/. You walk the seven gates in order and fill the blocks as you go. The prompts are in the core guide; this worksheet says which one to run where, and what you should be holding when the gate closes.

The complaint that starts this case is a made-up exercise input. It is not research, it is not a real user, and nothing here asks you to treat it as evidence. Wherever the method asks what a source establishes, the honest answer on this case is: a fixture written for practice.

The case

Someone writes a project update, selects Save draft, leaves the page, and finds the text gone on return.

The outcome you own: the author can come back to the text they confirmed, and the second identity cannot read it — not in the page, and not through the direct read route.

What the sandbox already carries, and you can check yourself:

• two identities, chosen at /as/author and /as/reviewer and held in a local cookie;
• one confirmed draft, fictional-draft-001, owned by the author identity;
• POST /save for the form, GET /api/drafts/fictional-draft-001 for the direct read;
• a Simulate failed save button that sends simulate_failure=1, so the failure is reproducible with nothing external;
• three deliberate defects: the save does not persist, the direct read answers the second identity, and the failure is swallowed and reported as success;
• three acceptance tests written against the intended behaviour, which fail before you implement.

Outside this case: deletion, expiry, two people editing at once, offline saving, real authentication.

Run the sandbox before you start

• Python 3.9 or newer. Nothing to install, no account, no network.
• From sandbox/: python3 app.py, then open http://127.0.0.1:8766/.
• Acceptance checks: python3 -m unittest -v test_acceptance.py. Expect three failures. Three errors instead mean the environment stopped the tests binding their local server on 127.0.0.1.
• In Codex, the default workspace-write sandbox blocks that local server. Allow network access for the session — codex --sandbox workspace-write -c sandbox_workspace_write.network_access=true — or run the test command yourself outside the sandbox.
• The server binds to 127.0.0.1 only and writes sandbox.sqlite3 beside the app. Delete that file to reset your manual run; the tests use a temporary database.
• The identity switcher is a cookie, not authentication. Never deploy this server. Never put real data in it.

Open your assistant on the case folder

If you installed the kit's skill, invoke it with the case: /onirion in Claude Code, $onirion in Codex. Whatever you use, ask for the gate statement every time, as the guardrail says: which gate it is at, what it has, what is missing, what you must decide before it crosses.

What the sandbox cannot give you

Five things the method asks for are not here: an approved frontend starter, written backend conventions, a design system, a path to staging, and leads who give the go-ahead before production. At each of those points this worksheet stops and has you write down the service that is missing and who you would ask. Do not invent another organization's standards, and do not let the assistant invent them either. Here you keep going inside the shape the sandbox already has, with the gap written down.

Copy this block each time the worksheet asks for it:

Service missing here:
What I would ask for, concretely:
Who I would ask (the role, not "someone"):
What I did instead on this run, and with whose agreement:
Date recorded in the journal:

The two things that run across the gates

Control session — opened in:
How it reaches the main session here:
If it cannot reach it: I relay the finding unchanged and say where it came from.
Limits written into its first prompt: it reads, checks, challenges; it does not
  change code; it does not decide scope; it does not write the PRD or the
  prompts; it returns findings with evidence and I decide.

Standing guardrail — what the agent re-reads before every change to the code:
What is missing from that list on this run:
The gate statement is asked for at every gate: yes / not yet

Gate 0 — set up the project folder

What you do. Make one folder for this case. Put the sandbox in it, and write the made-up complaint into it in your own words so the material is in the folder rather than in this page. Create the memory and the journal before anything else runs. Then run the inventory and conversion prompt from the core guide, and read what comes back.

Prompt to run. The inventory and conversion prompt (Gate 0). It converts, indexes, and interprets nothing.

Case folder created at:
Sandbox copied into it as:
The made-up complaint written down as:
PROJECT_MEMORY.md created: yes / not yet
PROJECT_JOURNAL.md created: yes / not yet
If this were real, the people who would be in the project channel:
What `converted/INDEX.md` lists:
What the pass could not read:
The hole I filled straight away, while it was cheap:

You should be holding: everything for this case in one folder, converted, inventoried.

Gate 1 — gather the discovery

What you do. Take stock of what you actually have: the sandbox README, app.py, test_acceptance.py, and the made-up complaint. Read the code for what it establishes — the defects are in it, commented. Then write DISCOVERY.md, so Gate 2 can open it by name.

Prompt to run. The Gate 1 prompt, pointed at those three files by name, with its rules block unchanged. There is no channel and no mailbox on this case: the material an agent would normally read for you does not exist here, and that is a line to write down, not a gap to fill with invention.

Sources I actually have:
What is established, and which source establishes it:
What contradicts what, source against source:
What is absent — the questions this material does not answer:
Questions I would put to a stakeholder, if there were one:
My hypothesis on the product boundary:
Written to DISCOVERY.md: yes / not yet
What the control session challenged in the above, and what I did with it:

You should be holding: what is known, what is missing, what contradicts.

Gate 2 — write the PRD

What you do. Produce one document whose first section is the strategic framing. Answer the alignment questions rather than letting the agent choose silently — on this case you are the only one who can answer them, and you say so in the document.

Prompt to run. The PRD prompt (Gate 2), on converted/, converted/INDEX.md, DISCOVERY.md, the memory and the journal, with the template at ../templates/prd.md for the shape of each section.

The three acceptance criteria this case has to carry, because the shipped tests already state them:

1. after a save confirms, a reload — and a switch away from the identity and back — brings the confirmed text back;
2. the second identity gets neither the text in the page nor a 200 from GET /api/drafts/fictional-draft-001; the denial does not contain the text;
3. a failed save answers 503, keeps the edited text in the field, shows an error, offers Retry, and never shows Saved; a reload before a successful retry restores only the last confirmed text; a retry that succeeds persists.

PRD written to:
Strategic framing, in three lines:
Product boundary — in:
Product boundary — out:
Roles: the author identity / the second identity, and what each may read:
The privacy rule that decides this case:
What wins when sources disagree, here:
Functional depth — flows that must really work:
Acceptance criteria — the three above, in my own words:
Open decisions, and who would take them if this were real:
Alignment questions the agent asked me, and my answers:
Every assumption marked as an assumption: yes / not yet
What the control session said about the framing, not only the coherence:

You should be holding: what is in and what is out, agreed — here, agreed with yourself, and written down as that.

Gate 3 — prototype the end-to-end flows

What you do. Let the session take the PM role and write the design prompt from the PRD. Ask for the whole flow, not the main screen: empty, editing, saving, saved, failed with its error and Retry, and the return after reload or a switch of identity. Ask for the narrow screen and for status and error messages a screen reader announces — the shipped tests read a role="status" message and a role="alert" message, so those are behaviour, not decoration.

Prompt to run. The design prompt — long specification — with the short instruction layer, and the refinement prompt if the first output is shallow.

Missing service. There is no design system here. Copy the missing-service block and fill it. Name a reference product you will follow instead, say it is a constraint, and write down that both the prototype and the code will draw on that same thing.

Missing service: design system
(copy the block above and fill it)

Reference product followed instead:
Screens and states the prototype covers:
Narrow-screen behaviour covered: yes / not yet
Status and error messages written as real copy: yes / not yet
Who I showed it to, and what they said:
Nobody depends on this case: what closed the gate was my own judgement, and
  that is recorded in the journal as such.
What the showings changed, written to memory and journal:

You should be holding: a prototype of the whole flow, and an honest line about who recognised it.

Gate 4 — port the prototype into code

*What you do. * The port goes into the sandbox's own code. There is no starter to clone, so you do not clone one: the application is the single standard-library file already in front of you, and you keep your changes inside the shape it has. Move the working documents next to the code, under docs/: the PRD, PROJECT_MEMORY.md, PROJECT_JOURNAL.md, all three at once.

Prompt to run. The coding-agent prompt (Gate 4), plus the standing constraint carried in every coding prompt.

Missing services. Two blocks here, not one: no approved frontend starter, and no written backend conventions. Fill both before you let the agent write anything, and name what you would ask Frontend Ops and Backend and API Ops for.

Missing service: approved frontend starter
Missing service: written backend conventions
(copy the block above twice and fill both)

Working documents moved under docs/: yes / not yet
The slice I asked for first:
What I ran it with, and what I clicked:
What was off when I put the running page beside the design:
The back-and-forths it took:
What the control session found when it checked the port against the design:
What I adapted to the sandbox's existing shape, and why, in the journal:

You should be holding: a page that runs, that you can click, still failing the three checks.

Gate 5 — connect the backend

What you do. The backend on this case is the storage layer and the handler in the same file. Connecting it means making the three defects real behaviour: the save persists what was submitted, the read is scoped to the owner so the second identity is denied at the route, and the failure is no longer swallowed — 503, the edit still in the field, an error, a Retry, no Saved. Go deep on each flow before the next: the empty state, the error, the denial, the reload before a retry succeeds.

Prompt to run. The connection prompt (Gate 5), one flow at a time. Call the control session on anything that behaves oddly, and ask it to reproduce rather than fix.

Flow 1 — save and return. What I changed:
  Observed after reload:
  Observed after switching identity away and back:
Flow 2 — the second identity is denied. What I changed:
  Status returned by the direct route:
  What the body contains:
Flow 3 — the failed save. What I changed:
  Status returned:
  What stays in the field:
  What the error says, and where Retry is:
  What a reload before a successful retry restores:
  What a successful retry persists:
`python3 -m unittest -v test_acceptance.py` returned:
What I clicked as each identity, not only what the tests said:
Findings the control session sent to the main session:
Decisions to memory, changes and verifications to the journal, dated:

You should be holding: the three flows holding in depth, and the tests passing because the behaviour changed — not because a test was weakened.

Gate 6 — test, then ship

What you do. Put it in someone else's hands while you are still working, and fix what comes back. Then walk the delivery path as far as it goes here — which is local, and no further. The server binds to loopback and holds a fixture; nothing about this case is deployed, and the run ends by writing down where it stopped.

Prompt to run. The release prompt (Gate 6), as a rehearsal. It names what is in the release, what was tested and with which identities, what was verified and how, what is known to be unfinished, and which review did not take place.

Missing services. No staging and no delivery path, and no leads of the trades to give the go-ahead. Two blocks, filled before you write the release note, so the note can name them.

Missing service: a path from local to the repository to staging to production
Missing service: leads who give the go-ahead before production
(copy the block above twice and fill both)

Who else clicked it, and what they reported:
What I fixed as it came back:
Defects were handled as they appeared, so none were classified: yes / no
Checks I ran, and what they returned:
What I walked end to end myself, including the empty, error and denied states:
What is still unfinished:
Which review did not take place, and who was not there to give it:
Where this run stops: nothing leaves this machine.
Release note written to the journal, dated: yes / not yet

You should be holding: a case you can account for line by line — what you built, what you verified yourself, and which review nobody gave.

What the run leaves you with

The gate that was hardest, and why:
The prompt I had to run twice:
The moment the assistant crossed a gate I had not closed:
The services I wrote down as missing, and who I would ask on a real case:
The one thing I will do differently on a case that matters:

Text licensed CC BY 4.0. Code MIT.