The one format question we never closed yesterday. This is the proposal, and where it fits inside the playbook you're already drafting.
Documentation of what perfect looks like. North Star. PRDs. Design intent. QA cases.
Designing and building against the intent. Quality kept up as the code is written, not after.
The final stage gate before production. Real services. Real flows. Tag-cut, not every commit.
In-production signal. New regressions surface as new QA cases, feeding back to Phase 01.
"We have to think beyond the post-deployment. Before the code is written. And also we have design and engineering. How do we find solutions that speak to the documentation of what the North Star is?" Pascal, 05/12 (paraphrased lightly for slide)
QA cases sit in Phase 01. They are the intent document. Phase 02 translates them into running tests. Phase 03 gates on them. Phase 04 generates new ones. They are the single artifact that crosses every phase.
Yes for ESLint, TypeScript, Prettier, A11y, bundle. They are the parallel layer underneath the pyramid. They read the code as you type. They never run it.
Three layers, three confidence levels. Unit tests run alone in seconds. Functional drives the UI with mocks. E2E drives the real services on tag-cut releases.
Functional and E2E are the same Playwright suite in two modes (mocked vs real). Tags (@critical, @ft-only, @e2e-only) decide what runs where.
Locally the agent reacts in seconds. CI is the artifact we sign off on. We are not paying CI minutes for things that should have failed at the keyboard.
They do, but only because they run at different times on different surfaces. The stack is a timeline, not a checklist. Read it left-to-right.
"Most of our confidence in the app, or pretty much all of it right now, comes from people clicking through it." Keith on the problem, 05/12
"If you wrote them out as when you're on this page, I would click this, I would type this, I would expect it to say this. These are the actual phrases that would mimic the test." Keith on the proposal, 05/12
Anyone can write one. A QA in India, a designer, you, Claude. No code. No selectors. Just intent.
Using the repo's Page Objects, Fixtures, Factories. One translation pattern across BFD.
Tags pin the runner. @critical in both modes. @ft-only on PR. @e2e-only on release.
--- id: web.auth.login.google title: Web sign-in shows Google button, starts OAuth app: web # web | admin | api area: authentication tags: [@critical] # critical | ft-only | e2e-only owners: [pascal, keith] --- ## Setup - The user is signed out. - Mocks: auth.google.start, auth.google.callback. ## Steps 1. I navigate to /authentication/login. 2. I expect "Sign in with Google" to be visible. 3. I click "Sign in with Google". 4. I wait for the URL to leave /authentication/login. ## Assertions - The button renders before any click. - Clicking leaves the login route (mocked OAuth). ## Out of scope - Real Google OAuth (covered by @e2e-only case).
It is product language, not code. A QA in India already writes briefs exactly like this. A designer who knows the flow can. You can.
Frontmatter pins the file location. Tags pin the runner. "I click label" maps onto a Page Object method. The case is the prompt.
Serious QA teams have shipped this brief for years. We are just giving the agent the same one.
## Steps 1. I navigate to /authentication/login. 2. I expect "Sign in with Google" to be visible. 3. I click "Sign in with Google". 4. I wait for the URL to leave the login route.
import { test, expect } from '../../fixtures/unified'; test.describe('Web Login @critical', () => { test('shows Google sign-in, starts OAuth', async ({ mockedPage, loginPage }) => { await loginPage.goto(); await expect(loginPage.googleLoginButton).toBeVisible(); await Promise.all([ mockedPage.waitForURL(u => !u.toString().includes('/authentication/login')), loginPage.clickGoogleLogin(), ]); }); });
bfd-express-base: led by Reggie. Lifted directly from TP. bfd-convex-base: led by Keith, because Keith carries the Convex port. Both ship as scaffolds with the playbook inside.
bfd-express-base by Friday.bfd-convex-base following Reggie's architecture.You asked yesterday whether you could mess around with Playwright in the interim. Reggie's answer: it is not a tool a QA person uses to test a site, it is code you write into the repo so we do not need a person to test the site. If you want to feel the loop yourself, Playwright Codegen is the one surface for humans. You open a page, click around, and it writes the TypeScript for you. That is the closest thing to a workbench. Everything else runs without a human at the wheel.
| # | The call | Proposal | Owner |
|---|---|---|---|
| 1 | Lock the QA-case Markdown schema. Frontmatter · Setup · Steps · Assertions · Out of scope. |
Yes, lock it. Extend later via tags, not schema changes. | Keith ships the schema doc by EOD. |
| 2 | Pascal as QA Case Editor + Playbook Owner. Sets the bar. Reviews dev-authored cases. Writes the playbook. |
Yes. Devs author against the schema. Pascal reviews before translation. Pascal writes cases himself where he is the SME. | Pascal |
| 3 | NCEE TP as reference architecture, templatized into two bases. The thing Claude translates into. |
Yes. Reggie extracts bfd-express-base. Keith builds bfd-convex-base on the same shape. |
Reggie + Keith |