Commit Graph
4 Commits
Author SHA1 Message Date
Thore CimbalandClaude Opus 5 84e87238f6 fix(pruefungen): acknowledge the reworded wiki finding, record what the run taught
The first CI run after the acknowledgement list went in was still red, so the
"all three green" line in #0104 was premature and is corrected rather than left
standing.

Two things it showed. Disabling the wiki mirror changed the finding's wording from
"Mirror wiki: counterpart unreadable" to "wiki: no active push mirror", and since
acknowledgements match on substrings, the entry no longer applied. Added. That is
the cost of a list readable without special knowledge: fix or move a cause and the
acknowledgement has to follow, otherwise it goes red - correctly.

The second finding, management mirror divergence, is deliberately NOT acknowledged.
It appears on any run starting minutes after a push because the mirror lags, and
acknowledging it is tempting - but that same message is the only signal if a mirror
ever really stops (#0028). It stays sharp; a run right after a push is briefly red.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-18 12:00:00 +00:00
Thore CimbalandClaude Opus 5 5e62408a72 fix(wiki): disable the backwards push mirror, park the rest until the end
Decision sorb. The mirror from axion1337.chat/wiki to sorb/wiki is off. It pointed
the wrong way: per ADR-0015 Wiki.js writes to sorb/wiki from the cluster and
canonize_wiki pulls it back to git.lab, so this mirror would have overwritten the
wiki content with git.lab's state. It had never run once - status none, no error -
which was luck rather than design.

Whether the wiki project stays at all is deliberately not decided now. sorb wants
that conversation immediately before project completion, once production readiness
is reached on everything else, so #0105 carries it as waiting with that as its
stated reason rather than as an open task somebody might pick up.

The group check's finding is acknowledged until 2026-12-31 rather than permanently.
A permanent acknowledgement would need an ADR, and writing that ADR is exactly the
decision being postponed; a date instead means that if the project outlives it, the
question asks itself again.

Both scheduled checks now reach zero open findings.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-18 12:00:00 +00:00
Thore CimbalandClaude Opus 5 7dfc9b0562 feat(pruefungen): acknowledge the deferred history-pass findings (#0053)
The group check carried 17 commit-hygiene findings that sorb deliberately deferred
to the history pass, plus two known items. Acknowledged until 2026-11-30, which
takes the check from 20 open findings to one.

Each commit is acknowledged by its own SHA rather than by a pattern. A rule like
": Echtzeit-Stempel" would have been one line instead of seventeen and would have
swallowed every future violation with it - the blind spot this whole mechanism
exists to avoid. As a side effect the entries clean themselves up: once the history
is rewritten they match nothing and report themselves for removal.

What remains open in both checks is the same single real finding, and it is new:
the GitLab project "wiki" is undeclared, and its push mirror to sorb/wiki has never
run once - status none, no error, no successful update. Per ADR-0015 that direction
is wrong: Wiki.js writes to sorb/wiki from the cluster and canonize_wiki pulls it
back to git.lab. Had this mirror ever fired it would have overwritten the wiki
content with git.lab's state. It stays red on purpose, because it needs a decision.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-18 12:00:00 +00:00
Thore CimbalandClaude Opus 5 61b0540525 feat(pruefungen): acknowledge known findings so red means something again (#0104)
All three scheduled checks were permanently red, which is how a nine-day outage of
the canonize job went unnoticed: one more red cross among red crosses is invisible.
A check that can only ever be red cannot report anything.

An acknowledgement takes a known finding out of the red verdict without hiding it -
it still prints, with its reason and its deadline. Red is reserved for what is not
acknowledged, which is to say: for the new.

Three rules keep the list from becoming the next blind spot, which is the obvious
objection to this whole idea:

- Every entry needs a deadline. Once it passes, the entry stops acknowledging and
  says so, so the finding counts again.
- "Permanent" is only expressible as an ADR reference. A permanent exception
  without a decision record is already an error per AGENTS.md; here it cannot even
  be written down.
- An entry that matches nothing reports itself, so the file cannot quietly
  accumulate lines for problems that no longer exist.

Four entries to start: notfallhandbuch (ADR-0016, deliberately unmirrored),
threadnet-wiki (ADR-0015, the wiki mirrors the other way round), gameserver (sorb:
not part of ThreadNet - dated, so the ADR-or-move decision does not drift), and the
zero-job pipeline artifact.

Verified rather than argued, including the counter-proofs #0104 asks for: today
four are acknowledged and one real finding stays red; adding a fresh finding still
turns it red; and with the clock moved past the deadlines the dated entries stop
acknowledging and report themselves. The scope column was added after the first run
showed each check reporting the other's entries as ineffective.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-18 12:00:00 +00:00