One workflow, all the way through

Sessions 3 to 12 each built one part: the schema, the names, the matrix, the access rules, sign-in, the clamps, three surfaces and the skill of directing an agent. Session 13 joins them into one working loop for one real form, so a record entered on the operator screen reaches the manager view through the review queue. That is also the end-to-end criterion of Homework 4 and an item on the certification practical.

The course example stays with Acme's first-off check sheet on Line 3 (Acme is an illustrative plant). Use the paper form your own intent named: a start-up checklist, a downtime log, a torque record, a sanitation sign-off. The method is the same.

How it is scored

The element is complete when you have opened every chapter and taken the assessment, and passed at 80% or more.

Go and see the form in use

Before you design anything, watch the form being filled in, on the floor, on a real shift. Lean practice calls this going to the gemba, the place where the work is done ^[1]. You will see what no document says: the box nobody fills, the column people use for something else, the note scribbled in the margin because there was no box for it. Bring three filled-in sheets back with you; they are your first test data.

Paper forms in quality work are often check sheets: simple, structured forms for collecting data where it happens ^[2]. Their strength is that anyone can fill them in; their weakness is everything after: copying, adding up and finding them. The screen keeps the strength and removes the weakness.

Four questions for every box

Write the field list

For each field that survives, write one row: the name in your naming standard from Session 5, its type, its unit, its limits, where it comes from and which roles in the matrix may read or write it. This list is the input to Brief 1; with it, the agent has almost nothing to guess.

Paper rules still apply

If your plant works under a quality system such as ISO 9001, the form is a controlled record: it must be identifiable, protected from loss and kept for a defined time ^[3]. If it is a record FDA rules require, moving it to a screen brings it under the electronic records rule, with its audit trail and access requirements ^[4]. The design from Sessions 7 to 11 (append-only records, attributable entries, role-based access, an audit trail of every review) is built to meet that kind of requirement; check the specific rules that apply to your plant with your quality lead before you retire the paper.

Split by layer, in order

Each layer stands on the one below. The surfaces cannot be built well until the table, its access rules and some realistic data exist, and the board cannot count approved checks until reviews exist. So the briefs run in order, each merged before the next starts. Anthropic's guidance for its agent recommends exactly this kind of decomposition into well-defined steps with checks between them ^[1].

The end-to-end test

The four briefs each have their own checks. One more test proves they work together: it signs in as an operator and a supervisor in two browser contexts, sends a record through the whole path, and reads the database at every stop. Write it before Brief 2 starts; it fails until Brief 4 is merged, and then it guards the workflow on every pull request after that. Playwright supports several independent browser contexts in one test, which is how one test can play two people ^[2].

test("a first-off check travels from operator to board, including a rejection", async ({ browser }) => {
  const operator = await signedInPage(browser, "operator-line3");
  const supervisor = await signedInPage(browser, "supervisor-shift-b");

  // 1. The operator enters a check with flange height above its limit.
  const first = await submitFirstOff(operator, { press: "L3-P02", hole: "12.02", flange: "25.31", burr: "0.03" });
  expect(await row("first_off_checks", first)).toMatchObject({ result: "fail", entered_by: ids.operator });

  // 2. The supervisor sees the difference and rejects it with a reason.
  await supervisor.goto("/review");
  await expect(supervisor.getByText("+0.11 above limit")).toBeVisible();
  await reject(supervisor, first, "Flange high: adjust die and re-measure");
  expect(await reviews(first)).toEqual([expect.objectContaining({ decision: "rejected", reviewer: ids.supervisor })]);

  // 3. The operator re-measures; the new check corrects the first.
  const second = await submitFirstOff(operator, { press: "L3-P02", hole: "12.01", flange: "25.04", burr: "0.02", corrects: first });
  await approve(supervisor, second);

  // 4. The board counts both: one first-time fail, one approved release.
  await supervisor.goto("/board");
  await expect(supervisor.getByTestId("first-pass-yield")).toContainText("0 of 1 first time");
  await expect(supervisor.getByTestId("checks-approved")).toContainText("1");
});

Keep the evidence

Homework 4 asks for your briefs, the changes the agent made, and your acceptance checks with their results. Keep each brief in docs/briefs/, link each pull request to its brief, and note in the pull request any problem you found while reading it and how it was fixed. If you rewrite a brief, keep both versions and one line on why. Record what the agent's work cost if your plan shows it: that is the exemplary level.

Follow the data trail

A screen can say Saved while the database holds nothing, or two rows, or the right row with the wrong person. So the end-to-end test reads the database after every step, and so should you the first time you run the workflow by hand. Open the table in Supabase's table editor beside the screen and watch each row arrive ^[1].

Put it in front of the floor

Tests find what you thought of. Operators find the rest: the label that reads differently on a dirty screen, the field order that does not match how they measure, the glove that does not register on one button. Ask one operator and one supervisor to use it on a real shift on one line, with you watching and not helping. Homework 3's exemplary level asks for exactly this: tested by an operator on the floor.

Run it beside the paper

Do not retire the paper on day one. For a week, on the pilot line, the operator fills in both. At the end of each shift, compare: the same number of checks, the same values, the same pass or fail. Every mismatch has a cause, and the cause is either a bug, a training gap or a paper error the screen has just caught. Medical-device software guidance makes the same point in general terms: confirm a system works for its intended use, in its real environment, before relying on it ^[2].

Decide, and write it down

At the end of the parallel week, the supervisor and the quality lead decide: go, or another week. Write the decision as a short record in the repository (docs/go-live/workflow-1.md): the week's counts, every mismatch and its cause, who decided and when. Then, and only then, retire the paper on that line. The other lines follow one at a time. Session 21 does the same for the whole platform.