The previous commit set 'status: slice-1', which the schema does not allow, and
it reached the remote because my shell chained the push to the wrong command
rather than to the validators. The gate the slices run under is gate 4.
The slice changes no behaviour: the scanner still reads the old list. What it
adds is the ability to say how much of the estate is covered, and its acceptance
is a number already known by hand.
Both mistakes in this slice were caught by controls rather than by luck. The
counter-proof about tag ordering was itself wrong — name ordering loses v0.10.0,
not v0.8.0 — and the test failed until the reasoning was fixed. The first edit
to the compose file assumed the wrong indentation, and the assertion in front of
it stopped a half-applied change from being written.
Slice 1 changes no behaviour at all: the derivation runs, the metrics appear,
and the scanner keeps reading the old list. Its acceptance is a number already
known by hand — 24 missing, 2 orphaned, coverage near 0.52. If the derivation
disagrees, the derivation is wrong, not the hand count stale.
Rolling out is a handover, not a step of mine. Port 2248 on the operating host
answers from the matrix node and agent forwarding carries, but the key is not
authorised there, so the procedure written after this very stack applies:
whoever builds hands over, whoever deploys verifies and writes the AAR. The
quantities that procedure demands are in the doc: about 65 targets instead of
29, about 90 registry requests per derivation, and up to 65 possible messages a
round where yesterday brought 12.
Slice 2 sets the missing-targets rule above the current value on purpose and
only pulls it to zero in slice 3, so the room never learns to live with a red
alert. Slice 5 is where this can still fail quietly: if cAdvisor only shows what
runs, a stopped service is absent from the desired set and coverage still reads
100 percent.
Gitea's package API wants a token, so the tag timestamps come from the registry
itself: manifest, then config blob, then the created field, anonymously, about
ninety requests a round. The constraint of no new credentials survives.
The derivation is cached rather than run per scrape; at a fifteen second scrape
interval it would otherwise make some twenty-one thousand registry requests a
day.
Two assertions carry the design. A source that fails must leave its own share
empty while the others keep delivering, and when every source fails the target
file is not overwritten at all. Deleting reports follows the same rule: no
target file, no deletion, or a restart during a Prometheus outage would clear
the whole estate.
The shakiest call is written down as such: cAdvisor only sees containers that
run, so a service that happens to be down is missing from the desired set and
coverage still reads a hundred percent. That is the hole ADR-0026 warns about,
and Gate 4 has to check it against docker compose config before criterion 2
counts as met.
The set of targets that should be scanned is built where the set that was
scanned is already known: in the existing exporter. Anything else needs the
same derivation twice, and two derivations are two truths. That also settles
where the coverage metric comes from.
The AAR of 2026-08-01 decided one thing outright. Its third finding says a
stale-scan rule cannot report an image that never scanned, because no series
exists to hang the expression on. A coverage figure built from existing series
is therefore blind to exactly the gap it is meant to show, so it has to come
from the desired set instead.
Two prices are written down rather than discovered later: a target that leaves
the set must lose its report, or an image no one runs keeps reporting; and more
targets mean more messages, roughly 65 instead of 29 per round, which Gate 5
has to measure since the reporting path itself is out of scope.
ADR-0026 generalises it — derive targets, never maintain them — with the
condition that makes it safe: a derivation that fails looks like full coverage,
not like an outage, so its freshness is itself alerted.
Six countable criteria, the first of which is that images.txt stops existing and
is not replaced by another maintained file. Coverage of the running estate has
to reach 100 percent, measured as a set difference over normalised names, and
stay visible as a metric so the gap cannot return quietly.
The open question is how far "everything from the registry" reaches. Six repos
hold 36 tags; seven are CI artefacts and 25 of the remaining version tags run
nowhere. Scanning all of them triples the workload and puts findings about
v0.1.0 into the security room — the exact noise this work removes. Three
readings are laid out with a recommendation, not a decision.
The ledger records the rungs: nothing needed building for the sources. Both
image sets already live in the same Prometheus the scanner can reach, and the
registry answers an anonymous token. It also records two wrong turns of my own,
including reading a registry 401 as "needs credentials".
#0078 asked for a CVE reporting path with its own room, metrics, a dashboard and
aggregated alerts. ADR-0003 decided it on 2026-08-01 and it was built right
after; the issue has described an accomplished state ever since. Measured rather
than read: the bot is joined, 173 messages stand in the security room, five
rules route by label, the dashboard exists.
What the check does not say is which images it never looked at. The target list
is hand-maintained and covers 27 of 51 running images — 52 percent. Missing are
the web client every user loads, both Traefik layers, the registry itself, the
whole observability stack, and the scanner's own image. Two entries are scanned
and run nowhere, so the room carries findings about an image no one uses.
#0106 carries that on, with sorb's requirement: derive the targets from the
stack and the registry, drop the list rather than police it.
#0056 asked for HA plus replication. The cluster is one node, measured
repeatedly during #0088 and written into two manifests as a constraint.
Replication on a single node does not buy what "HA" means, and the loss case is
already covered by rehearsed restores rather than by replication. Struck as
sorb decided; it becomes a new issue if a second node ever exists.
#0004 is a homelab host and outside this project's scope. It held the milestone
open without ever being worked.
#0078 (CVE reporting path v2) goes to in-progress.
The gate rows can only name their commit once it exists, so they follow the
work rather than riding along with it.
The ladder rung about the DNS pointer said the Corefile imports
`custom/*.override`. Measured against the running Corefile it imports both —
`*.override` inside the main block and `*.server` at the end. The choice of
`.server` was not arbitrary: a second `hosts` block in the main block would
collide with `NodeHosts`. The rung now says so.
The last open line of the smoke list is no longer an argument. With all four
waves in force since 09:39, OpenID tokens were issued at 11:49:58, 11:57:18 and
11:57:56 — read from `open_id_tokens`, not from a self-report. Without one no
call starts, so the criterion is met by measurement.
ADR-0025 moves to accepted, the design doc to done/, and #0088 to done with its
closing section. The node-address gap is carried forward for the next harvest:
it bounds every claim these rules make.
A new stolperstein: while closing this piece of work, a user reported hanging
calls and a hanging identity reset. Four causes were claimed in a row and all
four were disproven by the next measurement, two of them after an objection
from sorb. The actual cause was an account without a row in the homeserver's
`profiles` table — documented ten days earlier and unrelated to egress. The
lesson is the order: on a report during a piece of work, measure the difference
between affected and unaffected users first, before auditing your own change.
Federation answers, sign-in confirmed by the owner, a backup ran, ClamAV's
signatures are from yesterday, the wiki returns 302 from outside. One line
is not ticked: a call was not tested. Neither coturn nor the SFU was
touched, so this undertaking cannot have affected calls - but that is an
argument, not a test, and it stands here as the argument it is.
Acceptance criterion 1 of this very document is named as wrong rather than
quietly reinterpreted. It demands zero workloads left with only the broad
rule, and it was written before Gate 2 introduced the class that exists to
keep exactly that. What holds is what it should have said: every workload
is either narrowly ruled or documented as a reasoned exception at the
selector. Four remain open, all with a reason.
The pattern behind every correction in this undertaking: they came from
measuring, not from thinking about the plan. And four times the tool was
wrong rather than the subject - /dev/tcp in an sh, no nc in alloy, find
-printf in busybox, busybox TLS against Traefik. Each looked like a
finding.
Recorded for the next harvest: traffic to the node's own address escapes
the policy entirely, so every "internal only" workload still reaches
whatever the ingress publishes. Not a fault of this work, but it bounds
every statement about these rules and the framework does not know the case.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F2Q4Ri8NGwyTZzScvKnWFM
Measured from inside the restricted pod, not at the port but at the chain:
the homeserver's health endpoint returns 200 over the internal service
name, and Authentik's discovery document returns 200 with the correct
issuer. MAS has not restarted.
An intermediate step reported a failure that was not one. The first
discovery check ran with busybox wget and ended in a TLS alert from the
peer - which looks like a block and is the opposite, since a TLS alert
requires an established connection. Busybox's minimal TLS simply did not
satisfy Traefik. With a client that speaks TLS properly the answer was 200.
That is the fourth measurement today spoiled by the tool rather than the
subject, and the fourth caught only because the result was held against a
second measurement. The pattern is worth more than any single finding here.
Final count: four workloads keep broad egress in matrix, none in authentik
or monitoring. Three of the four are service characteristics, the fourth is
the documented CDN exception.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F2Q4Ri8NGwyTZzScvKnWFM
The five remaining open workloads now carry their reason at the selector
rather than in an issue. An unexplained open egress reads as neglect, and
whoever reads the rule should not have to guess whether it is intent or
leftover.
ADR-0025 decides the direction the whole undertaking kept running into: pin
what holds, prefer a private path over a public one, allow a small provider
block where a /32 would break silently, and leave a CDN target open with
the reason at the rule. It also records what the decision does not achieve
- traffic to the node's own address escapes the policy entirely.
MAS is resolved and turns out to be restrictable. Its configuration is not
in the repo and its container is distroless, so it was read from the
running process through /proc in an ephemeral container: the homeserver by
internal service name, Authentik by public name - and public names resolve
to the node address, which no policy covers. The reason for keeping it
broad is therefore gone.
It is still not restricted. The sign-off is a real login, which this
session cannot perform, and a mistake there hits authentication. The
manifest now says exactly that: what is open is the acceptance, not the
analysis.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F2Q4Ri8NGwyTZzScvKnWFM
authentik and monitoring are at zero workloads without a narrow rule;
matrix still has five, and those are exactly class C.
Destinations were read rather than guessed: alloy's from its running
configuration, authentik's mail host from the worker's environment. Mail is
load-bearing - the blueprints use password recovery and invitations - and
gets a /27 rather than two /32, deliberately the opposite call to ClamAV,
because a provider's mail block is not a CDN in front of half the internet.
The sharpest piece of evidence is the same host on a different port coming
back blocked: the rule bites per port, not per host.
And the positive control caught its third bad measurement of the day. The
first probe in alloy reported everything blocked including CoreDNS, because
that container has no nc and the command silently failed. Without the
control this would read "alloy is cut off" while it was shipping logs in
that very second. Repeated through an ephemeral container.
All restart counters in authentik date from 472 hours ago, so none of this
wave caused a bounce.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F2Q4Ri8NGwyTZzScvKnWFM
rohana now resolves to 10.0.0.3 from inside the cluster and TLS still
validates over that path, both measured from a pod. wikijs reaches exactly
that one address and nothing else; a triggered synapse-backup ran through
and wrote its archive, so the storage box allowance carries. Nine open
workloads became five.
The DNS pointer needed a step the design did not know about. The ConfigMap
is mounted optional, and when it does not exist at pod start the kubelet
does not fill it in later - CoreDNS kept reporting the missing import for
two and a half minutes. A restart was required, and with maxUnavailable 1
on a single replica a rollout restart would have meant a cluster-wide DNS
gap. Scaled to two instead, let the new pod load the zone, removed the old
one, scaled back. DNS was served at every moment.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F2Q4Ri8NGwyTZzScvKnWFM
Six deploy and helper workloads are restricted; the count of workloads
without a narrow rule went from fifteen to nine. The block is proven from
inside the pod - three truly external targets refused, CoreDNS answering as
the positive control - and the pod is distroless, so the probe ran in an
ephemeral container sharing its network namespace and labels. That is the
method the remaining waves need and it is written down rather than
rediscovered.
Rehearsing the rollback corrected a claim from Gate 2. "Flux makes a git
revert a rollback of minutes" holds only with an addition. The revert took
about forty seconds; restoring afterwards did nothing for four minutes,
although git.lab had the commit and the mirror reported finished. Only a
forced refetch of the GitRepository moved it.
So a rollback is a revert plus a nudge to the source. Someone who only
reverts and waits sees nothing for up to a poll interval and may conclude
the rollback itself is broken while it is merely slow. That belongs in the
record before a wave touches something users notice.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F2Q4Ri8NGwyTZzScvKnWFM
The owner pointed out that rohana is still reachable over the private
network and need not be called externally. Measured and correct: 10.0.0.3
answers as Gitea for the public host header and serves a valid Let's
Encrypt certificate for that very name, validated with full verification.
So the private path is not just reachable but TLS-clean, and no service
needs reconfiguring. What is missing is only the internal pointer - the
Corefile already imports the custom override directory, the ConfigMap
simply does not exist yet.
Two of the four class B workloads therefore stop leaving the cluster, and
the Gitea exception recorded in AGENTS.md becomes an internal rule. The
storage box stays external: no private path was named for it and I am not
assuming one.
The price is written into the design rather than skipped. An internal
pointer turns two paths into one - if 10.0.0.3 is down, rohana is
unreachable from the cluster although the public route would work, and the
failure would look like "Gitea is gone" instead of "the private path is
gone".
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F2Q4Ri8NGwyTZzScvKnWFM
Two findings from the preparation change the design.
There is no split-horizon DNS: every public name of the platform resolves
inside the cluster to the node's external address. Services that reach each
other by public name therefore leave the cluster and come back through
Traefik.
And traffic to the node's own address is not subject to the policy.
Measured twice, from two workloads restricted since the 20th, with
different tools: the storage box, rohana and 1.1.1.1 are all blocked, the
node address is reachable, and CoreDNS answers as the positive control. The
restriction works - just not against the node itself. That is a property of
the k3s enforcement, not a manifest error, and no NetworkPolicy can close
it, because policies allow rather than forbid.
It cuts both ways. Class A grows and gets safer, because services talking
over public names keep working under restriction. And the ten workloads
restricted yesterday can still reach anything published through Traefik -
the gap between what the manifest promises and what holds belongs written
down rather than smoothed over.
I also walked into the trap my own acceptance criterion warns about. The
first counter-probe used /dev/tcp in a container whose sh does not have it,
so everything came back "blocked", including the reachable node. Same
mistake as on the 20th, in the undertaking whose criterion 4 names it.
Repeated with nc and a positive control; only then was the result worth
anything.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F2Q4Ri8NGwyTZzScvKnWFM
Two constraints measured rather than assumed. k3s has no separate CNI or
policy pod, so enforcement is standard NetworkPolicy: CIDRs only, no DNS
names. And the cluster is single-stack IPv4 - a v6 connection attempt fails
with OSError - which matters more than it looks: had it spoken IPv6, every
IPv4-only rule would have been a gate that looks tidy and holds nothing.
The fifteen workloads fall into three classes: internal only, exactly one
pinnable target, and genuinely broad. The manifests do not yield the
targets - external addresses live in SOPS secrets and in the images - so
class B comes from resolved names instead.
ClamAV is the hard case and is not talked away. Its signature source
resolves to Cloudflare with rotating addresses. Pinning them breaks
silently at the next rotation - signatures age, the service keeps running,
nobody notices - which is the failure class this project built half its
checks against. Allowing Cloudflare's ranges would look like a restriction
and barely be one. So its egress stays, with the reason in the manifest,
and mirroring signatures internally is named as the later option.
Rolled out in three waves by risk rather than one commit, so a failure says
which service stumbled. The counter-proof will use Python from inside a
pod against a target that is demonstrably reachable with broad egress -
on the 20th both a service IP and /dev/tcp in a dash container produced a
false "blocked".
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F2Q4Ri8NGwyTZzScvKnWFM
Assigned by sorb. Size L: fifteen workloads, a real decision per service,
and mistakes land in production.
The acceptance criteria are counted in the running cluster rather than read
off the manifests - that distinction is what produced this undertaking in
the first place, since the issue's own remaining list was a week out of
date. Zero workloads without an egress rule, every exception naming where
and why with evidence that the service fails without it, a pre-agreed
smoke list, and a demonstration from inside a pod that a forbidden target
actually fails.
Non-goals name the temptations: no ingress changes, no new model or tool,
and no switching a feature off to save a rule. Synapse needs broad egress
for URL previews and already has the right control in
url_preview_ip_range_blacklist; disabling the feature would be the wrong
lever, as the issue has said since the 20th. flux-system is excluded too -
it pulls from the network and is the thing that rolls this change out, so
cutting its ground is a separate act with its own fallback.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F2Q4Ri8NGwyTZzScvKnWFM
All three rules evaluate healthy after the pull and reload, with the prefix
matcher active and the probe named in the message.
Healthy only means a rule can be evaluated, not that it sees anything, so
the series underneath were checked as well. The new cronjob has info and
created series but no last_schedule_time - a manual run does not set it and
the first scheduled one is 04.09. Without the "or kube_cronjob_created"
fallback the rule would stand on an expression with no series for this
probe and could never fire: green, healthy and blind.
Whoever wrote that fallback a week ago did it as a precaution. Today it
carries real weight for the first time, on a cronjob that did not exist
when it was written.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F2Q4Ri8NGwyTZzScvKnWFM
restore-drill-media, on the 4th at 05:20, an hour after the database
probe. The name is the alerting: BackupJobFailed already matches
restore-drill.*, so a failure needs no new rule and reaches the
maintenance room through the single alertmanager route.
Every link is measured rather than assumed. A control run with a
deliberately damaged file reported one mismatch and failed the job. The
job name was checked against the rule's regex. The route was read from the
config. And delivery works today: seven notifications sent, none failed,
alertmanager up.
The probe re-proves its own comparison on every run: after passing, it
alters one shared file by a byte and fails with "this probe proves
nothing" if the comparison stays quiet. That a comparison has only ever
said "equal" is a guess, and running monthly does not change it.
Silence is covered too - the stale and missing alarms now match the prefix
and name which probe is affected - but those two rule changes sit in
threadnet-operating and are not live: the operating stack does not pull by
itself, and Prometheus still serves the old expressions, measured through
its rules API. The failure alarm is unaffected and already armed. Written
down as open rather than reported as done.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F2Q4Ri8NGwyTZzScvKnWFM
The point named when #0030 was closed is done. A job in the cluster
extracted the newest archive into an emptyDir and compared it against the
production PVC mounted read-only: every one of the 309 files present in
both is byte-identical by sha256.
That is a stronger statement than the database drill makes. There it was
shown that rows arrive; here that the restored files are the running ones.
Three flaws in the test, all mine, and all written down. busybox find has
no -printf, so the byte counts came out as a silent zero beside real
numbers. The first run compared totals and counted every cache prune as a
mismatch, when the backup is a snapshot and production keeps running - the
intersection is what proves anything. And my exception knew url_cache but
not url_cache_thumbnails, so it reported a finding outside the cache that
was not one; the filter worked, its list did not.
Still unproven: the emergency path itself, copying back into the PVC. What
is proven is that the data come out of the archive complete and unaltered.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F2Q4Ri8NGwyTZzScvKnWFM
The subject of the issue was whether the backups were a guess. That was
settled on 14.08. with restored row counts rather than an assurance, and
the title has been wrong ever since. It also sat at in-progress for a week
without work. Third issue today with the same stale-head class.
Two things measured while closing, neither of them in the text:
restore-drill has never fired on schedule. lastScheduleTime is none - the
job was created on 14.08. and runs on the 4th, so the first automatic run
is 04.09. Only the manual run has passed. Every other cronjob in the
cluster shows a fresh timestamp; this one does not. Not a fault, but
"automated" and "proven" are not the same thing.
The Synapse media are backed up and the restore is untested. synapse-backup
mounts the PVC and archives /media/media_store - the run of 21.08. held 320
files and 216 MB, which would not add up without media. The way back is
written down and explicitly not automated, and nobody has walked it.
The homelab item is dropped rather than carried anywhere: the homelab is
not part of this project, and it should not have been listed as remaining
work in the first place.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F2Q4Ri8NGwyTZzScvKnWFM
Both issues described work that no longer exists. Without measuring, two
tasks would have entered planning half-done.
0083 is done. No single-file mount remains in the compose file; the running
exporter emits both metrics that only exist since the 19.08. change; and
the timing closes the chain - the mount commit carries 12:00Z while
Prometheus and Alertmanager have been up since 16:34Z and Loki since 17:08Z
the same day, so the redeploy came after the change. A "yes, it was rolled
out" would have claimed the same and proven nothing.
0088 stays, with a title that is no longer wrong. It said "13 ingress
rules, 1 egress", which was the state on 06.08.; measured today there are
ten workloads restricted to internal traffic and fifteen still open, not
the eleven the issue listed.
Measuring found more than it corrected. wikijs itself is unrestricted while
its database is, which nobody intended and nothing recorded. And the
namespaces authentik and monitoring carry only the metadata block, so their
egress is entirely open - that is not in the issue at all.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F2Q4Ri8NGwyTZzScvKnWFM
Size S owes no gates, but the ladder section is mandatory even when nothing
was built - an absent record and an ignored rule look identical.
"One ledger per session" does not quite hold here. This session's ledger
was closed at Gate 5 and then this task arrived. A second ledger
contradicts the wording; no ledger contradicts the sentence above it, that
every rule owes a trace or it is decoration. I chose the trace and wrote
the contradiction down rather than resolving it quietly: a session can hold
more than one finished run, and the concept currently knows only sessions.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F2Q4Ri8NGwyTZzScvKnWFM
Three task briefs lived only in a chat and in a home directory. They are
the only record of what was actually handed over, and therefore the only
basis on which a result can later be judged to match its request.
They land beside textbloecke.md rather than in a new directory: that page
already holds "short, copyable blocks you put in front of a session", and
these are the same idea at full length. Each carries its state at the top,
because a brief that reads as pending when it is done is the stale-head
failure this project keeps finding.
The third one exists for a reason worth stating: an agent judging its own
run justifies rather than checks, so that verdict must not be written by
the session that produced the run. And such a brief carries no findings of
the author's own - handing them over buys a confirmation instead of a
check, and then the separation is only cost.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F2Q4Ri8NGwyTZzScvKnWFM
Closing the run turned status to closed, and the judge - which checks a
closed ledger strictly and an open one loosely - reported fifteen findings
where it had reported none. All mine, in three classes: no ladder entry
carried the commit it became effective in, gate 4.4 carried no approval,
and the slices stood as gate rows although the template expects them in the
design document at size L ("size M records its slices").
The slice rows are removed, which touches existing rows that "appended,
never rewritten" protects. They should never have been there; the design
document has carried them with their commits all along.
Worth keeping, because it is the whole argument for the ledger: while the
run was open the record looked complete and was not. Only the act of
declaring it finished made the check strict enough to say otherwise.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F2Q4Ri8NGwyTZzScvKnWFM
Five statements this undertaking contradicts, named rather than left
standing. Two of them are in this document's own earlier gates: the Gate-2
mapping had FB-06 as open when the framework had split the item and closed
that half in v0.1.3, and had FB-09 and FB-11 as open when v0.3.0 covers
them partly. Both only surfaced because the states were checked against the
rule text of the tags instead of the issue status.
The third is FB-12's "point 3 is fixed", whose reasoning - the error is
forgetting, not doing it wrong - was falsified by the same task. That page
is revised rather than appended to, which is the practice this project
harvested and the framework shipped in v0.1.3.
Criterion 5 stays partly met. The deterministic half ran against both of
the day's ledgers without findings; the verdict artifact must not be
written here, because its own template holds that a verdict produced in the
working session is void whatever it says.
Moving the document one level deeper broke three relative links, which
validate.py caught before the commit. Same class as everything else today:
the tool saw what the plan did not.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F2Q4Ri8NGwyTZzScvKnWFM
The row was written in the same commit as the work, so it could not name
that commit's sha - the second time in this run. The parallel run shows the
order that works: the work commit first, then a commit for the ledger row.
That is what "rows are appended as gates close" means.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F2Q4Ri8NGwyTZzScvKnWFM
Slice 4.4. judge.py caught gate 4.3 naming no commit - the row was written
before the commit existed and the sha never filled in. Classified as model
failure, correctly: the rule is clear, the template says so, I did not do
it. Filled in, then clean. A fabricated sha is refused and fails closed.
Both ledgers of the day pass the deterministic half, including the parallel
run's, which this session did not write.
The verdict artifact is missing on purpose. Its own template says a verdict
produced in the working session is void whatever it says, and an agent
judging its own run justifies rather than checks. Acceptance criterion 5 is
therefore partly met, recorded as partly rather than ticked.
First rule-coverage measurement: 14 of 23 rules observable, nine not -
among them "every line traces to the request", "a check owes proof it can
fail" and "incidents get an AAR". Decoration until they carry a duty to
leave a trace. That is the claim this whole series started from, now a
number instead of a suspicion.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F2Q4Ri8NGwyTZzScvKnWFM
Slice 4.3. Every finding is now a stolpersteine page carrying its state,
and the mapping is discharged mechanically: twelve findings in the
register's last hand-maintained revision, twelve pages naming their origin,
zero unassigned.
The states were verified against the rule text of the tags, not derived
from issue status - and that turned up two errors in my own Gate-2 mapping.
FB-06 was listed as open; the framework had actually split the combined
item and closed that half as issue 0028 in v0.1.3, whose WORKFLOW.md
carries "Name what this work made false" verbatim. FB-09 and FB-11 were
listed as open too; v0.3.0 covers them partly through the ledger and the
ladder's trace duty, so they are `partly` with the version named.
Two are `declined`: the framework considered them and will not cover them,
so they remain ours. That state exists because writing `open` for a decided
matter is the failure class this undertaking exists to clear.
The texts are not edited. They came out of git at the register's last
revision and moved unchanged; only repo-relative links were rewritten,
because inline links resolve against the file.
Also done: the duplicated half of the ADR rule is gone from the project
section - permanent exceptions have been upstream since v0.1.2 - and three
descriptions that still called the register an inbox now describe the
pages, the generated overview and the signpost.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F2Q4Ri8NGwyTZzScvKnWFM
Slice 4.2. The receipt duty from ADR-0024 was built yesterday on the
premise that "the error is forgetting, not doing it wrong". The same
upgrade falsified that on the same day: the receipt for schema.yaml was
written, it is truthful, it names correctly what was carried over - and two
fields were lost anyway. Nobody forgot anything.
pruefe_upstream_drift.py now holds our schema.yaml structurally against the
baseline: every type, field, enum value and required entry the baseline
carries must exist here. Adding is allowed, losing is not. Checked
counterfactually against the real loss, which it reports.
For the two other extended files there is no equivalent - they are Python,
and no structural comparison exists. That half stays open and is written
down rather than glossed over.
Building it taught the check two things about itself. It broke the existing
selftest because that fixture wrote schema.yaml as prose - the same
unrealistic fixture FB-12 already records as having made an assertion
worthless for this very script. And my counter-control reported "nothing"
for the removed crash guard, because a crash returns the same exit code as
a failure; only checking for a traceback showed the script never reaches
its summary without it. Both times the control was blunt, not the check.
Sixteen assertions, six deliberate breaks, none uncovered.
The occasion is recorded for the next harvest as two stolpersteine pages -
the first use of the mechanism ADR-0009 decided: a receipt certifies
attention rather than completeness, and a file cannot be authoritative and
immutable at once.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F2Q4Ri8NGwyTZzScvKnWFM
Slice 1, the tracer bullet: schema, generator and one migrated page, so the
whole chain runs before eleven more depend on it.
Two fields were missing entirely. The v0.3.1 merge did not carry over
wiki-page's status and harvested_in, so the mechanism ADR-0009 decides was
not actually available here. A field-by-field comparison against the
vendored baseline found exactly those two and nothing else - the gap the
previous run predicted when it noted that reconciling the extended files is
a manual step with nothing to contradict it.
The generator gains a clustered section and writes the signpost; collect()
and apply_rules() already existed, so the change is a filter and a fifth
rule rather than a second reader or a new checker.
Running it corrected one of my own design errors immediately. The "without
state" group was written as a warning, and it flagged two perfectly correct
pages: status is optional per ADR-0009 and only meaningful on a page that
tracks a pattern. A permanent complaint with no subject trains people to
ignore the section, so the group is now neutral - with the downside written
into the code, since a pattern that lost its state now looks like an
ordinary page.
Eight controls, seven of them deliberate breaks: both generated files go
stale on a hand edit, an invented state value is refused, the new value is
accepted and clusters correctly, and harvested or declined without a named
version now fails.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F2Q4Ri8NGwyTZzScvKnWFM
The owner objected to the plan carrying two findings as "open" when the
framework has considered and declined them, on the grounds that the enum
has no better value. He is right: replacing a state the field cannot
express with a state that is wrong is the exact class this undertaking
exists to clear.
Extending is established practice here rather than an exception - the
extension block in schema.yaml already declares two enum extensions, and
ADR-0024 covers the file. The portability cost is near zero because these
pages never travel upstream: ADR-0008 sends generalized failure classes,
which carry no frontmatter.
The value is `declined`, not `rejected`. Our issue enum already uses
`rejected`, and matching vocabulary would be cheaper, but the meanings
diverge: a rejected issue is finished, while a declined pattern persists
and stays ours to live with. Anyone reading `rejected` would think the page
is disposable.
Measured while deciding where to document it: HERKUNFT.md cannot be
maintained at all. It sits under docs/sources/ and the lock check refuses a
test commit against it, while ADR-0024 declares its table authoritative and
requires it to stay in step with the pair list. A file cannot be both the
maintained truth and immutable. Recorded for the next harvest; an accepted
record is not repaired in passing.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F2Q4Ri8NGwyTZzScvKnWFM
Option A said FRAMEWORK-BEFUNDE.md would cease to exist as a file. It
cannot: ADR-0024 is accepted, links it twice, and an accepted record is
never edited. Deleting the file breaks validate.py at a line nobody is
allowed to repair.
Resolved without touching the record: the file stays as a generated
signpost of a few lines carrying no inventory of its own. The data live in
the pages, the overview in STATUS.md, and the file only says where both
are. Every reference stays valid and nothing can rot, because a signpost
holds nothing that could. It also means AGENTS.md needs exactly one change
- the duplicated rule - rather than two.
Eleven new pages, not twelve: FB-02 already owns one. collect() already
reads artifacts by directory and type, so the generator gains a filter
rather than a second reader.
The assertions that matter are the ones about absence: a page without a
state must show up as a finding rather than vanish, and harvested without
harvested_in must fail. The difference between "no state set" and "not
there" is the failure class this whole register was started for.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F2Q4Ri8NGwyTZzScvKnWFM
The owner's condition on approving Gate 1 was to check whether v0.3.1 is
already adopted before doing anything. It is, as far as the rules go: the
upstream part of AGENTS.md and all of WORKFLOW.md are byte-identical with
the vendored baseline, every new section is present, and the drift check
passes. What is not done is the content: no stolpersteine page carries a
harvest state, nothing generates the findings overview - neither our
gen_status.py nor the upstream one knows the concept - and judge.py is
wired nowhere.
Two ladder results worth keeping. The overview extends gen_status.py rather
than becoming a third generator. And FB-02 already owns its page, linked
from the register twice, so it gets a state instead of a duplicate.
The harvest state is now derivable instead of asserted: the upstream issues
carry it. Three of ours are done there, six open, and two were rejected
with reasons.
That last group exposes a gap in the state space. A pattern the framework
considered and turned down is neither open nor harvested, and the enum has
no third value. Carrying it as open asserts a process that no longer
exists - the very class FB-04 describes. Recorded as a finding for the next
harvest, not invented around here.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F2Q4Ri8NGwyTZzScvKnWFM
The undertaking was set up as the whole two-stage adoption and had to be
re-cut on measurement: a parallel run had already completed stage 1 the
same day and recorded it in its ledger. Gate 1 is therefore rewritten
rather than extended - a plan that announces work already done is the same
defect as an issue whose head asserts a diagnosis its appendices refuted.
What is left is the part that fails quietly if the adoption is treated as
finished. The twelve findings still live in a hand-maintained register,
while the framework's ADR-0009 gives them a home with a harvest state.
Four framework versions have shipped since they were handed over, so
"a released version covers this" is measurable for the first time - and
unmeasured. And judge.py is adopted but wired nowhere, with no verdict in
existence.
One decision from 2026-08-20 was deliberately reversed by that parallel
run, with approval and a ladder entry: upstream's check_locked.py was not
adopted because ours does the same job and only had a defect, which was
fixed. Not re-litigated here.
This run keeps a ledger, as now required. It records both the re-cut and a
working-tree contamination during the survey.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F2Q4Ri8NGwyTZzScvKnWFM
FB-12 point 3: the declared-extended files are deliberately outside the
byte comparison, so nothing reported when upstream changed them. Two of
three were touched between v0.1.1 and v0.3.1 and it only surfaced because
someone thought of it.
Two checks added to the script that already owns the subject, rather than
a second script beside it:
* completeness — every vendored file belongs to exactly one class.
check_harvest.py and judge.py were adopted byte-for-byte during the
upgrade and never entered the pair list; nothing compared them.
* reconciliation — if upstream touched an extended file between the
previous and the current baseline, ABGLEICH.tsv of the new baseline
must acknowledge it.
The acknowledgement lives in its own file on purpose. The first draft
searched HERKUNFT.md's prose for the filename, which is always there in
the inventory table: strict-looking and inert. Its selftest missed that
because the fixture was an unrealistically empty note; the counterfactual
against real history caught it.
Ten assertions, twelve deliberate breaks, none uncovered. Two of the
breaks exposed two useless assertions.
AGENTS.md requires an ADR for every permanent exception: documenting one
instead of deciding it is an error. schema.yaml, validate.py and
gen_status.py have diverged from the vendored baseline since the
migration on 2026-08-11, described in two places and decided in none.
FB-12 named the gap during the v0.3.1 upgrade.
A prefix comparison was measured and rejected: unlike AGENTS.md, these
extensions are interleaved — component sits between issue and wiki-page,
the two rules sit inside apply_rules, and gen_status replaces the issue
table rather than appending to it.
The honest price is in the consequences: the reconciliation on upgrade
has no machine contradictor. Measured on this very case — upstream
touched two of the three between v0.1.1 and v0.3.1 and nothing reported
it.
The baseline moved v0.1.1 to v0.3.1 on 2026-08-21, the first real run of
a procedure that had been considered settled since v0.1.2. It failed at
three places: WORKFLOW.md could not be copied byte-for-byte because it
links to the framework's own decision records; pruefe_sperrliste forbade
the upgrade itself, unable to tell an addition under docs/sources from a
change; and the three declared-extended files had to be reconciled by
hand because nothing reports that upstream touched them.
One root cause: the procedure was described and never executed. Two of
the three are fixed, the third is open — which is FB-11 on a new subject.
Our own positive-control rule, not applied: the adoption question was
closed on the description of a procedure. Nobody ran it.
pruefe_sperrliste read --name-only, so it could not tell a modified
source from a newly added one and flagged both. That made a framework
upgrade impossible by construction: an upgrade must place a new baseline
under docs/sources/upstream/, and the lock rejected exactly that.
Upstream's check_locked.py draws the same line and asserts it ('adding a
new source is not an edit'). Modification and deletion stay locked.
Three minor releases at once. Byte-identical surface: only WORKFLOW.md
actually changed (+128/-2); CLAUDE.md and the four templates are
untouched. AGENTS.md takes the new upstream prefix (+22/-2) and keeps our
project section unchanged.
The two declared-extended files were reconciled by hand, because nothing
compares them: validate.py gains upstream's check_vendored_portable, and
schema.yaml gains vendored, project_section_marker, the judged link field
and the ledger and verdict types. gen_status.py needed nothing — upstream
did not touch it. Recorded in the new HERKUNFT.md, including that this
reconciliation has no contradictor and will be forgotten next time.
Newly adopted: check_harvest.py and judge.py, plus docs/ledger/ and
docs/verdict/ with their templates. Deliberately not adopted:
check_locked.py — pruefe_sperrliste.py has done that job here since
2026-08-20, and two tools for one rule is maintenance without gain.
The v0.1.1 baseline stays where it is; docs/sources is immutable.
The list of names that must never leave in a harvest lives here rather
than in the framework: the framework must not store the names it exists to
keep out. That placement is the framework's own decision (its ADR-0008),
and this file is our side of it.
Two rules carry the reasoning, both learned expensively. A term the
framework itself uses is shared vocabulary and belongs off the list -
listing it produces noise, and noise teaches people to skip the check. And
a green run proves nothing about absence: a denylist finds only what
somebody thought of, which is exactly the confusion behind the near-leak
of 2026-08-13.
All eleven findings were handed over on 2026-08-20 as nine issues of the
next framework iteration. They stay open here regardless: handed over is
not harvested, and by this file's own rule a finding only counts once the
next iteration actually covers it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F2Q4Ri8NGwyTZzScvKnWFM
Size class and closing status are carried from now on. That settles the
behavioural half only: it was already the rule before, so what changed is
attention, not mechanism. FB-01 shows how long attention alone holds, so
the finding stays open.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F2Q4Ri8NGwyTZzScvKnWFM
Thore Cimbal
