The quality bars Bruno set, with the moment each came fromSUPPORTING MATERIAL
REFERENCE SHELF
Your guided curriculum
SUPPORTING MATERIALGUIDED READING

The quality bars Bruno set, with the moment each came from

His words are quoted exactly, typos kept, from the file named after each quote (all on the box; dates and times UTC). Where a bar is a rule of ours that came from a cost rather than from his words, it says so. Each bar ends with what it means for a new problem.

1. It feels like an architecture interview, in the interview's order

  • 2026-09-27 10:13-10:16, after round 2 shipped the API under the diagram (~/scratch/heavy-work/r4/COMMON.md): "One thing I thought I made clear. I wanted the api spec to be created first snd then the design. [...] It should be two different panels. One to create the api spec another for thhe diagrams like we have." and "It should feel like an architecture interview."
  • 2026-09-27 call, 18:32-18:52 (docs/backlog/interview-simulator.md): the goal is "as real as possible".
  • 2026-10-04 18:54, the bar for the whole of the latest round (~/scratch/guide-human/COMMON.md): "Remember end of the day this should feel like an architect interview. Me interacting with the interviewer. There is not a one answer be all. Although there are specific solutions for architecture problems so we have to have that in mind. Algorithms and architectural designs should be respected at given cases."

For a new problem: requirements by asking, then the API, then the design, then scale. Nothing the interviewer is meant to reveal is written above the board.

2. No single answer, but the known patterns named

  • 2026-10-04 18:51, after his DELETE failed the takedown simulation (~/scratch/guide-human/COMMON.md): "what deny list. I didnt have that nor thought i needed that. yeah fix it. Although are we forcing the User to a specific answer... no creativity here. or reasoning to explore."
  • 2026-09-27 10:16 (~/scratch/heavy-work/r4/COMMON.md): "Also you let me use an aurora db for the problem. Although yea it works, dynamo db is the obvious winner there and maybe with costs and times it would have shown. You need to be able to always have a way of improvement when simulating looking at the problem and component connected."
  • 2026-10-04 13:27 (~/scratch/guide-bigcos/BRIEF.md): "we strive for hte best and proven architecture."

For a new problem: a test checks what has to happen, so every design that does it passes. Where the industry has a usual answer (a conditional write for a contested name, a deny list for takedowns, a batched counter for live counts), the board names it in the hint and says why, the way an interviewer would bring it up. After every heavy run there is at least one next step with its numbers, even when nothing failed.

3. Taught while doing, never uncovered by failing

  • 2026-10-04 06:35-06:40, after his queue sat unread (~/scratch/guide-explain/BRIEF.md): "If I knew that I need to add the event endpoint I would. why didnt an error or something showed up ... I shouldnt be uncoverijng this."
  • 2026-10-04 06:25-06:28 (same file): "i feel like there should be more explanation of the components and of the choices to make to make it a better design"
  • 2026-10-04 12:55, on where clicks live (~/scratch/guide-bigcos/BRIEF.md): "like you have to know im learning too. what is the optimal way of keeping clicks. [...] i wish i could be taught while doing this, that was the point."

For a new problem: every rule a test or the heavy test enforces is said before a run, where the reader is working (the step in the editor, the gate before the heavy test), with the fix. A term the reader may not know (a deny list, an idempotency key, a hold) is explained where it first appears: what it is, where it lives, why the obvious thing does not do the job. Every part says what it does; every suggested change says what it gains and gives up.

4. A story with people, not a checklist; no status codes

  • 2026-09-27 17:33 (~/scratch/heavy-work/r4/SCENES-CONTRACT.md): "This is turning more of trying to pass tests than learning how to do it ... I rather there be like an IRL simulation of a person trying to create a link, a person trying to read the link. Almost like a behavior test driven simulation ... Right now I feel like im doing a checklist rather than learning ... there is definitely something missing here that lacks magic."
  • 2026-09-27 call, 18:32-18:52 (~/scratch/heavy-work/r4/T-brief.md, commit e3b1606): "I don't wanna see any of that" (raw responses, status codes, red and green rows).
  • 2026-09-27 19:27 (~/scratch/heavy-work/r4/U-brief.md): "I dont wanna know the scenes. I wanna unlock them as I go from easiest to complex. I imagined the simulation be similar to the design one with a pop up and animations."
  • Loved, in his notes of 29 Sep (~/scratch/board-feedback/Design-Board-Notes.pdf, written in the third person): "The new tree API spec is fantastic. The animation is amazing, and seeing step by step what happens is great." and "The text below Leo and Maya describing what's happening at each step is amazing." Nothing may take these away.

For a new problem: each test is a scene with named people, unlocked easiest first in the pop-up, with a title that sets up the situation and a line that says what should happen. A failure is a moment in the story; the tip asks a question before it names the pattern.

