Commit Graph

3 Commits

Author SHA1 Message Date
Homer 3afbccba81 A time in no particular zone, and a preview missing what it previews
The first audit pass: everything from 0.8.1 to 0.9.8 read as a whole rather
than one feature at a time, starting with what a model is actually told.

Four of these had shipped as correct. The date line carried a timezone
variable that resolves to nothing until somebody chooses one -- so every
default account was told times were "in  unless they say otherwise", while
two comments asserted the line disappeared instead. The prompt preview
built its variables without a chat, which is what eleven fragments are
gated on, so the whole agent surface was absent from it whatever was
ticked. Plan mode was instructed to keep its plan current with a tool that
mode withdraws. And knowledge_get returned a document whole where every
sibling reader caps and says so, its description promising exactly that.

The subagent guidance was wrong in both directions at once: it denied a
documented parameter and named seven of twenty-three allowed commands.
Both halves are pinned by tests against the real list and the real schema
now, because prose and a constant drift the moment one is edited alone.

docs/notes/audit-0.9.md carries the findings that are not fixed here, with
why -- the ones whose fix would change what a feature does are the user's
call, not this pass's.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-07 09:13:54 +02:00
Homer d201521353 A helper that would have deployed a channel nobody named
The channel is declared twice: in lembas.env, which this process reads and the
page prints, and baked into the systemd unit, which is what the helper actually
deploys. install.sh writes both together so they agree by construction -- and
the moment somebody edits one by hand they diverge, with the page naming one
channel down every card and the button deploying the other. Nothing anywhere
would have said so.

It cannot be collapsed to one place. Reading it from lembas.env at deploy time
would mean the service account decides what gets deployed, since it owns that
file -- and "the request carries no channel" is the property the whole design
rests on. So the two stay, and the marker file the page already reads to know
the helper exists now carries the channel it was installed with. A disagreement
is an alert.

Display only, deliberately: the service account can write that marker, so a
compromised process could lie about what the helper will do -- but not change
it, because the helper's own channel lives in /etc where that account cannot
reach. Lying about the channel is a much smaller thing than choosing it.

An empty marker -- every host installed before this -- reads as unknown rather
than as a mismatch. Claiming one would put a red alert on every existing host.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-06 21:44:35 +02:00
Homer 44920b62be A changelog, kept from now rather than assembled at the end
Every version bump gets an entry in the same commit. Not afterwards: the reason
a change was made is known while it is being made and gone a week later, and a
changelog assembled from commit subjects at release time is a list of things
nobody can act on.

Backfilled 0.8.2 through 0.9.8, because those shipped as a running deployment
rather than as releases and 1.0.0's notes have to be assembled from something.

The rule that earns the file its place is the last one in CLAUDE.md: a fix to
something that *looked* like it worked gets a line, always. Those are the
entries somebody stops working around a bug because of, and they are invisible
from outside -- nobody reports a control that silently does nothing, they just
quietly stop using it. Half of what is in here is that shape: a group delete
that left its grants, a share panel that only saved if you also saved the
resource, an update script that stopped after "== fetching ==".

A release is a signed annotated tag whose message is that version's entry, and
that is not decoration -- /admin/updates reads release notes out of the tag
object, so the tag message is literally what an administrator sees on the update
page.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-06 21:36:44 +02:00