Six months from now someone will open a file, find a line that looks arbitrary, and ask why it’s there. With agent-written code, the author can’t be asked. In DynoInvoice the answer is in the record. Here is one line, followed all the way back.
The line
45 val change = request.history.firstChangeIn(cursor, window.end)
46 if (change != null) {
47 kinds += PeriodKind.TRANSITIONAL
48 end = change.effectiveFrom.minusDays(1)49 }
In plain words: when a business changes how often it files GST returns partway through a window, its old filing period ends the day before the change. Read cold, it looks like a missing branch. It did once have one.
The trail, step by step
1 · The commit
c2707a7a, 15 October: “cut at the change date only; remove TransitionStyle and the pack transition field (INV-Q-5045 A)”. The version before it, 20145db7, chose between two styles, CUT_AT_CHANGE and EXTEND_TO_NEW_WINDOW. This commit deleted the second style, the setting that selected it and its test fixture.
2 · The task
INV-T-4963, “Implement calendar-and-periods”, merged the same day. It implements five requirements on filing periods.
3 · The requirement
A change mid-period creates a transitional period, shorter or longer than the standard one, with explicit dates, confirmed by an operator. A standing rule says filing law is versioned data, never code, which is why the library holds no frequency constants and the cut is the one thing fixed in code.
4 · The criterion
INV-AC-154: a quarterly filer that switches to monthly from 1 February 2026 gets a transitional period ending 31 January 2026, flagged irregular, with a warning, unconfirmed until confirmed.
5 · The question
The coder’s first version let the rules pack choose the style, then stopped. Only cutting at the change reproduces INV-AC-154. Extending appears in no published sentence, and for the criterion’s own example it would give 1 January to 28 February, contradicting it. The agents classed this as a question for the owner, not one they could rule: which filing periods exist decides which return covers which dates and when it is due.
6 · The ruling
The owner chose option A, cut at the change. The task was revised, and the coder removed the extend style. That is commit c2707a7a.
7 · The review
The reviewer required a test that two overlapping windows of one frequency are refused, plus the adjacent-but-not-overlapping case, “so the check cannot be weakened to always-throw or never-throw” (8ab19cbc), and that the README say no filing rule is built in. After the ruling, the README still said the pack decides the cut; that was fixed too (1a5a9271).
8 · The tests
PeriodGenerationTest.kt line 102: “quarterly to monthly effective 1 Feb 2026 ends the transitional period on 31 Jan (INV-AC-154)”; line 116: “no transitional period ends on or after the day its change takes effect”. The fixture change-cut.csv covers 10 May 2026: a period from 1 April to 9 May, 39 days.
What the trail shows
One odd-looking line led to a deleted alternative you can see in the history, a criterion that settles the behaviour, a question the agents declined to answer themselves, and a one-letter answer from the owner that decided which tax periods exist. None of it lives in a code comment that could drift. It is in the record, linked to the commit, the task and the tests.
That is what accountability looks like for agent-written code: not “the agent decided”, but a trail anyone can follow to the requirement and the person who ruled.
This page explains how the software behaves; it is not tax advice. The filing rules themselves are data in a calendar rules pack that is still being built.