5. Human words

  • 2026-10-04 18:51 (~/scratch/guide-human/COMMON.md): "I dont like the wording of the title of the simulations. Its not very human. Its very logical and robotic. It should get me the general idea in very simple terms. Like if you were explaining it to your dad. same as the steps. Your code dos this. your code does that. It doesn't flow as good."
  • His notes of 30 Sep (~/scratch/board-feedback/810653136-Design-Board-Notes-v2.pdf): "Overall it looks good, but something feels missing. The user isn't entirely sure what's going on" and "maybe it needs a better title, or a "scenario" title that sets up the situation".

For a new problem: short sentences, everyday words, people and what happens to them first, machinery second. Read every line aloud; if it sounds like a log line it is wrong. Rewording never changes a fact. (The words helper working now in ~/scratch/j2s-words sets the current register; read its DONE.md once it lands.)

6. The eyes are on the diagram: show the spot, the fix, why, and the re-run

  • 2026-09-27 03:50, after he ran the heavy test himself (~/scratch/heavy-test-round1-spec.md): "Like those numbers should be showing up on the arrows. Because the users eyes are on the diagram, not anywhere else." and "If there are some notes regarding "things that don't make sense here" not only speak about it but take like a small screenshot of that area so the user knows and what you recommend doing it and why with post-simulated number results."

For a new problem: rates ride on the arrows; each problem the run finds is a card with a picture of that spot on the reader's own diagram, the change drawn, and the board's own re-run before and after. No key needed for any of it.

7. Watch it build; real behaviour, at interview depth

  • 2026-09-27 03:35, his first run (~/scratch/heavy-test-v2-spec.md): "Why is it a specific time it all just breaks. I dont feel its being demonstrated well the growth of traffic. The fact traffic is very linear and then jumps hard feels unreal but maybe thats how it is?"
  • 2026-09-28 06:37 (~/scratch/heavy-work/r7/C-common.md): "But they should have the names of the concept. Meaning if sharding for dynamo or aurora have some weird AWS name, dont name it that, name it sharding. And it has to make sense when used in the simulation. [...] we shouldnt overcomplicate it." and "just assume auto scaling to any level. Just as how we should never worry about vertical scaling details."
  • 2026-09-28 07:08 (~/scratch/heavy-work/r7/COMMON.md): "Well auto scaling should follow how auto scaling realistically is. Thats all. But how much it auto scales, always assume to the max if needed."
  • 2026-10-04 06:25-06:38 (~/scratch/url-retouch/BRIEF.md): "Remember this is an interview sure we have to go over details but we cant go so insane in details llike the specifics of vertical scaling. API Spec should be API spec. But system design and architecture are seprate sections."

For a new problem: the High level builds over minutes so the breaks come one by one; what breaks is what a bigger machine cannot fix (a hot key, a row lock, a hard quota, the time scaling takes). Concepts carry their plain names. The API names what the code does, never infrastructure.

8. Cost per part, as pictures

  • 2026-09-27 04:19-04:20 (~/scratch/heavy-work/r2/P-brief.md): "We should also include Pricing Cost avg to the simulation." / "Per component based on the simulation"
  • 2026-10-04 06:25-06:38 (~/scratch/url-retouch/BRIEF.md): "Also there is too much talk regarding money in the results. I think its a positive and it should be more easier to see what spent what. Component wise. maybe with graphics. And then just focus to the point. Graphic wise too, what went wrong and how would you change each problem to a better solution and why."

For a new problem: prices from AWS's Price List with the date read; one tile per part; the price notes behind a summary.

9. Proven architecture, with diagrams and animation

  • 2026-10-04 13:27 (~/scratch/guide-bigcos/BRIEF.md): "I think it would have been helpful for the problem to have an area of how big companies deal with these kind of issues and their architecture for at least this problem ... this is the kind of detail and to the point diagram and animations that i would expect when I go over a problem in guide. we strive for hte best and proven architecture."

For a new problem: a "how big companies do it" section from primary sources, the answer to give in an interview, and at least three diagrams, one animated, each teaching one thing.

10. Less is more before the exercise

  • His notes of 29 Sep (~/scratch/board-feedback/Design-Board-Notes.pdf, item 3): "There is a LOT of text before the user can start the assignment." and "Less is more." The structure he proposed: the problem in one line, a scenario of two or three sentences with the last on its own line, then straight into the interactive problem.
  • Commit d204c86 (2026-09-28): two first-time users on two nights did not find the board, 70% of the way down the page.

For a new problem: # Design ..., the scenario, ## Design it (where the board mounts). The rest of the page follows.

