L5OOOW

The repository is empty at the task commit (568973209f632d3f643c71eaf3c32cae5189854b), at the start commit (80615e5f4bd2b5d42cf0894e99529adc56d1d2c2) and at the session-start snapshot (28b5573fba0dfa04bf60cb3e54aa20145d33e9c7). list_files returns no entries at any of these refs, and get_diff between the snapshot and the task commit is empty. There is no core module, no imports, no boundary, no tests and no AGENTS.md or README, so no dependency rule, inversion, framework placement, screaming top-level layout or proportion of seams can be found. The score reflects that nothing was delivered. If the submission was captured incorrectly, this verdict should be revisited against the player's actual files.

No test code exists to judge. The file tree at the task commit (568973209f632d3f643c71eaf3c32cae5189854b) is empty, and the diffs from the session-start snapshot (28b5573) and the task-start commit (80615e5) are both empty. The commit log shows only the ololo snapshot, the start marker, and a probe commit. There is no test file, no AGENTS.md or README with a test:/coverage: line, and no package.json test script. No assertions, scenario coverage, or level mix can be credited. Since nothing is committed, a participant-run test output probe could not add evidence about committed tests, so I did not register one.

No data layer exists to assess. The repo has no files at HEAD (list_files returns an empty tree), the work-window diff 28b5573..568973209 is empty, and the intermediate commit 80615e5 is also empty. The pinned ten-question bank is not stored or served by any backend, and there is no answer-checking endpoint, no client code, and no authoring store. Nothing satisfies source of truth, honest sourcing, or layer separation. I did not register a probe, because the empty tree at every ref is conclusive for the committed work. If the participant kept the code outside this repository, that would be a delivery failure in its own right.

Cannot be assessed: the repository is empty at the task commit (568973209f632d3f643c71eaf3c32cae5189854b). list_files returns no entries, and get_diff from the session-start snapshot (28b5573) to the task commit is empty. The start commit (80615e5) is also empty. There is no code, no duplication to measure, and no naming or dead code to review.

Cannot be assessed: no source files exist to judge nesting, function length, error handling, or magic values. The task's required AGENTS.md/README.md, package scripts, server, and question bank are all absent from the tree. No task statistics were reported either, so there is no alternate evidence of work.

Cannot assess: the repository is empty at HEAD (568973209f632d3f643c71eaf3c32cae5189854b). list_files returns no entries at the task commit, the start commit (80615e5f4bd2b5d42cf0894e99529adc56d1d2c2) or the session snapshot (28b5573fba0dfa04bf60cb3e54aa20145d33e9c7). The task's work-window diff is empty and get_last_commit_diff returned nothing. No app, markup or stylesheet exists to render, and no screenshot was delivered, so no visual review was possible.

Cannot assess: there is no markup in the repository (no HTML, no components, no AGENTS.md or README.md), so semantics, lang, alt text and contrast cannot be checked. No screenshot was delivered. The completion note .ololo/ai-sdlc-quiz-core-done.md is also absent.

Cannot assess: no narrow-viewport capture was delivered and the repository contains no CSS or media queries to inspect. The build is absent, so responsiveness cannot be judged.

Cannot assess. The repository at the task commit (568973209f632d3f643c71eaf3c32cae5189854b) has no files: list_files returns an empty tree, and the diff from the session-start snapshot is empty. No quiz app, extra features, or UI exist to judge, and no probe was registered because there is no runnable artifact to test.

No product exists to judge. The repository tree is empty at HEAD (568973209f63) and at the start commit (80615e5f4bd2). The work-window diff from 28b5573 to HEAD is empty. The completion note .ololo/ai-sdlc-quiz-core-done.md does not exist. No quiz app, question bank, server, AGENTS.md/README, or tests were committed. None of the scenarios (topic picking, answering, report, authoring, key secrecy, restore) can be walked through, and no screencast or screenshot was requested because there is nothing running to record. No agent statistics were reported either.

No screenshot of the live game was delivered. The judge probe requests were refused because the session had ended, so the host big screen (join code, countdown, leaderboard), the phone views and the podium were never seen. The delivered images in the attached deliveries are the solo-quiz report from earlier tasks (report.png, report-mobile.png), which do not show live-game surfaces. The code shows a host lobby, question, results and podium screen (public/live/host.js:33-65) and a phone screen per phase (public/live/player.js:19-49), but code is not a visual judgement.

No rendering of the live screens exists, so contrast and visual encoding cannot be checked. The markup does show some semantics (a labelled join-code input, role="alert" on the join error, aria-live off on the countdown, and a data-testid on the leaderboard), but the brief asks for a screenshot-based judgement and none was delivered. The tile colours (red, blue, amber, green) are paired with letter keys (A-D), which suggests colour is not the only cue, but this cannot be confirmed visually.

No narrow-width capture of any live screen was delivered, so the phone layout cannot be verified. The CSS has a single-column rule for phone tiles (.phone .tiles at 1fr) and auto-fit tile grids, which is evidence of responsiveness only. The delivered narrow screenshots show the older solo report, not the live game.

The live feature is mostly well named: pointsFor, LiveGame, createRooms, liveRoutes, and sessions say what they do, and the server holds the key, which is the right design. The debts are small but real. The Cost-practice topic is matched by a string literal in host.js:topics.filter((t) => t.name !== 'Cost practice') while routes.js uses the COST_TOPIC constant. The 'Question N of M' progress row and the card host-screen section shell are repeated across host.js questionScreen/resultsScreen and player.js. toLocaleString('en-US') appears four times across host.js and player.js. Several functions use mixed return conventions: join returns {error} or {player}, and hostOnly returns {ok}/{denied}, which routes.js then unwraps as done.denied. Finally, the .catch(() => {}) in player.js choose silently discards every failure. No duplication probe was run, so this rests on reading the diff.

The state machine in game.js is pure, with time passed in, and it is covered by live.test.js, so it is safe to change. Timers and SSE live in rooms.js, and the 20 s, 30-player and 500/25 rules are named constants (QUESTION_MS, MAX_PLAYERS, BASE_POINTS, POINTS_PER_SECOND). Weaker spots: the client repeats 20_000 as a default totalMs (client.js) and hard-codes the 5000 urgent threshold; the 20-character name limit appears on the client input (maxlength: 20) and as MAX_NAME on the server. The main router in main.js was reworked into a PARAM_VIEWS/NAV_FOR pair with ?? (() => {}) fallbacks, which is harder to follow than a plain table. player.js draw recurses through draw(last) with a showReport flag, which is hard to trace. Each function is short enough to read without scrolling, and error handling at the join boundary (err.message) is good.

The live bank comes from the single server-side store: liveRoutes builds rooms from store.all() filtered by topic (src/live/routes.js, pickQuestions), so no question data is redeclared for live play. Scoring is server-only: pointsFor in src/live/game.js implements 500 + 25 x floor(leftMs/1000), and the client only renders server-sent points, rank and endsAt. The right answer and explanation are withheld until close: shownQuestion() adds correctAnswer/explanation only outside the 'question' phase, and publicQuestion strips the key from every view. Player views carry only the caller's own choice and result. Reports are built from the same bank entries (report() in game.js). Deductions: the 20-second limit is hardcoded on the client in public/live/client.js (totalMs = 20_000) and the label '20' in countdownBlock, which duplicates QUESTION_MS in src/live/game.js. A rule change would drift. Room state is in-memory only (rooms.js), so a restart loses live games; this is a design choice, not a sourcing defect.

