XZQWL6

All seven scenarios hold, and the pinned constraint — roles decided where the decision is actually made — is genuinely met: the three-role table lives once in src/money/people.ts (may(), ALLOWED map), and every mutating route asks it server-side via refuseUnless(c, action) — entries POST/POST-id/DELETE and API PUT/DELETE in src/web/app.ts, all five receipt routes in src/web/receipts.ts, accounts/transfers/rates/home in src/web/currencies.ts, trades/prices in src/web/crypto.ts, and share/remove/settle in src/web/people.ts. I traced each scenario: (1) share: owner-only /books/:id/share upserts book_members; Grace's /api/me then lists Household as editor and POST /entries records with recordedBy=2 (tests/people.test.ts 'a book is shared'); (2) private stays private: the viewer is built only from db.listBooksFor and the book cookie is accepted only for books the user is a member of (src/web/auth.ts authMiddleware), other-book entries 404 via entryInBook/db.bookOfEntry, and the test proves Ada's salary entry is invisible to Grace by page, API, PUT and DELETE while Ada's balance stays 3223.70; (3) authorship: entries carry recorded_by/paid_by (migration 6), shown as 'recorded by X · paid by Y' under the note in shared books (src/web/views.ts who()) and visible in book-editor.png; (4) the 84.00 split is exact bigint arithmetic — splitEvenly(8400n,[1,2]) → [4200,4200], remainder cents go to the first people (test with 1000n/3 → 334/333/333), and both Ada's and Grace's /api/books/2/debts plus the /people page show 'Grace owes Ada 42.00'; (5) settling: POST /books/:id/settle inserts a settlements row, debtsOf nets shares minus settlements to zero, and the settlement stays in history — visible in people-desktop.png ('Grace paid Ada · paid back in cash 42.00 EUR' alongside the new 15.00 debt from the pizza split); (6) viewer refusal: tests/people.test.ts hits the raw requests a hidden button would have sent (POST /entries, PUT/DELETE api, form delete, receipts, crypto, share, settle) and gets 403 with data unchanged, and book-viewer.png shows the read-only screen; (7) removal: /books/:id/members/:userId/remove deletes only the membership — Grace gets 403/no book, her tram entry stays with recordedBy=2 and renders as 'recorded by someone no longer in the book'; owner cannot be removed, editor cannot remove. Carry-forward holds: the 46 earlier tests are unchanged and the probe-delivered run shows 55 pass / 0 fail; earlier modules were only threaded with bookId parameters, defaults preserving prior behavior. The done note is accurate and honestly declares limits (handle-only sign-in, even-only splits, single-currency debts — debtsOf accepts a currency field but never uses it when netting). Two minor coherence gaps keep it from 10: a viewer can still GET /entries/:id/edit (a dead form — the POST is refused, but the page itself is reachable by guessed URL, which sits oddly with 'refuses him even when the buttons are not on the screen'), and the settle API validates the payer's membership but accepts a recipient who is not a member of the book (db.getUser(to) only).

The delivered captures show a coherent, designed product, not default styling: balance as the obvious oversized headline with negatives in red, a warm/teal color system, role tags next to each member with the brief's exact role wording, debts with bold names and right-aligned tabular amounts, a settlements history row, and an editor form that clearly groups 'Paid by' and 'Split evenly with' with a legend and hint. The visible state is consistent with the scenarios (42.00 settled, then Grace owing 15.00). Minor deductions: the closed 'As' select truncates ('editor — add, ec') on people-desktop, and the signed-out card is sparse with the page mostly empty.

