KBS: List and Show
Today's log consists mostly of code generation. We've laid enough foundation that new functionality is easily produced.
List Functionality
The functionality for bs list is well defined after the work for the previous dev log. I think the experiment of directing the agents from the requirements document rather than my own intuition of what to tackle was successful, though perhaps only at the scale of a project like Knowledge Bases. The coding agent was able to select a reasonable chunk of functionality to peel off and turn into an implementation plan, with a different agent generating the implementation.
"Flaky" Tests
One discovery during the production of bs list was that the integration tests were actually "flaky". When run as dune clean && dune runtest, they would fail, and then dune runtest a second time would succeed (executable returning 0). This turns out to be desired behavior from dune — when no files have changed, it executes nothing and returns 0. I can see how this makes sense for building, but it seems like really poor behavior for running tests.
The bug causing the tests to fail was thankfully merely an output difference and not a logic issue. Coding agents using a locked down terminal apparently turn off ANSI color sequences, which resulted in asserts that don't pass when the tests are run in a full-color terminal, because of a difference in functionality implemented in Cmdliner. Fixing the bug required setting a TERM environment variable to force consistent printing behavior.
Refactor Kb_service and Show Functionality
I've been concerned about the pattern of implementation for a bit now, where each new functionality pushed major business logic into the Kb_service. It was already over 200 lines at this point. I had the coding agent draft a plan for how to split up the service in such a way as to keep the file size principle happy, while we added new functionality in the future. It chose a facade pattern where the service logic is split into other module files, but united under the same Kb_service interface to avoid changing code in bin.
Having refactored Kb_service, we moved on to implementing bs show, which went smoothly.
Service Unit Tests
The last thing we tackled was a concern that came up during the refactoring of Kb_service around the unit tests for service modules. The unit tests have been acting very "integration-y", driving a bunch of functionality with tests structured similarly to the integration tests. We came up with a plan to start also verifying the state of the database in order to simplify the tests, adding this as a coding principle for unit tests. I also edited AGENTS.md to point agents at the default opam switch in order to view library source (and docs), after I observed the agent querying the internet for documentation of the Sqlite3 library.
Relevant Commits
fcdcdb1— feat: add note status and list command4c020c4— fix(test): stabilise integration tests against host TERM setting9b33543— refactor: split Kb_service into focused service modules59d2f6c— feat: add show command for displaying item details8ee2ac5— test: strengthen service tests with state-based DB assertions