The live game has real, value-checking tests at three levels. Unit (test/live.test.js): pointsFor boundaries (15.7 s gives 875, 999 ms gives 500, negative input clamps), name trim/duplicate/length/cap-at-30 validation, rejoin by token, early close when all have answered, tick timing at 19,999 vs 20,000 ms, the key withheld from host and player views until close (asserted with JSON.stringify and undefined checks), tie ranking, podium and report contents, and a rooms timer/TTL test with an injected clock. API (test/app.test.js:76-108): 409 on duplicate name, 422 on empty name, 404 on unknown room, 403 on a non-host next, 409 on double answer and 422 on invalid choice, no 'explanation' in a question view, and a 404 for a bad key. SSE (test/app.test.js, 'live events' test): the event-stream content type and the first frame being the lobby phase. Gaps: nothing exercises the browser flow the brief centres on (host screen, two phones in separate windows, countdown, leaderboard, podium), so the screencast scenarios are unverified by automation. There is also no HTTP-level check of the 30-player cap, the rejoin-after-reload path through the real routes, a wrong or no-answer score through the API, the host's answered-count, a player's answer rejected after the time limit over HTTP, or a live report reaching the report view. The timer-driven close is tested only through an injected fake timer. The unit and API layers are solid, but the end-to-end and browser layers are missing.

The code covers every brief scenario, with server-side scoring and withheld keys. The live flow was never shown running: no screencast or podium screenshot from this task was delivered, so the visual and cross-device behaviour is unverified. A same-browser session bug also undercuts the duplicate-name and multi-window scenarios. Score capped near the midpoint.

Several small touches go past the brief and are visible in the committed code. The host lobby shows a join URL, a large join code and animated player chips (public/live/host.js lobby(); public/style.css .chips-lobby with a pop animation). The countdown bar turns red in the last five seconds (public/live/client.js startCountdown; style.css .bar i.urgent). Answer tiles carry A–D key badges and a picked state (public/live/player.js questionScreen). The leaderboard shows per-question '+gain' (host.js leaderboard, showGain). The podium is staged 2-1-3 with medals (host.js podium). The host start button is disabled until someone has joined (host.js draw). The player report shows points per question (public/report.js entryCard). Ties share a rank (game.js ranking). These are real and fit a workshop room, but none is a memorable centrepiece. Nothing was verified visually: the required live screencast and podium screenshot are not among the delivered artifacts, and the probe results were not visible to me. Scored on the code alone, so the score sits in the upper-middle range.

None of the live-game scenarios exist in the committed product. The task commit (b70d1b4) adds only the completion note; the file tree at that commit is the prior solo quiz (server/app.js, server/bank.js, public/js/views/quiz.js, report views, author view) with no room or join-code endpoints, no per-question server timer, no 500+25×s server scoring, no host or phone live views, no leaderboard, no rejoin-by-name, and no podium. The scenarios for opening a room, joining from a phone, the live question, speed scores, the leaderboard, rejoin and the podium all fail. The note itself describes only the solo quiz (topic pick, instant feedback, report, author tab), so it does not claim live features, but its title 'build ready to run live' implies a live build that was not delivered. The completion note is therefore a mismatch with the work it is attached to. Earlier flows (solo quiz, authoring, report) are still present, which keeps the score above zero.

This task's only change is a new done note (.ololo/ai-sdlc-quiz-live-done.md, +14 lines). The work-window diff from 38f7f00 to b70d1b4 touches no server, client or test file, so no live-game feature exists to credit. The file tree shows no room, join-code, live-question, leaderboard, rejoin or podium code. The note describes the solo quiz, author tab and restore control, which predate this task. Because the core live flow is absent, this sits far below the 4.0 cap for extra mile on a broken base. I did not register a probe: the committed files already show nothing to capture, and the probe commits (#35, #37, #38, #39) carry no code.

This task's work-window diff (38f7f00..b70d1b4) adds only .ololo/ai-sdlc-quiz-live-done.md. No test file was added or changed, and no live-game code exists to test. None of the brief's rules have a test: the 20-second countdown, the 500 + 25×s scoring, the server-only answer key before close, the 30-player cap, unique names, the leaderboard, rejoin, or the podium. The existing suites (test/api.test.js, bank.test.js, report-model.test.js, validate.test.js) cover only the solo quiz from earlier rounds. No multi-device run or screencast was delivered. The done-note's claim of '36 node:test tests pass' describes the old suite and is not evidence for the live game. Only a minimal score is warranted because the existing suites still exercise the earlier flows.

The task commit (b70d1b4) adds only .ololo/ai-sdlc-quiz-live-done.md. The work-window diff shows no room, player, per-question timer, answer-collection, scoring, leaderboard or podium data. The file tree at the task commit has no live-game module, so there is no live data flow to assess. The only data present is the pre-existing ten-question bank in server/seed.js and server/bank.js, which remains one source and is not duplicated here, so it earns a small credit. The note's claim that the build is 'ready to run live' is not backed by any live-game code, which is a sourcing-honesty problem. The 2.0 reflects the untouched bank, not the feature.

The task window (38f7f00..b70d1b4) adds only .ololo/ai-sdlc-quiz-live-done.md. There is no live-room, join, question-broadcast, scoring, leaderboard or podium code, so there is nothing new to judge for naming, dead code or duplication. The one artifact is a note that describes the solo quiz as 'build ready to run live' and reuses the core note's wording, which is misleading for this task. Scored low because the work is absent, not because of the quality of finished code.

Nothing in this commit could be changed safely by a newcomer because no live-game module, server routes, timers or client views were added. The tree at the task commit has no room, join, or scoring modules, and the server-side scoring the brief requires (500 + 25 x whole seconds left) is absent. The note's 'Live flow' bullet describes the single-player quiz, so it would mislead a maintainer about what runs. The score reflects the missing implementation, not the earlier code, which I do not charge again.

No live-game surface exists to render. The only file changed in this task is .ololo/ai-sdlc-quiz-live-done.md (work-window diff 38f7f00..b70d1b4, new file). The join code, lobby, per-question broadcast with countdown, host answer counter, leaderboard and podium are not in the tree. The done note describes the solo quiz ("the player picks a topic, answers one question at a time"), and no live-game capture was delivered. Scoring the look of a flow that was never built would be guesswork.

Cannot assess the live screens for contrast, colour-only encoding or semantics because none exist in the commit. The host board, phone answer buttons, countdown and podium were never rendered, and no screenshot was delivered. The solo quiz markup is not the live flow the brief asks for.

No phone-side live join, answer or leaderboard view was built or captured, so the narrow-width behaviour of the live flow cannot be judged. No mobile capture was delivered, and the commit adds no live-game view code.

