Standards Pub Quiz - Spec-First Build Round
7 questions, 20 seconds each. Use Mentimeter or Slido. Individual answers on phones, points go to tables (averaged).
This round runs right after the build - every answer is a standard the team just used hands-on. The point isn’t trivia recall; it’s “you already did this for real, now name it.” Read the canonical sources first if you want to challenge an answer: the five ways of working, the machine-readable contract, and the corporate standards in docs/corporate-standards-main/.
3 points per correct answer per table.
Questions
Q1: Machine-Readable Contracts
Which standard says your API must ship a machine-readable spec (OpenAPI) that stays in sync with the code?
- A) REQ-API-1 (API as a product)
- B) REQ-API-2 (correct)
- C) REQ-API-5 (consistent conventions)
- D) ENG-PRIN-DOC-STMT (ADRs)
Answer: REQ-API-2 - a machine-readable OpenAPI spec, kept in sync with the implementation. It’s the file you froze at Gate 1 before writing a line of /recommend: stacks/nextjs/openapi.yaml. REQ-API-1 is “treat the API as a product”; REQ-API-2 is the artifact that makes that real.
Q2: Where to Test Business Logic
You’ve got the gapScore calculation for /recommend. What’s the lowest viable layer to test it at?
- A) End-to-end (drive the browser)
- B) System / API test against a running server
- C) Unit test on the calculation function (correct)
- D) Manual click-through before the demo
Answer: Unit (QTEST-EARLY + QTEST-UNIT). Test at the lowest viable layer - pure logic like gapScore = 1.0 - value belongs in a fast unit test, not an expensive E2E run. Pushing it down is also QUAL-PRINC-AUTOMATION (the lowest layer of the pyramid) and QUAL-PRINC-WASTE (no slow test doing a fast test’s job).
Q3: Approving Your Own PR
Your AI pair wrote the code, you read every line, it’s green. Can you merge your own PR?
- A) Yes - you reviewed it yourself, line by line
- B) Yes - the AI already reviewed it
- C) No - another human must approve it (correct)
- D) Only if all the tests pass
Answer: No. ENG-PRIN-REVIEW-STMT - no change reaches trunk without review by another human; no self-merge. The AI can assist the review, but it cannot be the approver. This is Way #2: a human always signs the work.
Q4: What an ADR Captures
You wrote a one-line ADR: “computed team averages on the fly - dataset is tiny.” What is the ADR primarily recording?
- A) The code you wrote
- B) The why - the decision and its reasoning (correct)
- C) The test results
- D) The API response shape
Answer: The why. ENG-PRIN-DOC-STMT - document decisions, not code. An ADR captures the choice and the trade-off so the decision outlives the conversation it was made in. The code shows what; the ADR explains why you didn’t do the other thing. This is the back half of Way #5: keep it simple, write down the why.
Q5: What E2E Should Cover
You have unit and contract tests already. What should your single end-to-end test cover?
- A) Every edge case and error path
- B) The happy path only (correct)
- C) Nothing - E2E tests are banned
- D) The same cases as the unit tests, for safety
Answer: The happy path only (QTEST-E2E). E2E tests are slow and brittle, so they prove the whole flow holds together for the main journey - edge cases and error paths get caught cheaper, lower down (QTEST-EARLY, QTEST-NO-DUP). Re-running unit-level cases at E2E is exactly the duplication QUAL-PRINC-AUTOMATION tells you to avoid.
Q6: Is GET Idempotent?
GET /compare - call it once or call it five times in a row. Does it need an Idempotency-Key header?
- A) Yes - every endpoint needs one
- B) No - GET is safe and idempotent already (correct)
- C) Only if it’s behind the gateway
- D) Only on the fifth call
Answer: No (REQ-API-6). GET is safe and idempotent by definition - repeating it changes nothing, so no Idempotency-Key is needed. The key matters when a write must survive a retry. The /compare spec calls this out inline: if it ever became a write, REQ-API-6 would require the header. See the description in openapi.yaml.
Q7: Small Steps
Which standard backs the “stub + failing test first, then implement, in reviewable increments” rhythm you used?
- A) ENG-PRIN-TRUNK-STMT (short-lived branches)
- B) ENG-PRIN-INCR-STMT (correct)
- C) ENG-PRIN-CLEAN-STMT (clean code)
- D) QUAL-PRINC-SHIFT-LEFT (defect prevention)
Answer: ENG-PRIN-INCR-STMT - many small commits over large batches, easier to review and revert. ENG-PRIN-TRUNK-STMT (short-lived branches, frequent integration) is its close cousin and a defensible “also-correct” if a table argues for it - award the point. This is Way #4: small steps, not big leaps.
Scoring
| Table | Q1 | Q2 | Q3 | Q4 | Q5 | Q6 | Q7 | Total |
|---|---|---|---|---|---|---|---|---|
| 1 | ||||||||
| 2 | ||||||||
| 3 | ||||||||
| 4 | ||||||||
| 5 | ||||||||
| 6 |
Max per table: 21 points.
Scoring note: Q3, Q5, and Q6 are the “gotcha” questions where confident teams lose points - read the answer aloud and tie it back to what they did in the build (“you froze the contract before coding - that was REQ-API-2”). On Q7, accept ENG-PRIN-TRUNK-STMT as well if a table makes the case; the two travel together. Keep it loose and fast - the debrief is worth more than the points.
Mentimeter Setup
- Create a new Mentimeter presentation.
- Add 7 “Multiple Choice” slides.
- Set the timer to 20 seconds per question.
- Enable “Show correct answer” after each question.
- Set scoring to “Fastest correct answer gets most points.”
- After each reveal, say the cite ID out loud - the standard owners are in the room and this is how the Ways stay anchored to real IDs.
- At the end, export results by table.
Part of the Spec-First Build session - see the folder index. The five ways of working: ways-of-working.md.