Builtpublic

S7 · Finalize

The rule document owns the procedure and the runner reads it at execution time. This stage does not stop on failure.

try/continue

Confidence stamping, dashboard refresh, project metadata, labelling, document upload, notifications, releasing the run lock. The wrap-up work lives here.

The code does not own the procedure

The order of operations and the wording of the notices live in a rule document, which the runner reads at execution time and carries out. The procedure is not written down a second time in code.

The reason is that there are two entry paths — me calling it from a session, and a remote call from Slack. Bake the procedure into code and the two paths drift apart quietly. A procedure that only gets fixed on one side is the dangerous kind.

The same goes for the panel text stamped into the sheet. The script reads it from the rule document when it runs, so changing the wording never means opening code.

Confidence is not judged here

Every case gets a 0–100 score for how solid its basis is. Low scores show as colour in the sheet, and a note carries the score, why points were deducted, and where in the spec to look.

The point is that no LLM is called here at all.

The judgement was already made upstream. The design tags, the cross-reference record, and the coverage gate left traces behind, and this stage merely aggregates them deterministically and transcribes. Had it been built to ask a model “is this case trustworthy?” at the end, running the same sheet twice would have produced different scores.

Idempotence rules ride along: every run resets the colouring and re-stamps, and it only touches notes carrying its own signature. So a note somebody wrote by hand never gets erased.

Failure here does not stop the run

Every earlier stage halts if it can’t clear its gate. This one is the opposite — one failed item doesn’t stop the rest, and the exit code reports “partially failed.”

Because the test cases are already in the sheet. Failing the whole run because a dashboard refresh failed records work that actually succeeded as a failure.

But it must be written into the report. An unattended run finishes on green lights regardless of quality. The completion report is the only observation window there is, so staying quiet here means that run passes with nobody having looked at it.

Which is why the required contents of that report are pinned down — confidence distribution, output sizes, the list of what review deleted or changed, and the linked-document collection result. That last one: if it’s zero, it says “no references.” Saying nothing and saying there were none are different.

It advises; it doesn’t execute

At the very end, optional follow-up work gets a one-line notice each — whether to run image matching, whether to set up test data.

It advises and does not execute. Whether those are needed is a judgement for a person at that moment, not something the pipeline should bolt on by itself. The more unattended a thing runs, the more precisely you have to decide in advance where it stops.

Then it releases the run lock. It releases it on abort paths too — leave it held and a finished run still looks “in progress,” and the next person can’t edit.