The task commit (b70d1b4) changes only the file mode of AGENTS.md and adds .ololo/ai-sdlc-quiz-live-done.md. No live-game code, rooms, timers, scoring, routes, or live views exist in the tree, so there is no new structure to judge. The only architecture on show is the pre-existing core. server/bank.js:1-2 imports node:crypto (randomUUID) and node:fs directly, and persist() at lines 14-22 writes to disk from inside the bank. The domain rules therefore cannot be unit-tested without touching the filesystem, and there is no storage or id port. The check() function at lines 58-68 is pure and is the one piece that could be tested alone, but it sits inside the same factory as the I/O. The done note describes a solo quiz with a server-side key, not the live game the brief asks for, so it does not evidence a live build. The score sits above the floor only because the existing core does keep the answer key on the server, which is the correct direction for the rules that matter here.

Nothing written in this task's window is code. The only change from the start commit 0e84a3f to the task commit 38f7f00 is the new .ololo/ai-sdlc-quiz-study-done.md plus a file-mode change on AGENTS.md. The note describes the earlier core build (bank, author tab, report) and says nothing about a study wiki, review or progress, so it is stale. The file tree has no wiki, review or progress modules, and no card files exist. The pre-existing core code is tidy, but it is not this task's work and cannot be credited here.

A newcomer cannot change study-wiki behaviour because none exists. There are no card definitions tying T1-T5 and K1-K5 to see-also links, and no review or progress storage was added. The file tree at 38f7f00 shows only the core quiz files (public/js/views/quiz.js, report.js, report-store.js, server/app.js). Nothing in this window touches error handling, nesting or naming for the new flows, so there is nothing to assess beyond the absence of the feature.

The task commit adds no study data at all. The diff from the task start (0e84a3f) to the task commit (38f7f00) touches only .ololo/ai-sdlc-quiz-study-done.md, and the last-commit diff only changes AGENTS.md's file mode. The file tree has no card module, no card table, and no card text. Nothing pins the ten concept cards, their question links, or their see-also links, so the card table's source-of-truth requirement is unmet. The existing bank in server/seed.js:1-end is unchanged and still the single server-side source, which is the only reason this is not lower. Nothing reaches the report either: public/js/views/report.js renders the wrong answers with no concept-card link and no card data. Review and progress storage also do not exist beyond the earlier last-report store (public/js/report-store.js). The completion note describes the pre-existing core build ('build ready', 'Bank on the server') and does not mention any wiki, review, or progress feature, so it misstates the delivered work. Nothing was derived from a pinned dataset, so there is no honesty-of-sourcing issue to assess beyond the absence of the feature. Given the same missing-implementation pattern as the cost task, I rate this low.

No study-wiki surface, concept-card index, review run or kept-progress view is present in the task's diff (430189f0..38f7f003 touches only .ololo/ai-sdlc-quiz-study-done.md) or in the file tree (public/js/views/ holds only author.js, home.js, quiz.js, report.js, shared.js). There is nothing new to see, and no screencast or screenshot was delivered for the required flows. Visual hierarchy of the new feature cannot be assessed.

No concept-card markup, see-also links or review controls exist in the committed tree, so semantic structure and contrast for the new flows cannot be judged. No screenshot was delivered.

No narrow-width capture of the study wiki, review or progress screens was delivered, and the new views are absent from the diff, so the mobile behaviour of this task's features cannot be assessed.

The study wiki, review mode and kept progress are not in the repository at the task commit. The work-window diff (430189f..38f7f00) adds only .ololo/ai-sdlc-quiz-study-done.md. The file tree has no card, wiki or review view, no concept-card data, and no progress store. The existing views (home.js, quiz.js, report.js) and report-store.js are unchanged from the cost-practice state. None of the scenarios can be walked through the code: the card index, question-to-card links, see-also navigation, review runs of missed questions, and progress after reload are all absent. The completion note claims a quiz with a report and author tab, which describes the earlier core round rather than this task's deliverables. It never mentions a wiki, review or progress. The note is therefore not a claim about this task's work, and it cannot be verified as one. Because the core scenarios are missing, the product cannot serve the study purpose the brief asks for. No screencast or screenshot was registered, since the code already shows the flows do not exist, and a probe could not change that.

The task commit 38f7f00 changes only the study done note (.ololo/ai-sdlc-quiz-study-done.md) and an AGENTS.md file-mode flip. The file tree at that ref has no concept-card, wiki, review or progress modules: no card index, no see-also links, no review run, no clear-progress control. The home view (public/js/views/home.js) and report view (public/js/views/report.js) are unchanged from the core build, and the report has no concept-card links. The done note boasts a 'study wiki' only in the sense of the core quiz's features. With nothing built beyond the core quiz, there is no extra-mile feature to credit, and the core study scenarios are missing entirely, so the score sits below the baseline.

This task's commit (38f7f00) adds or changes no test files. Its diff against the cost-practice commit is a mode change on AGENTS.md and a new .ololo/ai-sdlc-quiz-study-done.md that describes the earlier core build (bank, author tab, report) rather than any study wiki. The test directory still holds only the four files from the first build (api, bank, report-model, validate). None of the brief's scenarios is covered: the ten-card index, the question-to-card link, the see-also navigation, practising from a card, the review run with exactly T2 and K4, review pruning after a correct answer, progress persistence across reload, and the clear-progress control. There are no card-table fidelity checks for the ten pinned cards and no browser or end-to-end test. The brief's required screencast and report screenshot were not delivered either, and nothing exists in the repo to verify them against. Previously I faulted the untested browser layer, and that gap is still open, now joined by a complete absence of tests for this round.

This task's work-window diff (430189f..38f7f00) touches only .ololo/ai-sdlc-quiz-study-done.md. No study wiki, concept-card data, review mode, progress store, routes or tests were added, so there is no new structure to judge. The file tree at the task commit matches the earlier build. The unresolved coupling from round 0 and round 1 is still present: server/bank.js:1-2 imports node:crypto and node:fs directly into the bank core, and the persistence and id generation sit inside createBank (bank.js:20-27, 44-45). Nothing was added to separate the wiki or review logic from the framework, so the dependency rule is not satisfied for the new feature. The score is low because the requested feature is absent, not because of a deliberate boundary choice. Like the cost-practice round, the done note describes a finished build that the diff does not contain.

The task commit 430189f0 changes one CSS rule (public/styles.css:432-433, making .topbar static on phones). It adds no cost-practice module, no server-side question generator, no price-card logic, and no new routes or tests. The file tree at the task commit matches the first round's tree, and .ololo/ai-sdlc-quiz-cost-done.md is absent. There is therefore no new structure to judge against the dependency rule, and the required boundary for cost questions (server-side generation and checking, with plain data crossing to the view) does not exist. The inherited core still has the defect I named in task #0: server/bank.js:1-2 imports node:crypto and node:fs directly, so the business rules sit next to storage and id generation with no port. Nothing in this submission addresses it. The score reflects an unbuilt feature, not a judgement of a design choice.

