Implementor Onboarding Exercises

Fill in the blanks to test your knowledge.

Complete the foundational rule. When spec and code disagree, the ___ is correct and the code is the ___.

// The rule the whole methodology rests on

// The is the authoritative artifact.

// The code is its compiled form.

// When they disagree, the code is the .

// Failure mode: code written BEFORE its governing spec makes the

// code the truth by default. The spec becomes documentation and

// loses its power to constrain.

Complete the intent capture. The question people skip is the ___ signal — how you would know it worked.

// INTENT CAPTURE — [tenant] — [date]

// Who is this for? the specific person, not "users"

// What are they doing? in their words, one sentence

// What happens today? current process, including manual parts

// What does it cost? time, lost work, rework, risk

// What does better look like? observable

// What must NOT change? the load-bearing things that work

// What is out of ? say it out loud now

// How will we know it worked? the signal, one checkable sentence

Complete the session note. The most-skipped and most-valuable section is "___", and the note records ___ rather than intentions.

// SESSION NOTE — [tenant] — [date]

// Goal. what this session was for

// Landed. done AND verified — not "worked on"

// In flight. half-done, and precisely where it stopped

// Decisions made. anything chosen where another option was reasonable

// Blocked on. what is waiting, and on whom

// Next. one concrete action, startable cold

// . what was tried and REJECTED, so it is not retried

// Write the note from what you can , not from what you did.

A check returns three outcomes, not two. Name the third, and the trap of collapsing it.

// Three outcomes

// yes

// no

// <- the one that gets collapsed into "no"

// Collapsing it yields a TRUE sentence about the WRONG cause,

// which ends the investigation in the wrong place.

// Shapes you will meet:

// - a filter matching nothing because the command failed first

// - a probe reporting an element missing on a page that never rendered

// - a search that silently searched the wrong directory

Complete the release note discipline: write in ___ not mechanisms, and always name the ___ radius of a fix.

// What changed — [tenant] — [date]

// New Gutter cleaning now has its own page.

// Improved Quote requests now include property size.

// Fixed The contact form was dropping the phone number on

// mobile. Requests before today may be missing it.

// ^ the radius, stated

// You should know

// Nothing you need to do.

// The old /gutters URL still works.

// ^ written in , not "added a redirect"

// Leave out: branch names, commits, tickets, file paths, effort.

Name the three properties a change must have to be genuinely self-serviceable.

// Self-serviceable requires ALL THREE

// 1. they can find it without being told each time

// 2. Safe getting it wrong does not break the page

// 3. named the way the OWNER thinks about it

// Fails property 3: operating_schedule_json

// Passes property 3: Business hours

// If a change is in the owner's column and they cannot do it,

// that is a defect in the BUILD — not a support request.

Complete the credential rule and its test.

// A secret must be of reaching the browser.

// Not merely unlikely to.

// A client-exposed variable is compiled into the bundle any

// visitor can read. Not hidden. Not obfuscated. Not protected

// by the page requiring a login.

// THE TEST — not "is this sensitive?" (you will talk yourself

// into an exception) but:

// "If this string were printed on the tenant's ,

// what could someone do with it?"

// Anything at all -> it does not go client-side.

Complete the sovereignty setup. The tenant creates the accounts and keeps the ___ paths, because whoever can ___ an account controls it.

// TENANT SOVEREIGNTY — set up at the START

// 1. The TENANT creates: registrar, hosting, data project.

// Their account, their payment details.

// 2. They invite YOU, with the narrowest role that works.

// 3. You document what you hold and give them the list.

// 4. They keep the paths: registrar login, owner email,

// billing method.

// Why 4 matters: whoever can the account controls it,

// regardless of what any role says.

// Test it: can they remove your access TODAY, without you?

Complete the delivery flow. The step most often skipped is the last one — and merging is not ___.

// The flow every change travels

// 1. Branch from an up-to-date main

// 2. Build locally

// 3. Push, open a pull request

// 4. Preview at its own URL — nothing live has changed

// 5. Review — you, then the tenant if customer-visible

// 6. Merge

// 7. — load the live URL and confirm it is actually there

// Step 7 is not optional. Merging is not ,

// and deploying is not serving. Caches exist.

Complete the gate discipline: the ordering is ___, and a gate you have never seen ___ is not a gate.

// Three stages, in this order

// 1. Structural does it conform? cheapest, runs on all

// 2. Functional does it do the thing? runs on stage-1 passes

// 3. Operational is it safe to release? most expensive, last

// The order is , not ceremony. Cheap checks first means

// most defects are caught before the expensive ones are paid for.

// A gate you have never seen something is a green light

// with an impressive name — worse than nothing, because it

// manufactures confidence downstream.