--- title: Guide principal route: /fr/resources/method-guide lang: fr part_of: Onirion version: "4.0" date: 2026-09-22 author: Alexis Boyer license: CC BY 4.0 one_line: "La méthode elle-même : les sept jalons, ce que chacun exige, les prompts qu'il utilise, et ce que vous avez en main avant de passer au suivant." kind: guide layers: summary: /fr/resources/method-guide complete_text: /fr/complete.md markdown: /fr/resources/method-guide.md --- *Le texte ci-dessous est celui du kit, en anglais.* # Onirion · core guide **A method by Alexis Boyer · version 4.0 · September 22, 2026** ## What this is A way to take one product from a folder of scattered documents to something running in production, alone, with coding and design agents doing the work you brief them for. It is written for a **Product Builder**: one person accountable for one product outcome, end to end, front and back. You carry the problem, the decisions, the design that was accepted, the constraints and the verification. You do not hand the outcome to anyone. The method is tool-neutral. The gates, what each one demands and what ends it do not change with the assistant you use. The two adapters in this kit — one per supported assistant — cover installation. What the kit does not carry is the wiring: how you make the main session and the control session address each other inside a given tool is something you set up in that tool, and nothing here describes it for you. Neither adapter changes the method. ### Vertical and horizontal You own one outcome, **vertically**: one product, front and back, from the discovery through to production. Design, Frontend, Backend and API, Data, access, delivery and review are **horizontal** — services supplied to you, and to everyone else doing the same job. You draw on them and keep the outcome. What they owe you is set out at the end of this guide, under “What Ops owes a Product Builder”. ### The seven gates Seven gates, numbered 0 to 6. Nothing above them, and no sub-phases. Each gate says what you do, the steps inside it, and the prompts and templates it uses. The line that closes a gate is what you should be holding before you move on. | Gate | What you do | What you have in hand | | --- | --- | --- | | **0** | Set up the project folder | everything in one folder, converted, inventoried | | **1** | Gather the discovery | what is known, what is missing, what contradicts | | **2** | Write the PRD | what is in and what is out, agreed with the business | | **3** | Prototype the end-to-end flows | a prototype the people concerned recognize as their tool | | **4** | Port the prototype into code | a front end that runs, that you can click | | **5** | Connect the backend | the flows hold in depth | | **6** | Test, then ship | accounts in real hands, then production | Two things run across all of them rather than inside one: **the control session**, which challenges the work from the discovery to the backend, and **the standing guardrail**, which sends the agent back to your frontend starter and your backend conventions before every change to the code. Both have their own section after the gates. The build is continuous. The front stays demoable and keeps evolving; shipping is not the end of the sequence. ## Gate 0 — set up the project folder ### What you do Everything the project needs goes into one folder created for it. Not scattered across drives, mailboxes and tabs: one folder, made for this project, holding every document the work will draw on. Open your coding agent's session or project on that folder. At this point it is not a code repository. There is no application, nothing to build, nothing to run. What the session is pointed at is a folder of sources, and that is enough to start. ### The steps 1. Create the folder. Put into it every document the project needs — what was written before, what was received, what you collected yourself. 2. Create the memory and the journal in that folder, before anything else starts: `PROJECT_MEMORY.md` and `PROJECT_JOURNAL.md`. 3. Create the project channel. What goes in it: the life of the product — what was decided, what is being tested, what has just become clickable, what broke. Who is in it: everyone concerned by the product, the business people included. 4. Run the first prompt: inventory and convert. It writes the converted files into the sub-folder `converted/` and the index into `converted/INDEX.md`. It does not interpret anything. 5. Read the index it returns, and the list of what it could not read. Fill the obvious holes now, while it is cheap. 6. Tell the session to state where it is before it goes further, and keep asking for it at every gate. ### The prompts and templates it uses The setup uses two prompts, and keeping them apart is the point. The first one looks at what you have. The second one decides what it means. Mixing them gives you conclusions drawn from a pile nobody has inventoried. **The inventory and conversion prompt.** It is the one you run here. ```text You are at Gate 0 of the method: setting up a new product project. The project folder is the one this session is opened on. Work only inside it. Do this, and nothing else: 1. Walk the folder and list every file you find. 2. Convert to Markdown everything you can convert, into the sub-folder `converted/` of the project folder. Never modify, move, rename or overwrite an original. 3. Write `converted/INDEX.md`: one line per source, with the file name, what it is, and the date it is from. If you cannot date it, say so. 4. List everything you could not read or could not convert, and why. Do not analyse the content. Do not draw conclusions. Do not write a PRD. Do not send anything anywhere — no service, no channel, no address. Report the index, the list of what you could not read, and where you put the converted files. Before you finish, state which gate you are at, what you have, what is missing, and what I must decide before you cross to the next gate. ``` Two rules in that prompt matter more than they look. The originals are never touched: the conversion writes into `converted/`, so a bad conversion costs you nothing. And the pass sends nothing anywhere: it reads and writes inside the folder, full stop. **The second prompt** is the one that analyses this material and writes the PRD. It is not run here. It belongs to **Gate 2 — write the PRD**, and Gate 1 comes first. ### The agent says where it is Set this up now, because it costs one line and it holds for the rest of the build. Before it goes further, the session states which gate it is at, what it has in hand, what is missing, and what you must decide before it crosses. "I am at Gate 3" is the shape of it, followed by the three answers. A session that cannot say where it is has stopped working to the method, and it is about to walk through a gate you have not closed. ### The memory and the journal start here Create both now, at the start, before the first prompt runs. Not at the end, not when the code starts, not when you remember. They are two different things and they do two different jobs. **The project memory** — `PROJECT_MEMORY.md` — is the reasoning layer. It explains why the product moved the way it moved. It captures: - current product position; - product principles; - major decisions; - trade-offs; - known risks; - what worked; - what did not work; - which source wins when sources disagree; - open questions; - case-study angles worth preserving. The memory answers one question: where does this product stand today. It opens with the current position, and you revise that opening as the product moves. Underneath it, each decision is a dated entry, and when a later decision replaces an earlier one you add the new entry and leave the old one in place, marked as replaced. So the top of the file is always current and nothing that was decided disappears. Use it when preparing handoffs, stakeholder updates, the PRD, case studies, and future coding sessions. Entry format: ```text ## [Date] - [Decision or topic] Context: Decision: Rationale: Trade-offs: Impact on product / architecture / QA: Open questions: Links: ``` **The project journal** — `PROJECT_JOURNAL.md` — is the chronological activity log. It captures what happened over time. Each meaningful entry includes: - date; - context; - decision or change; - implementation summary; - verification performed; - trade-offs; - follow-ups; - links to tickets, pull requests, QA reports, decisions taken in chat, documentation pages, or deployed previews. The journal is appended to and never rewritten. Entries that turned out to be wrong stay in it, including the mistakes — that is most of its value, because it is the only record of why you went down a road that did not work. Do not log every tiny interface tweak. Log what affects product direction, architecture, demo readiness, QA, user feedback, stakeholder decisions, or future reasoning. Entry format: ```text ## [Date] - [Workstream or session] Context: Decision or change: Implementation summary: Verification performed: Trade-offs: Follow-ups: Links: ``` Both files live in the project folder while there is no repository. When the code starts, at Gate 4, they move into the repository under `docs/` — `docs/PROJECT_MEMORY.md`, `docs/PROJECT_JOURNAL.md`, and the PRD beside them — and they stay what an agent reads before touching the application. ### The project channel starts here too Create a channel for the project on day one and put everyone concerned in it, business people included. It exists from the first day, next to the memory and the journal, and it is where the life of the product is shared from here to production. The people who will use the tool should not be discovering it at the end. **Gate 0 — what you have in hand:** everything in one folder, converted, inventoried. ## Gate 1 — gather the discovery ### What you do The starting material varies from one project to the next, and every one of these is a normal starting point: - discovery already done by someone else, sitting in existing files; - transcripts of user interviews; - talking to the users directly; - doing the discovery yourself; - spreadsheets of products, scopes and features already drawn up, with ideation on what could be built. You will often have several of them at once, and they will not agree. That is the material, not a problem with it. ### Sources to inspect - strategy and positioning material; - operational documents on the shared drives; - existing PRDs, journals, backlogs and research in the documentation tool; - existing applications and repositories, especially what already generates revenue; - stakeholder conversations in chat; - user interviews and transcripts; - production constraints and deployment risks; - current frontend standards and starter or template guidance. The goal is not to summarise everything. The goal is to identify contradictions, ownership gaps, and cases where different teams are using the same product name for different surfaces. What you come out with: - the source list; - the ambiguity list; - the questions for stakeholders; - an initial hypothesis on the product boundary; - known privacy and compliance risks; - existing repository, starter and template constraints. Write it down, in the project folder, as `DISCOVERY.md`: the source list, the ambiguity list and the questions for stakeholders under their own headings, with the hypothesis, the risks and the constraints beside them. Gate 2 opens that file by name. A finding that stays in a chat window is a finding the next gate cannot read. ### The steps 1. **Take stock of the starting material.** Whatever of the list above you actually have, and the fact that the pieces will not agree with each other. 2. **Go through the sources to inspect.** You are looking for contradictions, ownership gaps, and the same product name used for different surfaces — not for a summary. 3. **Ask an agent to read what nobody has time to read.** By name, with the prompt below: a channel, a mailbox, a period. 4. **Keep what comes back as input, never as a decision.** The scope decision stays with you. 5. **Write `DISCOVERY.md`** in the project folder, with the headings above, so that Gate 2 can open it by name. 6. **Give the control session the material the main session read** and have it challenge what the main session concluded. ### Have an agent read what nobody has time to read There is always material that holds the answer and that no one will ever go through: months of a chat channel, the running communications with clients when the product sits between an operations team and the people it serves. Have an agent read it, analyse it, and draw conclusions that feed the discovery. You ask for this by name. It is not a scheduled routine, and it is not a job that runs in the background: you point at a channel, a mailbox, a period, and you ask. Because iterating is cheap, you can ask again at any gate — an insight that arrives while you are connecting the backend is still worth having. What comes back is input. It is never a decision. The scope decision stays with the Product Builder. ### The privacy rules, plainly - Ask before reading a channel or a mailbox. Every time. The fact that you have access is not the same as having been asked to look. - Say what was read. Name the channel, the period, the threads. Anyone who later reads a conclusion should be able to see where it came from. - Keep personal data out of what is written down. The discovery needs the pattern, not the person: what people are struggling with, not who said it about whom. The control session belongs here too: give it the material the main session read and have it challenge what the main session concluded. ### The prompts and templates it uses **The prompt for reading what nobody has time to read.** ```text You are at Gate 1 of the method: gathering the discovery. Read [name the channel, mailbox or thread, and the period]. Then: - summarise what is being said about [the product or the problem]; - list what it confirms, what it contradicts, and what is new; - name the open questions it raises for the discovery. Rules: - ask me before opening anything I have not named here; - tell me exactly what you read; - keep names, addresses and personal details out of what you write down; - return findings, not decisions. I decide what is in scope. Before you finish, state which gate you are at, what you have, what is missing, and what I must decide before you cross to Gate 2. ``` **Gate 1 — what you have in hand:** what is known, what is missing, what contradicts. ## Gate 2 — write the PRD ### What you do This is a large part of the work. The PRD defines what the tool is going to be: what you want, and what you do not want. It gives the direction section by section, and it is what the agent works from for the rest of the build. One document comes out of this gate, not two: **a PRD whose first section is the strategic framing.** Run the second setup prompt here — the one that reads the gathered material and produces that PRD from it. You do not stop there. You refine it, iterate on it, and align it with the stakeholders and the business people, including on the technical parts, even when they are not technical themselves. Those parts decide what you will need, so they get explained rather than skipped. That second prompt has to be told what to read and what to return: the converted folder and its index, `DISCOVERY.md` from Gate 1, and the fact that anything not in the folder — a channel, a mailbox, client communications — is named explicitly rather than assumed. What it returns is a first PRD, its first section the strategic framing and its other sections filled from the material, every assumption marked as an assumption, and the contradictions listed rather than resolved on its own. ### The steps 1. **Run the PRD prompt below** on the converted folder and its index, `DISCOVERY.md`, and the project memory and journal. 2. **Make it state three things separately before it writes anything:** what is established and which source establishes it; what contradicts what, source against source; what is absent. 3. **Answer its alignment questions.** Where two sources point different ways, you decide — it does not choose silently. 4. **Read the PRD it returns** and check that every assumption is marked as an assumption, with the source it rests on or with what is missing and who has to decide it. 5. **Refine it and iterate on it.** The first pass is a draft, not the document. 6. **Align it with the stakeholders and the business people,** the technical parts included: those parts decide what you will need, so explain them rather than skip them. 7. **Mark each assumption validated or waiting on a decision,** with the name of the person who takes it, and update the product boundary with what came back. 8. **Point the control session at it** — at its strategic framing section as much as at the rest. ### The strategic framing is the PRD's first section **The strategic framing** is the short statement of what the product is going to be — what is wanted, what is not wanted, the boundary it holds and the business loop it serves. It is not a separate document. It is the first section of the PRD, and the sections after it detail what it states. It is also what every later prompt means when it says to read the strategic framing: open the PRD, read its first section. The PRD lives in the project folder beside the memory and the journal, and it moves into `docs/` with them when the code starts, at Gate 4. One term, everywhere: the strategic framing. ### What the PRD contains The PRD's sections, in this order — fourteen, and no others: 1. strategic framing; 2. product boundary; 3. roles and permissions; 4. core workflows; 5. product states and data visibility; 6. privacy and ethics rules; 7. which source wins when sources disagree; 8. design baseline and acceptable drift; 9. functional depth; 10. backlog taxonomy; 11. backend and API assumptions; 12. acceptance criteria; 13. the QA contract; 14. open decisions. ### What a PRD must make explicit for AI-assisted work An agent uses the PRD as its operating context, so the PRD has to be more explicit than a classic product spec. **Product boundary.** Who the app is for; who it is not for; which workflows belong in another product; what the app must never expose; which shared core or backend objects are assumed; the non-goals. **Role and permission model.** What each role can see and do, especially when the data is sensitive. Two roles that differ only by one screen still have to be written out. **Privacy and ethics rules.** Which data is sensitive and how it must be handled. This directly controls the interface, the data model, search, exports, backend read models, and QA — so it belongs in the PRD, not in someone's head. **What wins when sources disagree.** Write the order down. For example: 1. explicit stakeholder decision; 2. validated user interview insight; 3. the strategic framing section of the current PRD; 4. the rest of the current PRD; 5. backlog ticket; 6. older documents or older prototype behaviour. Without this, agents overfit to outdated tickets. For the same reason: do not use old backlog tickets before checking the product boundary and that order. **Design baseline.** Name the design reference, and say what counts as acceptable drift from it. **Functional depth.** Say which flows must actually work in the front-only prototype and which may stay placeholders. If a user can click something, define what it does. Avoid vague simulated states unless you scoped them on purpose. **Backlog taxonomy.** Keep these apart: product decisions; implementation tasks; design parity issues; privacy and legal guardrails; QA findings; backend integration work; future nice-to-haves. It stops an agent from treating an undecided legal question as a bug to code around. **QA contract.** The personas to test; the role-based privacy checks; requirements derived from transcripts; regression flows; validation commands; the expected report format. ### When sources disagree, ask an alignment question When two sources point different ways, ask the decision-maker a short alignment question instead of silently choosing a direction. A good alignment question: - states what was observed in source A and in source B; - explains the product risk of choosing the wrong interpretation; - proposes a default direction; - asks for confirmation or correction. This is what keeps the wrong product from being encoded into the PRD and then into the prototype. What you get back: the stakeholder's confirmation, an updated product boundary, an entry in the decision log, and each PRD assumption marked either as validated or as waiting on a decision, with the name of the person who takes it. The control session can be pointed at the PRD — at its strategic framing section as much as at the rest: not only whether the PRD is coherent, but whether the direction holds. ### The prompts and templates it uses **The PRD prompt.** This is the second setup prompt, run here and not at Gate 0. ```text You are at Gate 2 of the method: writing the PRD. Read, and open nothing else without asking me first: - the converted folder `converted/` and its index `converted/INDEX.md`; - `DISCOVERY.md` in the project folder: the source list, the ambiguity list and the stakeholder questions written at Gate 1, including what an agent read on my behalf; - the project memory and the project journal; - the PRD template `../templates/prd.md`, for the shape of each section. Anything that is not in the project folder — a channel, a mailbox, client communications — is named here by me, or it is not read. First, state three things, separately: 1. what is established, and which source establishes it; 2. what contradicts what, source against source, without resolving it yourself; 3. what is absent — the questions this material does not answer. Then ask me the alignment questions. Where two sources point different ways, do not choose silently. For each one, give me: what source A says, what source B says, the product risk of choosing the wrong interpretation, the direction you would default to, and the confirmation you need from me. Then produce one document: the PRD, with these fourteen sections, in this order, and no others: 1. strategic framing — what the product is going to be, what is wanted and what is not, the boundary it holds, the business loop it serves; 2. product boundary; 3. roles and permissions; 4. core workflows; 5. product states and data visibility; 6. privacy and ethics rules; 7. which source wins when sources disagree; 8. design baseline and acceptable drift; 9. functional depth; 10. backlog taxonomy; 11. backend and API assumptions; 12. acceptance criteria; 13. the QA contract; 14. open decisions. Rules: - one document, not two: the strategic framing is the PRD's first section, and the sections after it detail what it states; - mark every assumption as an assumption, with the source it rests on or, when the material does not settle it, what is missing and who has to decide it; - invent no decision, no approval, no API and no standard; if it is not in the material, it is absent, and absent is an answer; - do not send anything anywhere — no service, no channel, no address. Before you finish, state which gate you are at, what you have, what is missing, and what I must decide before you cross to Gate 3. ``` **The template.** The PRD template can be downloaded from this gate: `../templates/prd.md`. It carries the fourteen sections above, in that order, and the list above is what decides which sections there are. **Gate 2 — what you have in hand:** what is in and what is out, agreed with the business. ## Gate 3 — prototype the end-to-end flows ### What you do The PRD exists. Now your coding agent takes the PM role: it writes the prompt for the design tool, and it prompts the design tool directly. You do not hand-write the design brief yourself, and you do not paste screens between the two by hand. One demand matters more than the rest of the prompt: **end-to-end flows, not just the major screens**. If you ask only for the main screens, you pay for it later. Every time you go deeper into a flow — a validation error, a second step, a role that sees less — you go back and forth between the coding agent and the design tool. Ask for the depth up front and that ping-pong stops. Then you iterate in the design tool itself, not in code. You show the result to the users concerned, or to the business people when it is a business application. You keep iterating until it is convincing. Convincing has one meaning here: **the people you show it to say this is the tool they need.** The method is tool-neutral. Any app-oriented design and prototyping tool works. What does not change is who writes the prompt, what the prompt must demand, and what ends the gate. ### The steps 1. **Give the session what it needs to write the brief.** The PRD, whose first section is the strategic framing, the discovery material it rests on, your organization's design system or a reference product, and the product boundary. Tell it explicitly: you are the PM for this step, you are at Gate 3, write the design prompt. 2. **Have it build the prompt as a package, not one message.** A short instruction layer, a long specification, and the attachments that should constrain the output. Compressing everything into a single chat message loses the depth. 3. **Read the prompt before it is sent.** Check five things: who the product is for and who it is not for; the roles and what each one can see; the screens and flows that must exist; the states — empty, loading, error, restricted; the privacy rules. Then check that the end-to-end demand is actually in there. 4. **Let the session prompt the design tool directly** when your tools can reach each other: it is faster, and the package arrives intact. When they cannot, you carry it yourself — paste the instruction layer, the specification and the attachments in the order they were written, and change nothing on the way. 5. **Iterate inside the design tool.** Depth first: the flows that are still surface-level, the states that are missing, the screens that lead nowhere. Use a refinement prompt rather than restarting. 6. **Show it to real people.** The users concerned. The business people when it is a business application. Show a flow they do every day, not a tour of the navigation. 7. **Iterate again on what they said, and show it again.** Stop when they tell you it is their tool. 8. **Write down what the showings changed.** What was contradicted, what was confirmed, what you dropped. That goes in the project memory and journal you created at Gate 0. ### When the gate does not close Two cases, and neither one is a reason to stall. **The people disagree with each other.** The decision goes to whoever owns the strategy — the company's chief executive, or the lead concerned — and they settle it. The decision then goes into the project memory, dated, so that the prototype and everything built on it rest on a decision someone took rather than on the last opinion heard. **The product is new and has no users yet.** You cannot invent them. You find one or two, and because the loop is fast you change things the moment they give you feedback. What you do not do is launch to everyone, or make a large announcement, for a product you know is not ready. Say that plainly rather than dress it up: there is no measure of ready. There is a minimal scope that must work, and you launch with that. If nobody could test it, you are its first user. Then you launch small, and the first real users have the last word. ### When there is no design system Stop before you invent one. House standards made up on the spot are what the review will undo later, and the prototype and the front end will stop being the same thing. Do this instead: - **Name a reference product to follow.** An existing product whose interface your organization already accepts. Name it in the design prompt and say it is a constraint, not inspiration. - **Ask Design Ops for the system.** The components and their states, the tokens, the rules for using them, what may be extended and what may not, and who maintains it. - **Record the substitute.** In the journal, dated: what you followed instead of the system, with whose agreement, and what it stands in for. The next person should be able to see what they are looking at. Until the system arrives, the reference product is what you design against, and it is what the front end will follow at Gate 4 as well — the prototype and the code must keep drawing on the same thing, whatever that thing is. When the system does arrive, the gap between it and the reference product is a list of changes to make, not a redesign. ### The prompts and templates it uses **The design prompt — long specification.** Use this for a whole product. A short prompt is enough to explore one component; it is not enough to create an application. ```text Design a full high-fidelity web application prototype for [PRODUCT NAME], [ONE-SENTENCE PRODUCT DESCRIPTION]. This is a real logged-in [B2B SaaS / internal operations / marketplace / admin] application, not a landing page. Start directly inside the product experience. Treat the attached PRD — whose first section is the strategic framing — together with the research notes, source documents and design-system references, as what decides. If a linked source is gated or unavailable, work from the pasted content and do not invent a product decision that is missing. Design end-to-end flows, not only the major screens. Every flow listed below must be walkable from its entry point to its final state, including the intermediate steps, the branches, the failures and the confirmations. ## Strategic context [Why this product exists, the business loop it serves, the constraints around it.] This product helps [PRIMARY USERS] answer: 1. [CORE USER QUESTION] 2. [CORE USER QUESTION] 3. [CORE USER QUESTION] The product should feel like [PRODUCT METAPHOR: an operations workbench, a daily work console]. Calm, precise, structured, auditable, built for repeated daily work. ## Product boundary This product is for: - [ROLE / USER GROUP] - [ROLE / USER GROUP] This product is not for: - [OUT-OF-SCOPE USER / TEAM] Do not design: - [OUT-OF-SCOPE WORKFLOW] - [OUT-OF-SCOPE SCREEN] - [INTERNAL-ONLY OR SENSITIVE SURFACE] If an out-of-scope workflow exists, represent it only as a safe status, a handoff or a request state inside this product. ## Users and roles - [ROLE]: [what they do, what they need, what they can see] - [ROLE]: [what they do, what they need, what they can see] - [READ-ONLY / ADMIN / SUPERVISOR ROLE]: [permissions and constraints] Show role-based differences wherever they materially change navigation, actions, data visibility, disabled states or empty states. ## Core product principles 1. Lead with action, not decorative analytics. 2. Make the primary workflow usable end to end. 3. Keep sensitive data role-gated and explain visibility limits clearly. 4. Prefer tables, queues, drawers, modals, tabs, filters and audit trails over marketing-style layouts. 5. Make every clickable surface imply a real behavior. 6. Do not expose internal operational complexity to users who should only see safe statuses. 7. Use realistic data density and realistic edge cases. ## Navigation and shell Use a real app shell: navigation appropriate to the roles, page header, account or organization context, notifications, language toggle where relevant, account menu, settings and administration in the right place. Primary navigation: 1. [MAIN AREA] 2. [MAIN AREA] 3. [MAIN AREA] Do not repeat the product name as a large brand row inside every page header. The shell should feel like a daily-use operational product. ## Visual direction Use [YOUR ORGANIZATION'S DESIGN SYSTEM OR REFERENCE PRODUCT]. Treat it as a constraint, not as inspiration. Use: dense operational layouts; near-white app surfaces; soft neutral background; subtle borders; compact spacing; strong readable typography; text near black; accent colors only where they carry meaning; functional status colors; status badges, segmented controls, tabs, drawers, modals, tables, filters and forms. Avoid: landing pages; hero sections; decorative gradients that are not an established pattern; oversized marketing cards; generic analytics dashboards disconnected from action; playful consumer UI; explanatory filler text inside the product UI; one-off components that do not look reusable. ## Core data concepts Represent these naturally in the UI, with their real relationships rather than disconnected cards: - [ENTITY] - [STATUS / STATE MODEL] - [DOCUMENT / REQUEST / CASE / INVOICE / REPORT] - [AUDIT EVENT] - [PERMISSION / VISIBILITY LEVEL] ## Required screens and flows Design a coherent multi-screen prototype. Include the ones this product actually has, each walkable end to end. 1. Authentication and entry: [OTP / email code / passwordless / SSO], loading, invalid code, resend, successful transition. 2. Workbench: what needs attention now — work queues, recent changes, next actions, role-specific content. 3. Primary object directory: dense list or table for [the main entity], with search, filters, counters, row status and next action, primary and secondary actions, empty state, bulk or import/export where relevant. 4. Primary creation or submission flow: a guided modal, drawer or multi-step flow, not one long undifferentiated form. Include validation, missing required fields, back and next, save and resume later, review and submit. 5. Detail workspace: header, status and key metadata, tabs or sections, related records, documents, thread or comments, activity timeline, contextual actions. 6. Requests and communication: list, categories, status and priority, creation flow, detail thread, attachments, linked object, action-required state, resolved state. 7. Documents and records: repository, detail or preview and download behavior, filters, missing-document state, replace or re-upload, access restrictions. 8. Finance, billing or reporting where relevant: overview by period, invoices or ledger, payment status, reconciliation, downloadable documents, exception workflow. 9. Settings and administration: organization settings, users and roles, role descriptions, invite and deactivate, security settings, read-only states for users without permission. ## Interaction states to include Empty; loading; validation errors; missing required fields; pending, approved, rejected, needs information, overdue, resolved; disabled actions with a stated reason; role-restricted content; notifications; audit timeline; download and export; confirmation modals; destructive-action confirmation; success and failure feedback; side panels and drawers; dropdowns and profile menus. ## Privacy, security and visibility rules Respect: - [RULE] - [RULE] Do not expose: - [SENSITIVE DATA] - [INTERNAL NOTES] - [RAW EVIDENCE] If sensitive data is needed to complete a workflow, show the approved role-gated version, a safe status, or a path to request it. ## Content and mock data Language: [French-first / English-first / bilingual]. Currency: [currency]. Organizations, people, domain vocabulary, dates and identifiers should look real. Avoid lorem ipsum. Write real product copy. ## Output expectations A polished full-product exploration, not a single screen. Prioritize clear navigation, complete product vision, realistic workflow depth, strong table and list design, reusable patterns, role and privacy logic, real operational actions, and the modals, drawers, dropdowns, tabs, empty and error states the flows need. Someone reading the result should understand what [PRODUCT NAME] becomes as a complete product, and be able to walk each main flow from end to end. ``` **The short instruction layer.** This is what gets typed into the design tool alongside the long specification and the attachments. ```text Design [PRODUCT NAME], [SHORT PRODUCT DESCRIPTION]. Use the attached design system and product documents as source material. Treat the long design prompt as the full specification and this short prompt as the instruction layer. Do not create a landing page or a concept dashboard. Start with the real product experience: [PRIMARY WORK SURFACE], [SECONDARY WORK SURFACE], [DETAIL WORKSPACE], [DEEPEST WORKFLOW]. Design deeply across the product, not only the top-level pages. Include states, variants, drawers, modals, empty, error and loading states, permission-restricted states, audit views, escalation, handoff, and safe output previews where relevant. Each main flow must be walkable end to end. Core UX: - [PRINCIPLE] - [PRINCIPLE] Must include: - [SURFACE / FLOW] - [CRITICAL STATE MODEL] - [ROLE / PERMISSION VARIANTS] Use compact, calm, high-density operational UI. Make it feel production-ready, not like a presentation. ``` **What to attach.** Only sources that should actively constrain the output: the design system or a reference product, the PRD — its strategic framing and product boundary sections included — user research or interview synthesis, workflow deep-dives, entity and state blueprints, and existing screenshots when visual parity matters. Do not attach stale documents unless the prompt says in so many words that they are legacy context and do not decide anything. **The refinement prompt.** Use it when the first output is too shallow, too conceptual or too dashboard-like. ```text Refine this into a denser operational product. Prioritize daily user work over executive analytics. The primary workflow should be obvious on the first screen. Remove any marketing-style hero, oversized explanatory card or decorative section. Increase depth: - make status, owner, next action, date, priority and permission state visible where they matter; - make the main workflow usable end to end, including its intermediate steps and its failures; - add the missing drawers, modals, dropdowns, error, empty and confirmation states; - make history and audit easy to inspect; - make document and request workflows feel functional; - make role-gated and restricted states explicit; - use realistic data and realistic edge cases; - keep the design aligned with the attached design system. ``` ### Never do these - Do not implement a new user-facing feature straight into code without a design pass. Design it first, then integrate. - Do not treat the design tool's export as production architecture. It is what you port from, not what you build on. - Do not send the prototype to be built while the people concerned are still telling you it is not their tool. **Gate 3 — what you have in hand:** a prototype the people concerned recognize as their tool. ## Gate 4 — port the prototype into code ### What you do You start from your organization's approved frontend starter repository and its backend conventions. Not from an empty folder, and not from the prototype's export. The port itself is direct. You give the coding agent the prototype and the starter, and it builds the front inside the starter's conventions. Two things this method deliberately does not ask for: a formal page-by-page rebuild, where each screen is rebuilt and signed off in turn before the next one starts, and a written map from prototype screens to front-end pages. The port from the design tool to the coding agent is close enough that neither is worth the time it costs. What there is instead is back-and-forth. Many of them. You run the front, you put it beside the design, you say what is off, the agent fixes it, you look again. That loop is the work of this gate — looking at the running front next to the design, not rebuilding it screen by screen on paper first. Before every change it makes to the code, the agent goes back to the starter's rules and to the backend conventions. That is the guardrail, and it is what keeps agent-written work inside a shape a developer can review. While the port runs, the backend waits. What you built during Gate 3 stays as it is until the front end is ready; you pick it back up at Gate 5. ### Timing **Under a day to a front end you can click.** With the discovery material already gathered: three to four hours at best, twenty-four at worst, from a folder of sources to a running front end. **About a month to make it true.** Connecting the backend so the end-to-end flows hold in depth is the long part — no method removes it. **And it passes developer review.** The agent works inside your frontend starter and your backend conventions, and re-reads them before every change. These figures are the author's own practice. They are not a study. ### The steps 1. **Clone the approved frontend starter.** Named version, from where your organization publishes it. Clone it beside the folder of sources, not inside it: the folder of sources stays what it is, and the repository is a new folder next to it. Then repoint the session at the repository — from here on that is what the agent works in — and move the working documents into it together, under `docs/`: the PRD, `PROJECT_MEMORY.md` and `PROJECT_JOURNAL.md`. All three move at once, and they stay what an agent reads before touching the application. 2. **Open the backend conventions next to it.** The agent needs them before it writes the first API-shaped service, not after. 3. **Brief the coding agent once, properly.** Use the prompt below. Hand it the prototype in a form it can actually open: an export, captures of the screens and states, or a reference it can reopen on its own. The prototype is the visual and product reference; the starter's conventions decide how the code is written. 4. **Let it port.** Whole flows, not isolated screens — you already asked the design tool for flows, keep them whole here. 5. **Run it and click it.** Walk the flows the users recognized at Gate 3. 6. **Do the back-and-forths.** Put the running front beside the design and name what is off: spacing, density, state, wording, a missing empty state, an action that does nothing. Fix, rerun, look again. 7. **Have the control session check the port.** Its job here is to confirm that what was built really comes from the design. It reads, it checks, it challenges, and it messages the main session with what it found. It does not change code and it does not decide scope. 8. **Record the port in memory and journal** — what was adapted to the starter's conventions, what was deliberately left different from the design, and why. ### When there is no approved starter and no written conventions Stop. Do not invent them, and do not let the agent invent them either. A convention you made up on the spot is the thing the review will reject later. Ask for them. This is Ops work — the horizontal teams own these services — and what you request is concrete: **From Frontend Ops** - the approved starter repository: its location, its current version, its owner, how to clone and start it, and who maintains it; - the architecture, routing and state conventions; - how components and the design system are meant to be used; - the API client pattern, authentication, error handling and loading states; - accessibility and localization rules; - the checks required on a deployable branch, and the preview or environment path; - who reviews frontend work, and how fast they answer; - an agent-readable version of all of the above, so the coding agent can re-read it before each change. **From Backend and API Ops** - the API catalog with real examples; - authentication and permission rules; - request and response shapes, errors, versioning; - the business meaning of key fields and status values; - reference patterns for auth, migrations and tests; - a test environment with test identities and safe data; - read-only access to logs, errors and health, and who to reach when something breaks; - the procedure for requesting an API that does not exist yet. Until those arrive, you can keep the prototype moving and keep gathering what Gate 5 will need. Do not start a foundation you will have to throw away. Use a documented temporary equivalent only when you and the accountable lead explicitly accept the gap — written down, with the gap named and dated in the project journal, so the next person can see what they are looking at and what it stands in for. One thing this gate is not: a handoff. You port the front yourself and you will connect the back yourself at Gate 5. Frontend and backend engineers are horizontal services to your vertical work — they give you the starter, the conventions and the review. The work is not passed to them. ### The prompts and templates it uses **The coding-agent prompt.** ```text You are at Gate 4 of the method: porting the prototype into code. You are implementing [PRODUCT / SLICE]. Read before coding: - the prototype from Gate 3, in the form it was handed to you - the PRD, whose first section is the strategic framing - the approved frontend starter repository and its conventions - the backend conventions - the project memory and journal Product boundary: [WHO THE PRODUCT IS FOR, WHO IT IS NOT FOR, AND WHAT MUST NOT BE BUILT HERE] Rules: - the prototype is the visual and product reference; - the starter repository and its conventions decide how the code is written; - do not paste the design tool's export into the application foundation; - keep routes thin; - put domain logic in feature folders; - use the organization's shared primitives before creating anything new; - route mock data through API-shaped services that match the future backend contracts; - centralize copy and localization; - enforce role and privacy rules at the read-model level; - do not redesign anything unless you are explicitly asked to; - before each change to the code, re-read the starter's rules and the backend conventions. Current task: [THE FLOW, SCREEN OR FIX] Acceptance criteria: - the flow works end to end in the front-end mock; - the result matches the design where the design is non-negotiable; - no privacy regression; - relevant tests added or updated; - project memory and journal updated if this changed product behavior, architecture, a stakeholder decision or future reasoning. Run before finishing: - typecheck - lint - tests - build - click through the flow in a browser Report: - which gate you are at, what you have, what is missing, and what I must decide before you cross - what changed - what you actually ran and what it returned - memory and journal updates made, or explicitly skipped with the reason - remaining open product or backend decisions ``` **The standing constraint to carry in every coding prompt.** ```text If your work changes product behavior, architecture, a stakeholder decision or future reasoning, update the project memory and the project journal. Memory holds decisions and trade-offs; the journal holds the chronological record. Do not log small cosmetic changes unless they affect product direction or demo readiness. Before finishing, state whether memory and journal were updated, or why no update was needed, and state which gate you are at, what is missing, and what I must decide before you cross. ``` ### Never do these - Do not let the coding agent redesign the UI while porting it. - Do not start a new frontend foundation because the approved starter was hard to find. Ask for it. - Do not accept a green build as evidence that the flow works. Click it. **Gate 4 — what you have in hand:** a front end that runs, that you can click. ## Gate 5 — connect the backend ### What you do You take the front end you can click and connect it to a real backend, flow by flow, until the end-to-end flows hold in depth and not on the surface. **You build that backend yourself, in the session you are already in.** You do not open a second one, and you do not hand the backend to anyone: the Product Builder owns the outcome front and back. What runs in parallel is the backend and the **design** work — not the backend and the port. While the prototype is being iterated in the design tool at Gate 3, there is no front-end code yet, so nothing can collide, and endpoints, data model, authentication and permissions can be built ahead. When the design is done, backend work stops. The port runs at Gate 4 and you leave the backend alone. Only once the front end is ready do you go back to the backend, connect what the front needs, and carry on with it. The connection itself is the longest part of the whole method. A project has one frontend repository and one backend repository. Keep it that way. ### Timing Count **about a month** on average to connect the backend so the flows hold in depth. Two conditions, and only these two: it is the author's own practice, not a study, and it depends on the size of the application. The front end arrives fast; the depth does not, and no method removes that part. ### The steps 1. **Pick the backend back up where the port left it.** What you built while the design was being iterated — endpoints, data model, authentication, permissions — waited untouched through Gate 4. You carry on with it now, in the same session, with the running front end in front of you. 2. **Replace one service at a time.** The front was built on mock services shaped like the backend contract. Swap them flow by flow, not screen by screen. A flow is what a person does from beginning to end, not the page they are standing on. 3. **Go deep on each flow before moving to the next.** The happy path is not the flow. Take the empty state, the error, the slow response, the permission that says no, the record that already exists, the value that arrives malformed. Surface-level connection is what makes a product look finished and behave broken. 4. **Enforce roles and privacy at the read-model level,** not in the component that displays the data. What a person must not see should never reach the browser. 5. **Re-read the rules before every change to the code.** Each time the agent is about to touch the code, it goes back to your frontend starter conventions and your backend conventions. 6. **Call the control session when there are bugs or doubts.** It reads, checks and challenges: does this flow really do what the PRD says, is the failure handled, is the permission real. It does not change the code and it does not decide scope. It returns findings with their evidence, and you decide. The two sessions talk to each other directly: when the control session observes something, it sends the message to the main session itself. How you wire that up in the tool you use is yours to set up — this kit does not document it for any particular assistant. 7. **Write down what you decided, when you decided it.** Decisions, trade-offs and what you now know go to the memory. What changed, why, and what you verified goes to the journal, dated. 8. **Keep the front demoable the whole way through.** Never let the connection work take the product offline for the people waiting to see it. ### The prompts and templates it uses **Connection prompt**, given to the main session for one flow: ```text You are at Gate 5 of the method: connecting the backend. Before coding, read: - the PRD, whose first section is the strategic framing - your frontend starter rules and conventions - your backend conventions - the project memory and journal Current task: [ONE FLOW, END TO END] Acceptance criteria: - the user-facing flow works end to end against the real backend - empty, loading, error and permission-denied states are handled - no privacy regression - relevant tests are added or updated - project memory and journal are updated if the work changes product behavior, architecture, stakeholder decisions, or future reasoning Run before finishing: - typecheck - lint - tests - build - diff check - walk the connected flow in a browser, end to end, including its empty, error and permission-denied states Report which gate you are at, what is missing, what I must decide before you cross, what changed, what was verified, and any remaining product or backend decision. ``` **Control session call**, when a flow misbehaves or you are not sure it is real: give it the flow, the PRD section that defines it, and the running product. Ask it to reproduce, not to fix. **Gate 5 — what you have in hand:** the flows hold in depth. ## Gate 6 — test, then ship ### What you do You put the product in real hands while the connection work is still going on, you fix what comes back, and then you ship with the leads of the trades concerned. Testing is not a stage at the end. It runs alongside Gate 5 and it is your pilot: it tells you the flows hold and that the product was designed right. Waiting until everything is connected to let anyone touch it is how you find out too late that the tool was not the one they needed. ### The steps 1. **Give access while the connection work is still going on.** Demo accounts while authentication is not connected, real accounts once it is, sent to the people who should test. 2. **Share the life of the product in the project channel.** What just got connected, what is now clickable, what broke, what you decided. 3. **Fix what comes back, as it comes back.** As long as you handle defects as they appear, they need no labels. 4. **Start classifying only when there are more defects than a session can hold.** That is the moment you are tracking them instead of fixing them, and P0, P1 and P2 start earning their keep. 5. **Walk the delivery path.** Local, then the repository, then staging. 6. **Prepare the release with the prompt below,** and take the go-ahead with the leads of the trades concerned — engineering, backend, frontend, data. 7. **Ship.** The freeze applies in one case only: an MVP that has to go to production, where what is in the release stops moving until it is out. 8. **Record the release in the journal** and keep going: the front stays demoable and the build continues. ### How you give access It depends on where the backend is. - **Authentication not connected yet** — create demo accounts and send them to the people who should test. They click through what exists. - **Authentication connected** — create real accounts for the people concerned and send them. ### What you share in the channel The project channel was created at Gate 0, with everyone concerned in it, business people included. While they test, that is where the life of the product is shared: what just got connected, what is now clickable, what broke, what you decided. ### Severities, and when they start Defects that come back get a severity once you are tracking them rather than fixing them straight away. The trigger is simple. As long as you handle defects as they appear, the labels add nothing: you fix the thing and move on. The moment there are more of them than a session's worth to hold in your head, you are tracking a list instead of clearing it — and that is where the classification earns its keep, because it is what lets you say what is being fixed now and what is waiting. Plain meanings, at first use: **P0**, blocking; **P1**, important; **P2**, minor. ### The delivery path Local, then the repository, then staging. From staging to production the step is not taken alone: the leads of the trades concerned — engineering, backend, frontend, data — check that everything is in order before shipping. Treat it as a go-ahead, not as an approval board. It is short, it is about whether the thing is in order, and it is where the vertical work goes back through the horizontal Ops services that supported it: the people who own the frontend conventions, the backend conventions, the data and the delivery path confirm that what you built sits inside them. It is also the honest answer to the objection this way of working attracts — one person shipping to production what an agent wrote. The answer is that it is read by the trades before it goes out. ### When there is no staging, no delivery path and no reviewing leads Ask for them, the same way you asked at Gate 3 and Gate 4, with a named owner and a named artifact: the path from local to the repository to staging to production, the checks that run along the way, a way to see which revision is live, and the people who give the go-ahead before production. Meanwhile, the honest answer is a small one, and you say it out loud rather than dressing it up: you ship what you can verify yourself — the flows you walked end to end, the empty, error and permission-denied states you exercised, the checks you ran and what they returned — and you write in the journal, dated, which review did not take place and who was not there to give it. Nobody should have to reconstruct later what was read before it went out, and the gap you recorded is the request you make again next time. ### The one case where things are deliberately frozen An MVP that has to go to production. There, what is in the release stops moving: you fix what is in it, you do not add to it, until it is out. That freeze belongs to that moment, not to the method as a whole. Everywhere else the product keeps moving. ### After shipping The front stays demoable and keeps evolving. Shipping is not the end of the sequence; the build is continuous. You go back into flows, deepen them, connect what was left, and show it again in the channel. Record the release in the journal, using the journal entry format from Gate 0. ### The prompts and templates it uses **The release prompt.** Run it in the main session once staging holds what you intend to ship. ```text You are at Gate 6 of the method: test, then ship. Read before you write anything: - the PRD, whose first section is the strategic framing - the project memory and the project journal - what changed in the repository since the last release Prepare the release note for the leads of the trades concerned — engineering, backend, frontend, data. State these, and invent none of them: - what is in this release, flow by flow; - what has been tested, by whom, and with which accounts — demo accounts or real ones; - what was verified and how: the flows walked end to end, the empty, error and permission-denied states exercised, the checks that were run and what they returned; - what is known to be broken or unfinished, and where it is being tracked; - what the leads are being asked to give the go-ahead on; - which review did not take place, if one could not, and who was not there to give it. If something was not tested, say it was not tested. A gap named is the request I make next time. Do not send anything anywhere — no service, no channel, no address. Before you finish, state which gate you are at, what you have, what is missing, and what I must decide before this goes to production. ``` **Gate 6 — what you have in hand:** accounts in real hands, then production. ## The control session The control session is not a gate. It runs alongside them, from the discovery to the backend, and it is the one practice the author calls their safety harness. You work in two sessions, side by side. The main session is the one you are in; it is where the building happens. The second session has one job: to challenge the first. It is not a review stage bolted on at the end — it is open the whole time and you call it in wherever doubt sits. ### Where you call it in - **At Gate 1**, it challenges the discovery findings of the main session: what the main session concluded, checked against the material it actually read. - **At Gate 2**, it can challenge the PRD, its strategic framing section as much as the rest — not only whether the PRD is coherent, but whether the direction holds. - **After Gate 4**, it checks that what was built really comes from the design. - **During Gate 5**, you relaunch it on backend bugs and on doubts: a flow that behaves oddly, a result you do not believe. ### The rule Write these limits into the control session at its first prompt, and repeat them when it strays. - It reads, checks and challenges. - It does not change code. - It does not decide scope. - It does not write the PRD and it does not write the prompts. - It returns findings with their evidence, and the Product Builder decides. That last line is the whole point. The control session produces findings, never decisions. ### The two sessions talk to each other When the control session observes something, it sends its finding to the main session directly. That exchange between the two sessions is part of the practice — not a report a human reads in one window and retypes into the other. You stay in the loop and you decide what the main session does with what it receives. What this kit does not carry is the wiring. How one session addresses the other in the tool you work in is something you set up in that tool; nothing here documents it for a given assistant. The practice is one thing, the plumbing another, and only the first is described in this guide. ### The drift, and what prevents it A control session with no written limits slides into becoming the PM session. It starts deciding what is in scope, rewriting parts of the PRD, writing the prompts for the main session — and then you have two building sessions and no harness. The author has seen this happen in their own practice and puts it down to discipline rather than to the design of the practice. The rule above is what prevents it: the limits are written down, they are part of the control session's starting prompt, and you restate them the moment the session starts proposing instead of reporting. Two sessions, and only two: one main session and one control session. Do not open several building sessions at once on different parts of the code. Their scopes overlap, and what comes out of that is bugs. ### Starting prompt for a control session Works in any tool. Fill the brackets and keep the rules block unchanged between runs. ```text You are the control session for [PRODUCT]. The work is at [GATE]. Your job is to read, check and challenge the work of the main session. Do not trust its claims. Check them against the material. Read what exists at this gate, and nothing that does not: - the discovery material in the project folder, and `DISCOVERY.md` once Gate 1 has written it - the project memory and the project journal - from Gate 2 onward, the PRD, whose first section is the strategic framing, and the product decisions - from Gate 3 onward, the design the front end is ported from - from Gate 4 onward, the repository Tell me what you read, and what did not exist yet at this gate. What I am asking you to check now: [ONE AREA: the discovery findings / the PRD / its strategic framing / what was ported from the design / a backend flow / a bug] Rules, which do not change between runs: - you read, check and challenge - you do not change code - you do not decide scope - you do not write the PRD and you do not write the prompts - you return findings with their evidence, and I decide Return: - which gate the work is at, what it has, what is missing, and what I must decide before it crosses - each finding with the evidence it rests on: the file, the screen, the flow, the section of the PRD, the steps that reproduce it - what you could not check, and why - product decisions separated from defects - [once defects are being tracked rather than fixed as they appear, mark each finding P0, P1 or P2] When you observe something, send it to the main session as well as to me: [how this tool addresses the main session — if it cannot, hand it to me and I will relay it unchanged] ``` The adapters cover installation. What goes in that last bracket — how the two sessions reach each other in your tool — you set up in the tool itself; this kit does not document it for any particular assistant. If they cannot reach each other at all, you relay: you paste the finding into the main session yourself, unchanged, and you say where it came from. What does not change is the practice: the control session addresses the main session with what it found, and you decide what happens next. ## The standing guardrail Before the agent changes code, it goes back to the organization's frontend starter and to the backend conventions. It re-reads them, and they frame how it reasons before it writes anything. Not once at the start of the project — every time it is about to touch the application. This is what makes the work reviewable. The code is generated, and it still goes to developers for review, and it passes, because it was produced inside the organization's own standards instead of alongside them. ### The agent states its gate The other half of the guardrail: the session says where it is before it goes further — which gate it is at, what it has in hand, what is missing, and what you must decide before it crosses. Ask for it at every gate, and treat a session that cannot answer as a session that has left the method. ### Read before coding - the prototype from Gate 3, in the form it was handed to you; - the PRD, whose first section is the strategic framing; - the organization's frontend starter and its written conventions; - the backend conventions; - the project memory and the project journal; - the QA contract carried in the PRD. ### What every code-generating prompt restates Do not assume the agent still holds this from earlier in the session. Put it in the prompt each time: - the organization's frontend starter is the technical reference; - the prototype is only the visual and product reference; - routes stay thin; - domain code belongs in feature folders; - shared UI uses the design system's existing primitives first; - copy is centralized, not written into each page; - mock data goes through services shaped like the future API; - role and privacy rules are enforced at the read-model level; - no one-off redesign and no new component system without explicit approval; - do not paste the design-tool export into the application as its foundation; - state which gate you are at, what is missing, and what I must decide before you cross. ### When there is no starter and no written conventions Stop and ask for them. This is a request to Frontend Ops or to the backend owners, not a problem to solve by yourself in the repository: every convention you invent locally is something a reviewer will have to undo. What to ask for, and what to do while you wait, is at Gate 4. ## What Ops owes a Product Builder You own the outcome vertically. Design, Frontend, Backend and API, Data, access, delivery and review are horizontal: services supplied to you, and to everyone else doing the same job. For this method to run, those services have to supply: - **a frontend starter with the conventions encoded in it** — app shell, routes, feature folders, shared components and primitives, domain types, API-shaped services, copy and localization files, tests — so that you make no architecture decision while you build; - **a backend foundation with precedents to copy**: authentication, permissions, request and error shapes, migrations, a test environment with safe data, and a written way to ask for an API that does not exist yet; - **a data service**: where the reference data lives, the business meaning of key fields and status values, a test dataset that is safe to use, and the rules on what may be exported, by whom and to where; - **a design system** that both the prototype and the front end draw on, so that what the design tool produces and what the code produces are the same thing; - **access paths**: a written request route, an approver, a least-privilege default, a response target, and an owner for expiry and rotation; - **staging and delivery**: a path from local, to the repository, to staging, to production, with the checks that run along the way and a way to see which revision is live; - **review**: developers who read the generated code, and the leads of the trades concerned who give the go-ahead before production. Each of these has a named owner you can reach. "Ask someone" is not a route. ### The optional self-check The self-check is the list above, read as a list of what you have and what you do not. It is optional. There is no score, no threshold, and nothing in it stops you from starting at Gate 0 — you can run it on the first day, in the middle of the build, or never. Go down the seven lines. For each one, try to name the artifact and the person. Every line you cannot name is a single thing to ask a named Ops owner for. That is its only purpose: to turn "this is harder than it should be" into a request with a name on it. Why it exists: if your organization already supplies all of the above, you do not need it. You will read the list, recognize everything, and move on. If you are starting without those services, you will hit exactly the problems the services were built to remove — an architecture you had to invent yourself, access you cannot obtain, a front end nobody has agreed to review, no path to staging. The list lets you see them coming and ask early, instead of discovering them one at a time in the middle of a build. Text licensed CC BY 4.0. Code MIT.