KBS: Adding Todos
Today's changes build on the previous commit's unpacking of Todo, making a repository for Todos, and hooking it up to the command line to provide bs add todo ....
More Guidance
The implementation plan forgot to add a task for integration tests, which resulted in a bin principle saying changes to bin, where we're only keeping command-line parsing and top-level orchestration, should always be accompanied by an integration test. I also had the agent put together an architecture document guiding the structure of integration tests and their purpose.
In the hopes of keeping file sizes down, I added a line length principle to bin and lib. I'm not sure about these principles, because I think this can be automated as a lint. I will keep these in mind and improve the linting situation when I get another structural/syntactic principle that can be automated.
During review I noted that we had logic duplicated between bin and lib, and added a principle encouraging the pushing-down of logic into lib. I am now thinking perhaps I should work up a more in-depth architecture document for bin that is built from this principle and the first principle about no unit tests.
Lastly, I had the agent digest the part of my post on "Correct Construction", producing a lib principle, as well as a supplemental guidance document.
Automatic Reviews
Running a single generalized code review once the implementation plan is finished continues to be valuable. The concern above about code duplicated between bin and lib resulted in a cleaner system and some additional guidance for the future. Interestingly, the agent suggested removing the database argument in order to reuse the lib version of git directory resolution would be a large change, so I fed it the implementation-plan.md and produced another plan document to work on in pieces. That resulted in the 2bc74a9 commit — refactor: remove db-file argument.
Next Steps
1. Ideation. I think I am going to spend time to produce some documents on the final state of the application, rather the continuing to hand-feed the agent work piece by piece. Instead I'll let the agent figure out what work to peel off from the final state for implementation plans. It will make more sense for that kind of document to be checked into the repository; I've played around with checking in implementation plans in the past, and didn't like how agents would find them and try to "correct" the out of date code references.
2. Nesting. A code quality issue I'm noticing all over lib is the agents' willingness to keep nesting OCaml expressions 6, 8, 10 indentations deep. Multiple nested match statements make it hard for my human eyes to see the data flow. I'm going to work on prompting and/or linting to see about flattening the nesting into let-expressions.