DEE2QL

The submission goes beyond the required CRUD ledger with several genuinely user-oriented touches: month filtering, a persistent SQLite-backed book, post-redirect-get to prevent duplicate submissions on refresh, correction forms that preserve typed invalid data, and validation that reports all detected problems at once. These fit a personal finance ledger and are implemented in the delivered code. The extra category view also provides separate income/expense totals per category. Evidence: lib/serve.ts:18-24, lib/serve.ts:50-62; lib/pages.ts:106-128, lib/pages.ts:143-165; lib/ledger.ts:43-71; lib/store.ts:43-47, lib/store.ts:93-101. Automated verification could not run because package.json's test glob was not found by the environment, as shown by probe:ledger-tests.

The repository includes a clear AGENTS.md that tells an agent the stack, how to run (npm start), how to test (npm test), and a working agreement (TODO/NOTES). This provides solid guidance but omits the task‑specific constraints (e.g., the pinned March balance of 3223.70). Automation is present via npm scripts and a comprehensive test suite that the agent can invoke to verify correctness, showing reusable commands. No automatic guardrails such as pre‑commit hooks are defined, so mistakes are not caught without explicit test runs. The size and content of the agent configuration is proportional to the small task, offering just enough structure without unnecessary bulk.

The ledger’s dataset is defined in a single place – the MARCH array in lib/store.ts (lines defining initial entries) – and accessed exclusively via the SQLite store. No duplicate copies of the entries exist elsewhere. Category and kind lists are also defined once in lib/ledger.ts. All calculations (balance, totals, per‑category) are performed in ledger.ts functions (balanceOf, totalOf, perCategory) and used by the presentation layer (lib/pages.ts), keeping data handling separate from rendering. Tests (test/scenarios.test.ts) confirm that the output balances and totals match the pinned facts, showing honest sourcing. No hard‑coded amounts appear in markup or logic, and there are no shadow data artifacts. The only minor limitation is that the initial data lives in code rather than an external data file, but it remains a single source of truth.

The codebase cleanly separates concerns: ledger.ts holds pure domain logic and validation; money.ts handles monetary parsing/formatting; store.ts encapsulates SQLite persistence and maps domain types to rows; pages.ts builds HTML views from domain data; serve.ts wires HTTP routing, form handling, and orchestrates the other components. Dependencies flow one-way (serve → store/pages → ledger → money) with no cycles. Each component has a single, well‑defined purpose, making them replaceable and testable in isolation. The layering matches the task size—no unnecessary abstractions, yet distinct modules for domain, storage, presentation, and server—so the structure is proportional and maintainable.

The code uses clear, self‑describing names for types, functions and constants (e.g., KINDS, CATEGORIES, Draft, Refused) and contains no dead code or obvious copy‑paste. Duplication is minimal; a quick scan of lib/ledger.ts, lib/pages.ts and lib/store.ts shows no large repeated blocks, keeping duplication well below the 10 % threshold.

Functions are short and focused (e.g., read in ledger.ts validates all fields at once, perCategory aggregates totals, page builds the view). Error handling is centralized in the Refused class, and all magic values are named constants (KINDS, CATEGORIES, MARCH). Nesting depth stays low, and the code is pure‑functional where possible, making future changes straightforward.

The test suite contains substantial assertions across unit and integration levels. ledger.test.ts asserts balances, totals, per-category aggregation, validation errors, and month extraction. money.test.ts verifies parsing, formatting, signed output, and exact arithmetic. scenarios.test.ts walks through the full set of task scenarios, checking entry addition, correction, removal, error handling, exact totals, non‑existent corrections, and month filtering. Edge cases like missing date, zero/negative amounts, multiple validation failures, and invalid dates are covered. The mix of unit tests and higher‑level scenario tests provides good coverage without relying on implementation details. Minor gaps remain (e.g., extremely large amounts, concurrency), so a near‑perfect score is warranted.