11. Slow enough to follow, and a voice that fits

  • 2026-09-27 20:52 (~/scratch/heavy-work/r4/X-brief.md): "Also the flow of the call is EXTREMELY fast animation. should def be slower to see. Also ... there should be a click to unlock tip on why it might be wrong. shouldnt fully give answer but makes you think about it"
  • His notes of 30 Sep (v2 PDF): "Speed: the animations are too fast. Set them to 0.5x speed by default."
  • 2026-10-04 05:14 (~/scratch/guide-narration/BRIEF.md): "The voice should follow well. She should be saying enough and not enough to fit in the animation and not be delayed or ahead. When something goes wrong, it should maybe say why. again we wanna make sure we re create and save and reuse on the right sections and combinations since elevenlabs is kijnd of expensive."
  • 2026-10-04 08:31 (~/scratch/guide-voice1x/BRIEF.md): "So I suggest making 1x feed the automatic simulation. Also simulation should start after the voice tells the user what is the overall simulation about. So once I click simulation. wait 0.5 seconds, then start the small intro, and once intro ends start simulation."

For a new problem: a narration catalog keyed by situation, never by the reader's names or run numbers, so one clip serves every reader; an introduction per scene that never gives the outcome away; every clip shorter than its step.

12. No key needed, and quick by hand

  • 2026-09-27 16:36 (~/scratch/heavy-work/r4/M-brief.md): "There should be an easy seamless way of doing it. End of the day, the user SHOULDNT need an api-key."

For a new problem: every model feature (Haiku writing the API, Sonnet's report, Say it) is a shortcut beside a by-hand path, never the only way.

13. Production's answer when something breaks

  • 2026-09-27 16:36 (~/scratch/heavy-work/r4/K-brief.md): "if there is a smart solution thats done on prod then it should state it depending on what breaks"

For a new problem: Break it's tips are keyed on part kinds and already general (resilience.js); check they read true for the new problem's parts.

14. An interviewer that does not miss simple questions

  • 2026-09-27 21:14 (~/scratch/heavy-work/r4/K2-brief.md): "My question was very very simple and common. The fact you miss something so simple kinda scares me."

For a new problem: build the interviewer's evaluation set first (150+ questions the way people ask), measure, then write answers until the misses are understood. The URL interviewer went from 61% to 99.6% on 259 questions that way (commit f9fea5f).

15. UI and UX checked, and completed well

  • 2026-09-27 21:39 and 21:43 (~/scratch/heavy-work/r5/COMMON.md): "Dont be lazy! Make sure ui and ux is on spot. I know you have skills and all on it but double check it" and "Make sure all of them get completed and completed well. You should probably install some playwright mcp or skills to check your work. And if its easy to use and looks well."
  • 2026-09-29 16:03 (~/scratch/heavy-work/r9/COMMON.md): "I mean use good ui ux skills and program manager mentality on User experience."

For a new problem: run the design skills (impeccable, emil-design-eng, apple-design, design-taste-frontend) on real pictures, and a stranger's walk before release (see plan.md).

16. Hours, not days

  • 2026-10-04 19:04 (~/scratch/guide-human/playbook/BRIEF.md): "i dont wanna spend days on a single problem perfecting it... i dont mind hours. but not days."

Our own bars, each from a cost (not his words)

  • A check you have not seen go red proves nothing. In every helper brief since the heavy test's first build. It came from a card check that passed on an empty picture because it only asked whether an <svg> existed, and a check that counted the speed buttons instead of reading the arrows' labels (commit c2f5296). Break each new rule once, restore byte-identical by sha256, watch it pass again, and list the breaks.
  • Pictures looked at. Every visible change is judged on a picture rendered and opened. The big-companies helper's brief: most defects in the guide's diagrams were found only by looking (text past a box edge, a line through a word, a first frame that says the opposite of the lesson). Hide .read-progress in element screenshots.
  • His screens. "Bruno is on Mac Chrome" (commit 2a3b9c7): judge the board at 1280, 1440, 1512 and 1728 px wide, and WebKit at 1440 as the nearest thing to Safari. The board does not mount on a phone (the page keeps its reference sketches), so the page and its diagrams are checked at 390x844 too.
  • Numbers come from code or from a source with a date. A number on the page is the run's, or it is sourced (AWS's docs, a primary engineering post) with the date it was read; an estimate says so. A model never supplies a number (Sonnet's sentences that carry a number the run did not give are dropped).
  • Code decides verdicts, never a model. The gate, the simulations and the fix cards are code. Agreed with Bruno on 2026-09-27 for the tests ("He said yes to code running the tests and Haiku only writing the spec at 08:12 UTC", site/designboard/README.md).
  • The writer never sees the test. Haiku gets the reader's words and nothing of the page, so the tests grade the reader and not Haiku (leak tests on six-word windows).
  • Versions are ours. 2026-09-28 (commit 8e673f8): "I just wanted versioning. Versioning could be in github. Not up to the user. Up to us." Readers get the latest board only; versions are board-X.Y tags.