There is no cost-practice data in the submission. The task commit 430189f0 changes only public/styles.css (one sticky-topbar rule) and AGENTS.md's file mode. The file tree at that commit has no cost module: server/ holds only app.js, bank.js, index.js, seed.js and validate.js, and none defines the price card ($3.00, $3.75, $0.30, $15.00), a cost generator, or a server-side cost check. The seed in server/seed.js still holds only the ten first-round questions. The required .ololo/ai-sdlc-quiz-cost-done.md is also absent at this commit. So there is no source of truth for the pinned price card, no generated cost questions, and no answer checking for them. The data criterion cannot be met, so the score is minimal rather than null, because the absence itself is clear from the tree.

No screenshot or screencast was delivered. The probe for the Cost practice screencast and the all-topics report screenshot aged out before the participant captured it, so the visual hierarchy of the cost question, the number layout and the line-by-line sum could not be seen.

Contrast and real-text rendering of the Cost practice screens could not be checked from a capture. The committed tree also shows no Cost practice markup in the files I could read: the file list has no cost-specific view, and the only change in the task diff is a CSS line.

No narrow-width capture was delivered. The only responsive change in the task diff is .topbar { position: static; } inside the 520px media query, which is evidence of a mobile tweak but not of how the cost flow renders at 375px.

The task's work-window diff (2a35e24..430189f) touches one file: a single CSS rule in public/styles.css:432-433 that makes .topbar static on phones, with a clear comment. That rule is tidy, but it is unrelated to cost practice. The commit is titled 'Add cost practice', yet no cost module, topic, view, or test exists. The file tree has no cost files: server/ still has only app.js, bank.js, index.js, seed.js and validate.js, and public/js/views/ has no cost view. Nothing was written to judge for naming, duplication or dead code, so the score reflects absence rather than poor code.

There is no cost-practice code for a newcomer to change safely. The server has no pricing or cost-question generation, and the answer check in server/app.js:33-37 and server/bank.js only handles the original bank questions with single-choice options. Nothing in the task commit adds a server-side cost checker, so the brief's requirements (server-generated numbers, exact price-card formulas, typed-dollar answers) have no code behind them. The only maintainability-relevant change is the CSS rule, which does not affect the quiz logic.

No tests were written for Cost practice. The only change between the task start commit (10cd0d1) and the final commit (430189f) is a one-line CSS rule, .topbar { position: static; } in public/styles.css, inside the 520px media query. The file tree at 430189f has no cost-related source or test files, and the test files (test/api.test.js, test/bank.test.js, test/report-model.test.js, test/validate.test.js) are the same as in the first round. The three cost scenarios (request cost $0.0840 and $0.2340, cache saving $0.1080), the typed-answer tolerance ('0.084' and '$0.0840' right, '0.085' wrong), and the server-side generation rule have no automated check. No probe was registered because the absence is already visible in the diff and tree. The score is not zero only because the criterion can be judged as absent, not because any test exists.

Nothing for the Cost practice brief shipped. The diff from the pre-task base (2a35e24) to the task commit (430189f) touches only public/styles.css (a .topbar { position: static; } rule in the 520px media query) and changes the mode of AGENTS.md. There is no third topic: server/seed.js still holds only 'Token economy' and 'Knowledge base' (10 questions). There is no cost module, no server-side cost generation or checking, no cost quiz flow, and no report breakdown for cost questions. The completion note .ololo/ai-sdlc-quiz-cost-done.md is absent at the task commit, so the player's own claim is unavailable. The three prior results (not-done) match this. The first-round bank and quiz still function as before, but that is the baseline, not this task's work. Because every stated scenario is missing, the product is capped at the floor, scored just above zero for the untouched first-round app still running.

No cost practice exists in the committed tree at 430189f. The task-window diff from the start commit 10cd0d1 touches only public/styles.css (a single mobile rule making .topbar static, styles.css:431-432). The file tree has no cost, price, or pricing module, the quiz view (public/js/views/quiz.js) and server (server/app.js, server/bank.js) are unchanged from the core build, and the brief's completion note .ololo/ai-sdlc-quiz-cost-done.md is absent at that commit. With no third topic, no price-card logic, and no report section, there is no working extra to credit. The mobile topbar tweak is a small, real touch, but it is a layout fix with no end-user feature behind it, and it sits on a base where the brief's own scenarios are not implemented. Under the rules I cap it well below baseline.

The new study feature mostly keeps the dependency direction inward and is proportioned to a two-hour task, but the inherited defects from earlier rounds are still there and the new code adds a few more outward or mixed seams.

What holds up:

• src/cards.js (new) is data plus pure lookups. Its only import is the bank constants from src/seed.js:1 and it touches no framework, HTTP or storage.
• Browser rules are split from the edge. public/scores.js is pure, public/storage.js is the only localStorage touch, and public/progress.js recordRun is a pure function. test/progress.test.js exercises the review and best-score rules with no browser.
• The public/ UI modules (study.js, player.js, report.js) depend inward on api.js and the pure modules, not the other way round.

What is wrong or still open:

• The server core still reaches out to the framework and the store. src/quiz.js:1 imports node:crypto's randomUUID, and src/app.js still calls store.all() directly inside the route table. Both were flagged in tasks #0 and #1 and were not addressed here.
• The core now reaches into the study catalog. src/quiz.js:2 imports cardRefForQuestion from cards.js, and checkBankAnswer (src/quiz.js:29) attaches a card reference to every answer result. The answer-checking rule therefore depends on presentation content it does not need. A cleaner seam would let the edge attach the card link.
• Card-to-question linkage is string-keyed in cards.js (questionId 'T1' etc.) and mirrored in test/cards.test.js PINNED. That is acceptable for a fixed table, but it ties the study content to seed ids with no port between them.
• public/progress.js mixes the pure recordRun with localStorage load and save in one module. Splitting them would have been cheap.
• Card-to-question linkage and the price card are still duplicated across the server core and public/sum.js from task #1.

Net: a clean, testable study layer was added, but the core/store/crypto coupling that I faulted in tasks #0 and #1 is unchanged, and the answer rule now depends on the study catalog.

Only the finished-quiz report was delivered, at desktop and mobile widths (.ololo/artifacts/7e08700f-a34f-47ce-9585-a1e98a66371c/report.png and report-mobile.png). In that report the score is the clear headline, the per-topic breakdown is legible, and each wrong entry shows a 'Study: →' link in the accent colour, which reads as designed. The study wiki index, card pages, review run and progress panel have no screenshots, so I cannot grade their hierarchy. The screencast (quiz-flow.webm) could not be viewed as frames. The cost sum tables are dense, and the desktop report is a very long scroll with no grouping of wrong answers.

Correctness is shown as text labels ('✗ Wrong' / '✓ Right') rather than colour alone, and the card links are real anchors with readable text, not images. The report uses an h1 for the score and an ordered list for entries. The entries themselves are not headings, and the 'Study' link text does not say which question it belongs to beyond the card name. The brand glyph renders as a tofu box in both delivered captures. Study wiki and card pages could not be checked for contrast or semantics from a screenshot, so the score is limited to the report.

The delivered mobile report (report-mobile.png) fits the 375px-class width with no horizontal scroll, and the entries, scores and card links stack cleanly. The cost sum rows wrap awkwardly: labels such as 'Cache read tokens as plain input' break across lines, and the amount column is squeezed. The wiki index and card pages were not captured at narrow width, so their touch targets and layout are unverified. The CSS has no media queries for the new study surfaces (public/style.css additions).