Markup and screenshots agree: lang='en', skip link, real headings, labels tied to inputs, a fieldset/legend for the split checkboxes, role='status'/'alert' flashes, table with sr-only caption and th scope, time[datetime], aria-current month links (src/web/views.ts:57-160). Information is never color-only: negative amounts carry a − sign and 'out' labels, roles are text tags, and dark mode is provided via prefers-color-scheme. Captured text is real, high-contrast text (muted #6b665c on card ≈5:1, danger ≈6:1); the #9a6b00 warning tone used for missing-rate notes is borderline for its small size, the only soft spot.

Both narrow captures (375px) hold up: single-column stacking with no horizontal scrolling and no truncated or overlapping content; the entries table reflows into per-entry cards (grid-template-areas in src/web/static.ts:150-172) keeping the 'recorded by / paid by' attribution, and the people page stacks books, members, share form, debts and settle form cleanly. Touch targets are adequate though the small Remove/Delete buttons are compact; the 'Paid by' select keeps a narrow 1fr column beside the split fieldset on mobile, and the brand wraps to two lines in the header — all minor.

A proportionate, honest two-level suite. Unit level (tests/people.test.ts:37-56): the role table is asserted action-by-action including the undefined-role case; splitEvenly is pinned to exact cents (8400n over 2 -> 4200/4200; 1000n over 3 -> 334/333/333, remainder not lost) and debtsOf is tested for share-owes-payer, opposite-direction cancellation, and settlement clearing. Integration level: seven tests drive the real Hono app with real in-memory SQLite, cookie sessions and distinct signed-in people, each mapping to a task scenario — Grace finds the shared book and records (201, recordedBy=2, paidBy=2 asserted); privacy is checked by page, API, guessed entry id (404 for edit/PUT/DELETE) and side-effects (Ada's balance stays 3223.70, no 'grace' entry); the 84.00 split asserts exact debts 42.00 visible to both via API and rendered HTML; settling asserts debts empty, settlement in history, page shows 'Grace paid Ada'; the viewer test refuses POST/PUT/DELETE on entries plus receipts, trades, share and settle routes with buttons verified absent from Linus's HTML and state verified unchanged; removal takes access (403/404, /api/books/2/debts 403) while entries persist with recordedBy=2 and 'recorded by someone no longer in the book'. Error paths beyond the happy path: strangers 401, no-book 403, invalid month/book 404. No skipped, commented-out or tautological tests; assertions state behavior (status codes, exact amounts) not implementation. Probe b4800539 shows npm test 55/55 green, matching the done-note's claim. Held back from 10: the settle route's 422 validation branch (bad payer/date/amount) and the share route's 422 paths (invalid role, self-share) are untested through HTTP; a viewer reading /api/books/:id/debts is untested; split preservation on entry edit (split omitted) is unasserted.

Beyond the scenarios, the build carries several working, user-considered touches: entries of departed members keep rendering as 'recorded by someone no longer in the book' (src/web/views.ts:88-95, tested at tests/people.test.ts:169-183); 403s explain who you are and what the role excludes rather than a bare error (src/web/auth.ts:66-78); viewers get a written explanation instead of silently missing forms; remove/delete carry confirm dialogs whose copy says entries stay; debts net pairwise and are always computed, never stored (src/money/people.ts:56-97); split remainders are exact to the cent with a test (10.00 → 3.34/3.33/3.33). The permission design itself — one role table asked by every mutating route — is clean engineering, and the probe (412d0d68-91f7-470c-b5f2-7c5006e76586) confirms all 55 tests run green on the player's machine. Not 8.5+: no single memorable showpiece (no invitation links, no custom share ratios — honestly listed as not built), so it stays in the 'two-plus genuine touches, working' band near its top.

Naming is consistently descriptive (may(role, action), refuseUnless(c, "write"), entryInBook, applySplit, splitEvenly, debtsOf, bookOfEntry), and the permission decision really is one table (ALLOWED in money/people.ts) with zero copy-pasted permission logic across the five route files. No dead feature code, but three small blemishes: (1) src/money/people.ts:11,103 imports and re-exports divRound that nothing in the module or codebase uses — dead weight; (2) the 'is this a JSON request?' predicate is re-implemented inline with slightly differing predicates (some check accept, some only content-type) in at least six places across app.ts, receipts.ts, people.ts, currencies.ts, crypto.ts instead of reusing auth.ts's wantsJson; (3) a sprinkle of as any/(c: any) casts (viewerOf(c as any) in entryInBook, renderBook = (c: any, ...), (r: any) row mappers in database.ts — the latter continuing the file's pre-existing style). Dense one-liner style in database.ts's return object is inherited, not introduced.

A newcomer could safely extend this: adding a role means one entry in ROLES/ALLOWED plus the SQL CHECK; every mutating route in every module gates through the same refuseUnless helper so the pinned owner/editor/viewer table holds where the decision is made, not in the template (tests/people.test.ts asserts exactly that, including refusing a viewer's raw POST/PUT/DELETE and share/settle calls with the buttons off-screen). Access scoping is enforced at the cookie-acceptance point (books.find(...) ?? books[0]) and per-object (entryInBook, receiptInBook, account.bookId checks in transfers/trades), with cross-book ids answering the same 404 as missing ones — deliberate and documented in DECISIONS.md. Nesting stays shallow (≤3), route handlers are short, boundary validation is thorough (settle route checks membership, self-payment, date, amount; split ids are filtered to book members; remainder cents distributed so shares sum exactly). Weaknesses for a newcomer: the page-builder views (peoplePage ~110 lines, bookPage ~130) are long flat template concatenations — the project's established style, readable top-to-bottom but a scroll to read; entryForm has grown six positional parameters with two optional object tails; and the dual-cookie book context is implicit state whose rules live in one well-commented middleware. The 9 new tests read like the task's scenarios with a clean cookie-jar person() helper, which is the strongest maintainability signal here.

The submission keeps the layering the earlier parts established and extends it cleanly for multi-person books. Pure domain logic lives in src/money/ with no I/O: the new src/money/people.ts holds the pinned permission decision as one table (ALLOWED/may at people.ts:13-23), exact-cent splitEvenly, and debtsOf computed from shares minus settlements — debts are derived, never stored, per DECISIONS.md. All SQL stays in src/db/database.ts ('the only file that speaks SQL'), where migration 6 adds users/books/book_members (with a role CHECK constraint at the DB level too), sessions, entry_shares and settlements, and every listing is book-scoped in the query itself (selectAllInBook, selectSharesInBook, etc.), giving cross-book isolation by construction with 404-parity for foreign entries (entryInBook in app.ts, receiptInBook in receipts.ts, notHere in people routes). The web layer is per-feature Hono routers (app.ts, people.ts, receipts.ts, currencies.ts, crypto.ts) over a shared auth seam: authMiddleware resolves the Viewer from a session cookie plus a book cookie validated against membership, and refuseUnless(c, action) asks the money/people.ts table at every mutating route, so permissions hold server-side exactly as the contract pins — tests/people.test.ts even asserts 'the role table is the only place permissions live'. Dependencies flow one way (web → db → money); money imports nothing. Deductions: page builders query the database inside view assembly (peoplePage in web/people.ts takes db and calls listUsers/listMembers/debtsIn among the markup; renderBook in app.ts mixes orchestration and rendering glue), database.ts has grown into a 31KB catch-all with a ~60-method interface every web module reaches across, web/crypto.ts helpers default to bookId=1 rather than requiring explicit scope, and people.ts carries a vestigial unused re-export of divRound. None of these break a boundary; they blunt the edges.