A Calculator on a Throughline

The tool, and the contract

Throughline is a Git-native requirements tool: one small YAML file per item, a permanent UID, typed links, and a validator that fails the build on an orphan, a dangling link or an unaccepted item. The first example's technical page sets out the working contract in full. Here it ran in its plainest form: no source composed, no document generated, no challenge pass. An intent, a non-goal, and one requirement with one test for every behaviour a person can see, all written by the AI as proposed in the same turns as the code, and all ratified by the person before the evening ended.

Two graphs, and what they do not compose

Both graphs are what a fresh tl init --no-demo lays down: registers for intent, requirement, non-functional requirement, non-goal and test, and one coverage rule, that every live requirement needs an incoming verifies link, at warning severity. Neither uses the non-functional register. Neither composes a source. The first example composed an accessibility standard and a security one; the second composed six writing graphs; this one composes nothing, which is why its check is the fastest of the three and why no moved source can ever mark one of its items suspect. The price of that is on the account page: every fault was caught by a person, by the AI or by a unit test, never by a stamp.

Item before code, on every change

That is the shape of every one of the fourteen commits: the requirement and its test born first and grounded at birth, the code second, the check third, the commit naming the items. Where a request changed what a signed requirement said, the change went through tl amend with a --rationale carrying the person's reason, so the removal of the shared-causes setting and of the offline days are recorded on the requirements they altered, not only in the history. The item for content-hashed asset names, REQ-0010, was written before its fix, and the build step that enforces it exists because the item names it.

One measure in the assessment reads against this: commits naming an item, 1 of 14. The citations were in the bodies of the commit messages and the script reads subject lines. The figure is published as measured. The fix is to the habit or to the script, and finding which is the kind of thing an assessment exists for.

The gate, where it ran and where it did not

The check ran on the workstation after every change and before every commit, and never reported an error. It was not in the page's pipeline. That pipeline builds the image, scans it for vulnerabilities, refuses to publish an image that fails the scan, and tags what passes with the build's time; it does not run tl check. The site you are reading does, at strict severity, in every one of its builds; the two items behind this example were held unpushed until they were signed, because one proposed item would have stopped every build of this site.

Twelve rollouts

Each push built the image, scanned it and published it under a tag made of the build's time; the hosting's image automation picks up the newest tag and rolls it out, normally within about ten minutes. The AI hurried each one by asking the automation to look again, and checked the page from outside every time: the response headers, the redirect from plain to encrypted, the health path, and the page in a browser with the console read. Twelve rollouts in the evening, counted from the hosting's history; the first twenty-six minutes after the request.

The one defect the AI found by itself came from those checks. The network in front of the page sets a four-hour cache on the stylesheet and the script, so a returning reader would pair a fresh page with a stale script and a new slider would silently do nothing. The fix is a requirement and a test: the page references each asset by a placeholder, the image build replaces the placeholder with the file's hash, and the build fails if any placeholder survives.

Ratification, in three rounds

The first round was not a hand-off. Some way into the evening the person ran tl ratify over all thirty-two items then on the graph, without saying so. The AI's next commit staged every changed file, so his thirty-two status: ratified lines went into a commit titled for photographs and signs. His name is on each item's ratification; the commit is not his. The only trace at the time was the check's warning count falling from twenty-eight to six between two runs, which is exactly what a bulk ratification looks like and which the AI did not read as such.

Ten minutes later the AI amended a signed requirement, REQ-0014, to record the new defaults he had asked for, and the tool said so at once: the ratification no longer matched the content, and tl ratify would show what had moved and ask again. The same happened to REQ-0005 when the page began to keep the reader's settings. The second round was a hand-off: ten items, the two amended and the eight new, in one command, each shown and confirmed. The third was the tool's eighteen, in one command more. Both later rounds were committed on their own, under a message that names him and nothing else.

The rule the first round produced is now feedback the AI reads at the start of every session: in a repository that holds a graph, stage explicit paths, never everything; read an item's status before amending it; and treat a sudden fall in the warning count as a signature.

The map tool's graph

The tool's graph was written when the code was moved out of the page's repository, not before it, and its assessment says so. Its eight requirements are one per command and one per property a page depends on: a site found from a coordinate or a place search; the features fetched from open map data with a user agent that names the tool; the base map with its entrance junctions labelled; cameras placed in a browser and saved back to a file; the illustration with numbered cameras and group labels; an inline figure a page can theme by class under a strict content-security policy; every output derived only from three recorded files; and, added the moment the page needed hover photographs, each camera marker an addressable group carrying its id. Eight tests, one per requirement, most of them exercised by a unit suite on a synthetic site of one shop, one car park and one road.

Determinism as a requirement is what turned the first run on real data into a finding rather than a surprise: the tool's output was diffed against the hand-made map and differed in two junctions the frame did not show. The filter that fixed it dropped a junction on the synthetic site's edge and three tests failed; a half-metre tolerance fixed that. Both faults were found before the tool's first commit. The assessment records them as defects after "done" because the tests had been green.

The assessment

Both graphs were assessed at "done" with the assessment script of the tool's skill, which applies fixed criteria (strict check clean, documents current, nothing proposed, working tree clean) and measures the graph, the git history and the session record. The windows are from one session and overlap; the table says so rather than splitting them.

The page's lines added include the fetched map data and the generated figures, which are most of them. Its test files read zero because its tests are the graph's test items, checked by hand and in a browser rather than by a suite; the tool's are a suite. The page's rollouts, twelve, are not in the table: the script measures the repository, and the rollouts are commits in another one.

What the tooling taught