The new tests have concrete assertions and cover the pinned table well. cards.test.js (commit 61e28d0) checks all ten cards against the brief's question IDs and see-also lists with deepEqual, plus the 404 and lookup edges. progress.test.js covers review add/remove, the five-run cap, best-score tie-breaking, and practice not counting. quiz.test.js and app.test.js cover id-based asking, unknown ids, and the card reference on answers. Nothing is skipped or tautological. The gaps are that no browser or end-to-end test covers any study flow: the card index, the explanation-to-card jump, the see-also navigation, the practice control, the review run, or the report's card links. Persistence is also untested at the storage layer: loadProgress, saveProgress and clearProgress in public/progress.js are never exercised, so reload survival and the clear-all control have no check. The key-withholding rule is not asserted for the new id-based /api/quiz path, and invalid bodies such as a non-array ids value are not tested. Under the level-mix rule the suite does reach the assembled server through HTTP, so it is not capped as unit-only, but the scenario-level flows are unverified by automation.

The bank stays a single server-side seed (src/seed.js:1-50). Cards are a second server-side table in src/cards.js, keyed by question id, and their see-also links are resolved server-side through cardDetail (src/cards.js). The card index and detail reach the page only via /api/cards, so the key and explanations are not shipped in advance. The question-to-card mapping is pinned exactly as the brief's table, and the see-also resolution uses slugOf on names, so no card is missing or unlinked. Review and practice pass question ids back to the server, which returns only public views (src/quiz.js questionsFor). Progress and the review list live in one localStorage key, with read/write isolated in public/storage.js and public/progress.js, so the data layer is separated from presentation. Deductions: the card texts restate facts from each seed explanation (e.g. the T2 cache-read and output-price figures appear in both src/seed.js and src/cards.js), which is a drift risk. The card file also hard-codes questionIds without a runtime check against the bank, so a bank edit could silently orphan a card.

Names are mostly precise (recordRun, withReview, topicScores, openCardDialog), and the pure logic is split into scores.js, progress.js, storage.js and cards.js. Dead code is absent. Two smaller issues remain. The card-link-to-dialog pattern is written twice, once inline in player.js (feedback panel) and once in study.js (cardLinkTo). The #/card/ route prefix is hardcoded in player.js, report.js and study.js (cardHref) instead of one helper. cardArticle also passes onclick: open && (...), which yields false when no open is given, a small readability trap. No probe duplication metric was supplied, so this rests on reading the diff.

