MNZY4O

The desktop capture presents a clear hierarchy with prominent balance cards, a dedicated “People in this book” sharing panel, visible roles, and a readable “Who owes whom” summary. The ledger, accounts, receipts, and category sections are organized into distinct cards with consistent spacing and controls. Evidence: desktop screenshot shows Grace as editor, Linus as viewer, and Grace owing Ada 42.00.

The screenshots show strong text/background contrast, large readable totals, explicit role labels, and debt information expressed in text rather than color alone. The committed implementation also documents centralized permission enforcement and API-level refusal in the completion note, while the visible controls have clear labels such as “Share this book” and “Remove.” Evidence: desktop and mobile screenshots; completion note describes may(role, action) and require() enforcement.

The narrow capture remains usable without apparent horizontal scrolling: cards stack vertically, the people section, role badges, debt amount, ledger, and category summary all remain visible within the viewport width. However, the compact top navigation is noticeably cramped and the ledger becomes very dense, with column labels and action buttons reduced to tiny controls, which weakens readability and touch comfort.

The repository supplies an AGENTS.md file that gives the agent basic run‑time instructions (npm start, npm test) and a brief overview of the stack, satisfying the instruction criterion, though it lacks task‑specific guidance. Reusable automation is present via npm scripts and an extensive test suite (e.g., test/sharing.test.ts) that encode the core workflow, earning credit for skills and automation. No git hooks or guardrails are defined, so that aspect scores zero. The overall codebase is appropriately sized for the multi‑scenario money‑tracker task, demonstrating proportionality. Combining these factors yields an overall moderate agentic score.

The authoritative source of truth for people, books, memberships, splits and settlements is the SQLite database defined in src/storage/db.ts and the tables in src/storage/sharing.ts. All domain logic (e.g., role checks, split calculations, debt aggregation) reads from or writes to this DB via the storage layer (People, Books, Ledgers). No hard‑coded copies of the data appear elsewhere; the only duplicated constants are the role strings (owner, editor, viewer) in src/domain/sharing.ts and the DB schema CHECK, which stay in sync and do not drift. Permission enforcement is centralized in src/http/people-api.ts via the require helper, keeping presentation code free of data logic. All outputs (book listings, debts, settlements, entry ownership) are derived from the stored data, satisfying honesty of sourcing. Evidence: DB schema and seeding in src/storage/sharing.ts (file:src/storage/sharing.ts:9‑45), role definitions in src/domain/sharing.ts (file:src/domain/sharing.ts:1‑19), permission checks in src/http/people-api.ts (file:src/http/people-api.ts:30‑46), and data access in storage classes (People, Books, Ledgers).

The code uses clear, self‑describing names (e.g., may, splitEvenly, debtsFrom, Forbidden), has no dead or unreachable code, and no copy‑pasted blocks. Permissions are encapsulated in src/domain/sharing.ts and referenced centrally, avoiding duplicated logic. No large duplicated sections were found across the repository.

The main write‑path (handlePeople in src/http/people-api.ts) consistently routes through the require helper, ensuring permission checks are enforced regardless of UI. Functions are reasonably sized, nesting depth stays shallow (max ~3 levels), and error handling is explicit. Magic values are avoided; constants like ROLES and ALLOWED are declared once. The split and debt logic is pure and well‑documented, making future changes straightforward.

Beyond the required sharing/book features, the repository implements a full crypto‑asset module (src/domain/crypto.ts) with precise unit parsing, rounding, holdings aggregation, price lookup and valuation. This provides a real, usable capability that a money‑tracker user would appreciate even though the brief never asked for it. The implementation is complete and functional, showing thoughtful extension of the product.

The codebase cleanly separates concerns: src/domain holds pure business rules (e.g., sharing permissions, split calculations) without any I/O; src/storage implements persistence and uses domain types (Role, Split, debtsFrom) to keep data logic separate; src/http translates HTTP requests into domain calls and enforces permission checks in a single place (require) before delegating to storage (src/http/people-api.ts lines 23‑45). The UI lives in src/web, isolated from backend logic. Component boundaries are clear, each file/module has a single responsibility and interfaces are well‑defined (e.g., PeopleStores in the API). Dependencies flow from higher‑level layers (UI → HTTP → Storage) down to low‑level layers (DB), with no circular imports. The size of the project matches the complexity of the required features (multiple roles, sharing, splitting, settlements), avoiding unnecessary layering while still keeping the code modular. These observations come from the file structure (list_files), the domain logic (src/domain/sharing.ts), storage implementation (src/storage/sharing.ts), and API handling (src/http/people-api.ts).

The test suite contains concrete assertions that verify expected values and behavior across the core scenarios. It covers sharing, privacy, author tracking, bill splitting, settlement, viewer restrictions, owner‑only sharing, member removal, and also includes unit tests for the core domain logic (splitEvenly, debtsFrom, may). The tests exercise both happy paths and error paths (e.g., 403/422 responses, invalid operations). While most required behaviours are exercised, a few edge cases such as invalid split configurations or over‑settlement are not explicitly tested, preventing a perfect score.