QRF3M6

At the task commit the question bank is not the pinned one. src/seed.ts:1-end declares three invented topics (Prompting & context, Reviewing AI-generated code, Testing with AI) and 9 questions, none of which are the required Token economy (T1-T5) or Knowledge base (K1-K5) items. Those pinned questions, answers and explanations appear nowhere in the tree, so the honesty-of-sourcing requirement fails outright. The bank is also held in the client: src/seed.ts is imported by src/api.ts:2 and returned as the fallback in readLocal() (src/api.ts:21-28), so the full answer key (correctIndex and explanation for every question) ships in the frontend bundle. This breaks the server-side key requirement and the 'no bank hardcoded in the frontend' rule. The HTTP path (src/api.ts:58-72) expects a Spring server that is not in the repo, and there is no server-side checking of answers. The data-layer intent is reasonable: src/bank.ts holds pure validation and upsert logic, and src/api.ts gives one QuizApi interface with a local/HTTP switch. Only the intent is credited, though, because the actual bank is wrong and sits in the client.

At the task commit the core modules are framework-free. bank.ts and quiz.ts import only the Bank, Question, Topic and Answer types from types.ts, and nothing they contain names React, the DOM or storage. The dependency direction is right where it exists. That is undercut by several findings. (1) The answer key lives in the client: quiz.ts:14 isCorrect(question, chosenIndex) compares against question.correctIndex in the browser, and seed.ts bundles the full bank with its answers. The brief requires the server to hold and check the key, so the core is wired to the wrong side of the boundary. (2) The only data-access seam, api.ts:8-15 QuizApi, is a plain CRUD mirror (loadBank/saveTopic/removeTopic/saveQuestion/removeQuestion). It has no answer-check or quiz-session operation, and it mirrors the Spring endpoints method for method (api.ts:70 comment), so it is a boundary in name only. (3) The localStorage implementation and the HTTP implementation sit in the same api.ts file as the interface, and the storage key and fetch calls are at the edge of that file. (4) The core is not fully pure: bank.ts:9 newId() calls crypto.randomUUID() and quiz.ts:3 defaults shuffle to Math.random, so randomness and ids come from the environment rather than being injected. (5) The tree is src/{api,bank,quiz,seed,types}.ts, which names mechanisms (api, seed) more than the quiz's concepts (topics, questions, attempts, reports). The app entry point index.html:10 references src/main.tsx, which does not exist, and there is no server directory, so the server-side bank and the answer check the brief requires are absent. Proportion is fine for a two-hour task: the core is small and the seams are few. The missing server and the client-held key are the main structural defects.

At the task commit the repo has no entry point (no src/main.tsx, no App component, no Spring server), so no extra feature is reachable by a user. The only extras are library-level code: validateQuestion returns per-field problems (src/bank.ts), parseBankData rejects malformed or orphaned banks on load (src/bank.ts), and the client falls back to localStorage and then the seed bank when the server is not configured (src/api.ts). These are thoughtful but invisible to an end user. The core quiz does not visibly run, so any extra mile sits on a broken base and is capped at 4.0 by the rules. No probe or screencast verified any feature.

No test files exist in the submission. The file tree at the task commit (c0d443d) contains only src/api.ts, bank.ts, quiz.ts, seed.ts, types.ts, vite-env.d.ts and config files. There are no *.test.ts or *.spec.ts files, and no tests directory. The work-window diff adds none either. Vitest is listed in package.json ("test": "vitest run") and devDependencies, so the runner is configured but has nothing to run. The only pure logic that could be tested (validateQuestion, upsertQuestion, deleteTopic, parseBankData, isCorrect and shuffle in src/bank.ts and src/quiz.ts) has no assertions anywhere. No coverage script is defined, and the AGENTS.md or README test/coverage lines the brief requires are absent. The only verification is the task's own probes, which were declined by the player, so no test output exists to check. Nothing in the submission exercises the scenarios: topic selection, answer checking, report, authoring validation, or server-side key handling.

The modules that exist are tidy, with clear names and small pure functions in src/bank.ts and src/quiz.ts. But the submission is mostly scaffolding. There is no entry point: index.html:10 loads /src/main.tsx, which is absent from the tree. There are no components, no server, and no tests. The seed bank in src/seed.ts uses invented topics ('prompting', 'review', 'testing') and invented questions, not the pinned Token economy and Knowledge base bank. src/api.ts also calls a server with no backend in the repo. Much of the code is unused, so it is dead weight rather than clean code.

A newcomer cannot run this. There is no main.tsx, no UI, and no backend, and CLAUDE.md is still a placeholder (CLAUDE.md:3-5). AGENTS.md/README is missing, so there is no run:, test: or coverage: command. There are no tests, although package.json defines a test script. The one good part is that validation is isolated in bank.ts:validateQuestion, with a clear boundary in parseBankData. Those strengths do not offset the missing app, which means the code cannot be changed or verified safely.

The committed tree does not deliver the product. There is no entry point (src/main.tsx is referenced by index.html:10 but absent from the tree), no quiz UI, no answering or report flow, and no server backend. The bank in src/seed.ts:4-6 uses the wrong topics (Prompting & context, Reviewing AI-generated code, Testing with AI) and wrong questions, not the pinned 'Token economy' (T1–T5) and 'Knowledge base' (K1–K5) sets, so the pinned-bank scenarios cannot pass. Nothing in the bank or API layer checks answers on the server; the only check is correctIndex comparison in src/quiz.ts:6-8, run client-side. The local-storage/HTTP API in src/api.ts is a data layer only, with no matching server, and the Spring endpoints it expects are not in the repo. The only reasonable behaviour is validation in src/bank.ts (empty option, duplicate options, missing explanation, missing correct answer), which covers part of the authoring scenario. The completion note .ololo/ai-sdlc-quiz-core-done.md does not exist at the task commit, so there is no claim to verify. No AGENTS.md exists either; CLAUDE.md (a placeholder that says the stack is not yet chosen) is the only doc. No probe results or screencast/screenshot artifacts were delivered, and the player declined the one probe command, so no runtime evidence exists.