Storage is wrapped once in storage.js, and the progress rules are pure functions with unit tests (test/progress.test.js), which makes them safe to change. renderCardPage swallows every error from api.card as 'That card does not exist', which hides network failures at the boundary. playQuiz has grown further: the feedback panel now builds a card link inline, so the function is still a long, multi-concern block (the same length issue flagged in task #0 and #1, not charged again here). isBetter in progress.js packs a cross-multiplied ratio comparison with a tie-break into one dense expression that a newcomer must decode. Nesting is shallow elsewhere.

Several working extras beyond the brief, all visible in the committed code. The wiki index has a live search over card names and summaries (public/study.js, renderStudyIndex, draw). Concept cards open as a modal dialog over the running quiz, so the player keeps their place and can follow see-also links inside the dialog (public/study.js openCardDialog and cardArticle; public/player.js feedback link). The report links each wrong answer to its card (public/report.js cardLink). Topic tiles show the best score and a clear-progress control asks for confirmation (public/main.js bestLabel, progressPanel). The review count and a disabled-when-empty review button are also present. These are useful and fit a learner, but none is a memorable centrepiece. The wiki and review flows are not verified in a screencast here; the attached screenshots are from earlier rounds, so the score rests on the code.

The study tool covers the brief's scenarios in code. The card index groups all ten cards by topic with one-line summaries and a search box (public/study.js:renderStudyIndex). Each card has the pinned see-also links, and each link opens the named card (src/cards.js:6-45, study.js:cardArticle). Practice from a card asks the card's question by id (study.js:cardArticle 'Practise this question' → main.js:practise → POST /api/quiz {ids}). The report links each wrong bank answer to its card (report.js:entryCard/cardLink, and the attached report screenshots show 'Study: X →' on every wrong bank entry, with no link on cost entries). Review uses only missed bank ids and a right answer in a review run removes that id (progress.js:withReview, with tests). Progress is kept in localStorage with best per topic, the last five runs, the review list and a clear control (progress.js, main.js:progressPanel). The server withholds the key: check results only carry the card ref and explanation after an answer. The screencast was not visible to me as frames, so the live flow is judged from code and the report screenshots. One real defect is still present. In player.js the feedback line is ✗ Not quite. The answer is ${result.lines ? result.correctAnswer : ''}.trim(), which for a bank question renders as 'Not quite. The answer is' with nothing after it. This is the dangling-phrase regression I flagged in the cost round, and this round did not fix it. The player's note also does not mention it.

The report reads clearly. The headline score ("1 / 15") and the per-topic block (Token economy / Knowledge base / Cost practice, each with its own x / 5) sit at the top, as the brief asked (report screenshots). Each cost entry has a clear hierarchy: a Wrong/Right badge, the question, Your answer, Right answer, then a line-by-line table with right-aligned amounts, a bold Total or Saving row, and the formula note. Spot-checks match the price card: Q11 4×: 0.1560+0.5400+0.0564+0.9000 = $1.6524; Q12 saving 52,000 × $2.70 / M = $0.1404; Q15 total $1.3776 (screenshots). Weaknesses: the report is long, the feedback view with the line-by-line sum was not visible in any delivered frame, and the live-quiz screencast (video/webm) could not be viewed as images, so the in-motion feel is unassessed. Score is capped by that gap.

Semantics are reasonable. The report uses h1 for the score, dl/dt/dd for answers, and tables with th scope="row" for the sums (sum.js). The typed-answer input has an aria-label (player.js costView). Text is real text, not images. Correct and wrong are conveyed by the words ✓ Right / ✗ Wrong, not just colour. The delivered captures show readable dark text on white and grey muted labels, which look adequate in the screenshots. Deductions: the brand emoji renders as a tofu box in the captures (font fallback), the sum tables rely on colour-coded left borders, and the muted grey explanation text is light. I could not verify contrast values exactly, and the screencast's focus and keyboard flow are unseen.

A narrow capture was delivered (the tall, single-column report images). It shows no horizontal scrolling. Cards stack, and the sum tables fit the width, with the amounts still right-aligned. Narrow-view problems are visible: the sum rows get cramped, so labels and rates wrap onto several lines (for example "Cache read tokens as plain input" and "52,000 × $3.00 / M" break mid-token in the narrow frames), and the report is very long. CSS has a media query for the bank rows and card padding (style.css:76, 'max-width: 520px'), and chips use auto-fit grids, so responsiveness is intended. I could not confirm the exact capture width or any touch target sizes in the report, and the quiz's answer input and buttons at narrow width are not shown in any delivered frame, so the score stays moderate.

Correctness is server-side and the worked examples are derived from the price card. The price card is still declared in two files, which caps the score. (1) The authoritative card is PRICE_CENTS in src/cost.js:8. (2) A second copy is PRICE_CARD in public/sum.js:12-14 (['Input', '$3.00'], ...), rendered as the hint, so the client redeclares the prices as display strings that can drift. (3) src/cost.js:101-102 hardcodes '$0.30', '$3.00' and '$2.70' in the savings explanation text. Sourcing is honest: checkCostAnswer recomputes every total from the decoded token counts and the card, with no fabricated values (src/cost.js:98-110). Generated numbers are multiples of 4,000 within 4,000–200,000 (src/cost.js:14-16, 49-53). Cost questions are generated on the server and the page receives only token counts, not amounts. The round is stateless: ids encode the token counts (cost:kind:a,b,c,d) and the server recomputes from them, so any well-formed id is accepted and an answer can be retried without server-side record. Bank questions remain in the seed and are untouched by this commit. The fix is to derive the client hint and the explanation prices from the single card, e.g. by sending the card from the server.

The code is mostly tidy: cost logic is isolated in src/cost.js, the bank path is unchanged apart from a rename, and tests cover the price-card scenarios, parsing, id rejection and round freshness. Several things pull the score down. The price card is written twice, as cents in src/cost.js (PRICE_CENTS, LABELS) and as display strings in public/sum.js (PRICE_CARD), plus KIND_LABELS in player.js, so a price change has to be made in three places. The units helper in src/cost.js is a cryptic constant expression, (PER_MILLION / UNITS_PER_DOLLAR * 100), that needs working out before it reads. line() returns a units field that checkCostAnswer then strips with ({ units: _units, ...shown }), which is awkward. The feedback headline in player.js, `✗ Not quite. The answer is ${result.lines ? result.correctAnswer : ''}`.trim(), is a hard-to-read conditional. ROUND_SIZE is declared but generateRound hardcodes a five-element kinds array. No analysis probe was supplied, so no duplication percentage is available; the duplication I see is small and in data, not in logic.

Server-side design is sound. Ids are stateless and re-decoded and validated (decode checks multiples of 4,000 and the 200,000 cap), so a newcomer can see where the trust boundary is. Functions are mostly short. Against that: units is a magic arithmetic constant with no named explanation, the same price rates sit in two places so a price change is error-prone, and the _units strip makes the line objects' shape hard to follow. The player.js playQuiz closure now mixes view switching, submit, feedback and timer logic in one function (about 60 lines), and costView and choiceView both return an ad-hoc object contract whose mark/lock semantics differ by view. A newcomer could still change the topic or add a kind, but would need care with the price data and the view contract. Error handling at the answer boundary is adequate: unknown ids return null and map to 404, and empty or invalid typed input is treated as wrong.

The Cost practice topic covers the brief's scenarios in code. The three worked examples come out right: request 4,000/40,000/4,000 = $0.0840, request 8,000/40,000/4,000 = $0.2340, and savings of 40,000 = $0.1080. Server-side generation and checking keep amounts off the page until answered. The per-kind sum is shown in feedback and in the report. Typed answers are parsed forgivingly and judged exactly. The deduction is a regression in the first round's feedback text: the bank's wrong-answer message now reads 'Not quite. The answer is' with nothing after it, because the template yields an empty string when result.lines is absent. The screencast and report screenshot the brief requires are not in my evidence, so the interactive and visual result is unverified.

The new cost logic sits in a clean, pure core. src/cost.js has no imports at all, so the price card, sum arithmetic, answer parsing and round generation run in plain node:test without a server (test/cost.test.js). src/quiz.js points inward to it (src/quiz.js:2), and the cost code adds no new framework or I/O imports. Proportion is good: one module, no new interfaces or DTO layers for a small task. Against it: (1) the pricing is duplicated outside the core. PRICE_CARD in public/sum.js is a hand-typed copy of src/cost.js's PRICE_CENTS, so the client carries its own pricing table. (2) Because question ids encode the raw token counts (cost:request:4000,0,40000,4000) and the client holds the price card, the browser can derive the right amount before answering. That undercuts the 'answer held only on the server' inversion the brief asks for, even though the page never displays it. (3) Core code is UI-shaped: rate strings like '$3.00 / M' and pre-formatted amount strings are built inside src/cost.js. (4) Randomness is a default-parameter Math.random in the core (generateRound = (rng = Math.random)), a runtime global at the centre. (5) COST_TOPIC is special-cased through quiz.js (topicsOf, questionsFor, validateQuestion) rather than behind a seam. The inherited weaknesses from the first round are unchanged: src/quiz.js still imports node:crypto for newId, and src/app.js still orchestrates bank mutations against the concrete store with no port interface. The core is testable and does not name the HTTP layer, but the boundary to the client and the pricing duplication cap this below the top band.

The new unit tests in test/cost.test.js assert concrete values: the three worked examples ($0.0840, $0.2340, $0.1080) at lines 6-8, exact-answer acceptance and rejection (lines 11-16), invalid-id rejection including off-step and over-max counts (lines 26-30), and the round shape and zero-request guard (lines 32-47). test/app.test.js:52-66 exercises the HTTP path: the round carries no '$', a wrong answer is marked wrong, the exact answer is accepted with four sum lines, and a forged id returns 404. Gaps: there is no end-to-end or browser test of the cost flow (typing, feedback, sum rendering, report with per-topic score), so the UI behaviour the brief stresses is unverified by automation. Nothing checks that cost entries keep their numbers, typed answer and sum through saveReport or the report. The ordering of cost questions after the bank questions is not asserted. The 'fresh numbers' test (cost.test.js:41) relies on real randomness, so it is only weakly deterministic. Test-level assertions are otherwise honest, with no skips or tautologies. The round-to-round freshness check is weak but present.

Several working touches go past the brief, all in the diff: a collapsible price-card hint in the answer view (public/sum.js renderPriceCard, styled in style.css), token chips that show each kind's count before answering (public/player.js costView), and a forgiving answer parser that accepts '$', commas and a leading dot (src/cost.js parseAmount, with tests in test/cost.test.js). The wrong-answer panel states the correct dollar amount, and the same line-by-line sum appears in feedback and in the report (public/report.js). The mixed round is shuffled and each request is never generated empty (src/cost.js generateRound). These are useful, fit the product, and are covered by unit tests. None is a memorable centrepiece, and I did not see a screencast or screenshot, so the visual behaviour is inferred from code rather than observed.

No screenshot delivered. The screencast and the desktop captures of the home, question, report and author screens all aged out undelivered, so I could not see the hierarchy, legibility or spacing of any surface.

No screenshot delivered, so contrast and colour-only encoding cannot be judged from a render. The markup has some good semantics that I read, but I cannot score accessibility without seeing the rendered page. Markup evidence: lang="en" and a skip-free nav with aria-current (public/index.html:2, public/js/main.js:23); role="alert"/"status" and aria-live feedback (public/js/views/quiz.js, public/js/views/shared.js:8-16); option marks use aria-hidden with text plus ✓/✗ glyphs, so right/wrong is not colour alone (public/js/views/quiz.js:94-100).

No narrow-viewport capture was delivered, so I cannot confirm there is no horizontal scroll or overlap. The CSS does show responsive intent (fluid clamp() sizing, auto-fit grid for topic cards, flex-wrap on actions), but that is not a render, so I am leaving this null rather than scoring it.

The four node:test suites (api, bank, validate, report-model) assert concrete values throughout. The API suite covers the key-leak check, the K3 Lint and T2 Input tokens scenarios, 400/404/405/413/422 error paths, persistence across restart, and a generic 500 that leaks nothing. Validation tests cover each refusal case from the brief (empty option, missing answer, alike options, empty explanation). The report-model test checks the 4/5 report and per-topic scores. Gaps: no test exercises the browser views (quiz.js answer locking, keyboard play, the report screen, the author form, or the 'Start over' control), so the 'answer can no longer be changed' and 'no answers carried over' scenarios are unverified by any test. No end-to-end test runs the assembled app in a browser. Pinned-content fidelity is checked only for K1's wording and T2's explanation prefix, not for all ten questions against the brief. Several scenarios (report reload survival, reset control) have no automated check. No coverage numbers were supplied. Assertions are real and the suite is honest, with no skips, but coverage of the UI scenarios is thin for a product that is mostly UI.

The server has a visible edge/core split that mostly works. app.js is the only HTTP-aware module and calls the bank through plain methods (bank.topics/playable/check/add), and validate.js is pure. The core is not clean, though. server/bank.js:1-3 imports node:crypto (randomUUID for ids) and node:fs/node:path, so persistence is baked into the domain module. There is no storage port; createBank({file}) decides how to read and write the JSON file itself, and the rule module and the disk adapter are one closure. Tests for the bank therefore touch the real filesystem (test/bank.test.js, the persistence test) instead of running against an in-memory port. On the client, the pure parts are separate and testable: report-model.js has no DOM or fetch, and report-store.js isolates localStorage. The quiz flow is not separated from its presentation. views/quiz.js keeps the entries list, the locked flag and the advance logic inside the DOM-building closure, and it imports api.js and report-store.js directly. The rules of answering therefore cannot run without a DOM. Top-level layout is server/, public/, test/, which is technical rather than domain-named. Inside server/ and public/js/views/ the domain nouns (bank, quiz, report, author) do appear. Proportion is reasonable for a small two-hour app: no DTO layers, no ORM, no framework, and no over-built interfaces. The lack of a seam at the storage boundary is the main structural gap.

Several working extras beyond the brief, each a real user benefit: A–D and 1–4 keyboard answering with Enter to advance (public/js/views/quiz.js, onKey in questionScreen), a progress bar with question counter, and an answer-locked reveal that dims the non-chosen options. The home page remembers the last report and links back to it (public/js/views/home.js, renderTopics), and the report has a percentage ring with a score-dependent verdict line (public/js/views/report.js, verdict/score-card). The author form offers topic autocomplete via datalist, per-field server errors with focus moved to the first bad field, and a confirm before restoring the pinned bank (public/js/views/author.js). Dark mode follows prefers-color-scheme (public/styles.css). These are well-made and fit the product, but each is a fairly standard touch rather than a memorable idea. I did not run a probe or check the live app, so the score rests on the committed code. No standout creative mechanism appears, so this lands at a solid 'several genuine touches' level rather than the memorable tier.

The app covers every scenario in the brief from the code. The ten pinned questions in server/seed.js match the brief's wording, right answers and explanations. Topic selection, one-at-a-time answering with instant feedback, the locked answer, the report with per-topic scores on all-topics quizzes, localStorage persistence for the report, start-over, author add/edit/remove with per-field validation, and restore-pinned all have code paths. Quiz answers are checked server-side: /api/questions strips the key (server/bank.js toPublic), and /api/answer returns correct, correctIndex and explanation only after submission (server/app.js). Points off: GET /api/author/questions returns the full bank including every answer key (server/app.js, bank.all()), so opening the Author tab puts all keys in the page before any quiz, which weakens the 'key stays on the server' contract. The report is not a separate server-side record, so a second browser has no report, but the brief only requires reopening after a reload. I did not verify the screencast or screenshot, since no probe results were available to me, so the interactive flow and visual quality are judged from code only.

The bank has one source of truth: server/seed.js holds the ten pinned questions, and server/bank.js loads them into a JSON file (data/bank.json, gitignored) that every read and write goes through. I checked each seed entry against the brief. Wording, right answer and explanation match for all ten, and the answer indices point at the right text (e.g. T2 answer: 0 is 'Output tokens', K3 answer: 0 is 'Lint'). The server never sends the key before answering. server/app.js GET /api/questions returns bank.playable(), which goes through toPublic (bank.js) and strips answer and explanation. POST /api/answer is the only route that returns correctIndex and explanation, and check() computes correct on the server. The frontend has no question bank or key: public/js/views/quiz.js renders only what api.questions returns, and the report and author views read from the API or localStorage holding a post-answer report. Validation lives once in server/validate.js, and the client only displays the field errors it returns. Reading and shaping are separated: api.js wraps fetches, report-model.js is a pure builder, and report-store.js handles persistence. Minor deductions: report-store.js loadReport trusts the parsed localStorage shape without checking it, and the data/ persistence path is not exercised by any probe. I did not run the app, and no probes were registered or delivered.

Naming is mostly clear and matches what things are: checkAnswer-style bank.check, buildReport, scoreByTopic, loadInto, quizHref. Dead code is minimal and the shared helpers (loadingNote, errorNote, loadInto in views/shared.js) remove what would otherwise be copy-paste across the home, report and author views. Deductions: the author renderAuthor mixes data, actions and markup in one closure (public/js/views/author.js), and onKey in quiz.js uses a dense findIndex over LETTERS with an inline && fallthrough that reads awkwardly. The confirm(...) && act(...) expression inside onClick is a terse idiom rather than a named handler. No duplication measurement was supplied, and nothing I read approaches the 10% threshold.

Server boundaries are sound: validate.js returns field-keyed errors, app.js maps HttpError to status codes and catches unexpected errors with a 500 and a log, and readJson enforces a body size limit. Magic numbers are named (OPTION_COUNT, MAX_BODY_BYTES). Module layout in AGENTS.md matches the tree, and bank logic is kept separate from HTTP. Weaker points: renderAuthor (80 lines) and questionForm (70 lines) are longer than comfortable to scroll; questionScreen in quiz.js combines rendering, answering and key handling in one closure; load() in bank.js will throw at startup on a corrupt JSON file with no recovery; the errorSlots object is filled as a side effect while building the form. A newcomer can still change things safely because the pieces are small and the tests cover bank, validation, API and report model (AGENTS.md test/ layout).

Judged from code only: both interactive probes (quiz-flow.webm and report.png) were still open with no artifacts delivered, so the screencast and report screenshot were not verified. From the code, every pinned scenario has an implementation path. Topic selection, one-at-a-time questions, instant right/wrong feedback with explanation, and the report with score, per-topic scores (all-topics only), and per-question answers are all present. The report persists via localStorage, and the 'Start a fresh quiz' control exists. The author flow covers add, edit, remove, restore, and server-side validation with field-level errors. The key stays on the server: toPublic strips answer and explanation (src/quiz.js), and checkAnswer returns the key only after a POST. The pinned seed wording, answers and explanations match the brief (src/seed.js). Deductions: the 'can no longer be changed' rule is enforced only in the client (answered flag in public/player.js). The server's /api/answer accepts repeat submissions for the same question, so a player could re-post an answer through the API. Also, the answer endpoint returns the explanation with every response, which is fine for the flow but is not gated server-side. Visual polish and the interactive flow could not be confirmed.

No screenshot was delivered. The capture request (probe 3cd0e1f6-2173-4f3f-8698-f7d938ff2a61) is still open, so the visual hierarchy of the home, question, and report screens could not be seen. The markup and CSS alone are not a basis for a visual score.

No screenshot was delivered, so contrast could not be checked by eye. The markup does have some semantic structure (lang="en" in public/index.html:2, a labelled radio group in public/author.js, role="status" on feedback in public/player.js). That is supporting evidence only and does not replace the rendering.

No narrow-viewport screenshot was delivered. The CSS does contain a media query (public/style.css, max-width 520px) and fluid grids, but horizontal scrolling, truncation, and touch target sizes could not be verified. Scoring from CSS alone is not allowed.

The suite is small but mostly asserts concrete values. Unit tests in test/quiz.test.js cover the public view with no key or explanation (line ~12), answer checking (T2 wrong, K3 right, unknown id), and validation refusals for empty option, alike options, missing answer, explanation, topic and wording. test/app.test.js covers the HTTP flow: 422 on an incomplete question, add/edit/delete/reset with bank counts going 5→6→10, 404s, and static-file traversal. Gaps: (1) Nothing checks the pinned wording, answers or explanations against the brief; the seed test only counts topics (quiz.test.js:8-12). (2) No test that an answered question cannot be re-answered, which is a brief requirement; the server accepts repeat answers and nothing asserts otherwise. (3) No test for an answer that is not one of the options. (4) No test that the store persists across a reload (createStore on the same file). (5) The front end (player.js scoring, report.js topic scores, keyboard, localStorage report) has zero automated coverage, and no browser or end-to-end test exists. (6) Several assertions are weak, e.g. the malformed-JSON case only asserts status 200. No probe was registered, so this verdict rests on reading the code and the diff alone.

Naming is mostly clear (validateQuestion, checkAnswer, toPublic, topicScores, renderReport) and the server modules are small and focused. No duplicated blocks stand out, and the static code has no measured duplication figure to cap it. Deductions: player.js stores the live question on a DOM node (root.currentQuestion, player.js render), which is an ad-hoc side channel. dom.js's key in el && key !== 'list' special-case is opaque. author.js repeats the editing = null; errors = {}; draft = emptyDraft(...) reset in submit, reset and cancel. seed.js has very long single-line question literals. No dead code is visible in the diff.

Server layering is sound: src/app.js route table, src/quiz.js pure logic, src/store.js persistence, with checkAnswer and toPublic keeping the key server-side. Errors are handled at the boundaries (422 with field errors, 404 for unknown ids, readJson falls back to {}). Weaknesses: author.js refresh is a long function (about 30 lines) that defines submit, edit, remove, reset and cancel as closures and re-renders the whole view on each action. player.js playQuiz is about 80 lines mixing state, rendering, keyboard and timer, and it relies on an implicit cleanup ordering. Magic values such as '1234' and the 'agent-quiz:last-report' key are inline, and the 'Token economy'/'Knowledge base' constants are only partly named. Tests cover the API and quiz logic, and run/test/coverage commands are documented in AGENTS.md.

The bank has one source of truth: src/seed.js holds the ten pinned questions, and src/store.js persists the live bank to data/bank.json (src/store.js, load/save/reset). Every route reads through store.all(), so there are no drifting copies. The pinned wording, options, answer indexes and explanations I checked in src/seed.js match the brief (T1 answer 1 = b, T2 = 2 = c, T3 = 0 = a, T4 = 1, T5 = 2 = CLAUDE.md, K1 = 1, K2 = 1, K3 = 2 = Lint, K4 = 1, K5 = 1). The data layer is separated: quiz.js holds pure logic (toPublic, topicsOf, questionsFor, checkAnswer, validateQuestion) and app.js only routes. The key stays server-side: POST /api/quiz returns toPublic(), which strips answer and explanation (src/quiz.js), and the explanation and correctAnswer come back only from POST /api/answer. The client bundles no bank; public/ contains only UI code, and topic lists are derived from the API (public/main.js). Shadow data is minimal: the only browser-side data is the last report in localStorage, which is player state, not a question source. Deductions: the server does not record answers or enforce single answers (the one-answer rule is enforced only by disabling buttons in public/player.js), so the report's entries are client-assembled from server responses. The /api/admin endpoints expose the key by design. Otherwise the sourcing is honest and the server is authoritative for correctness.

The domain core is mostly clean. src/quiz.js holds the rules as pure functions: toPublic strips the key and explanation, checkAnswer compares against the bank, validateQuestion enforces completeness and distinct options, and topicsOf and questionsFor shape the views. It has no HTTP, file or DB imports, and test/quiz.test.js exercises it directly. Dependencies point inward for these rules. Several defects keep it from a higher score. (1) Outward reference in the core: src/quiz.js:1 imports randomUUID from node:crypto and newId (src/quiz.js:end) generates ids inside the core, so id generation is a non-deterministic external dependency at the center. (2) No inversion at the persistence boundary: src/app.js routes call store.all() and store.save() directly on a concrete createStore object, and there is no declared repository interface. (3) Use-case logic lives at the edge: the create, update, delete and reset flows (withQuestion, bank.splice, bank[index] = ..., store.save(bank)) are written inside the route table in src/app.js rather than in the core, so the business operations on the bank are not testable without the HTTP layer. (4) Proportion is reasonable: one store module, one router, and a pure core fit a two-hour quiz without over-engineering. The top level (src/, public/, test/) is generic and does not name the domain (quiz, bank, topics), though the file names inside src/ do. The browser modules mix DOM building and API calls in player.js and author.js, which is acceptable for a small vanilla app.

Several working extras beyond the brief, all visible in the committed code. Keyboard play: number keys 1–4 pick an option and Enter advances (public/player.js onKey, around lines 70–76). A running per-question timer and progress bar (player.js render and tick). Per-topic scores on the all-topics report (public/report.js topicScores and the topic-scores list). The last report survives reloads via localStorage (report.js saveReport/loadReport). A 'Start a fresh quiz' control (report.js). Author ergonomics: a topic datalist fed from existing topics, edit and cancel flows, a case-insensitive duplicate-option check (quiz.js validateQuestion), and a confirmed 'Restore original questions' control (author.js). Dark mode follows prefers-color-scheme (style.css). These are useful, sensible touches rather than a memorable signature idea. I did not see them rendered, so the score rests on code evidence, and no interactive probe was registered. The core flows are present in code, and I found no sign of scope creep hurting them.