Mass-Update-Gate-Schwelle gegen beobachtete Publish-Verteilung neu ansehen #53

New Issue

2026-09-04T18:30:05Z

torben commented

2026-09-04 18:30:05 +00:00

Befund

Analyse der Telemetrie unter reports/telemetry/ (568 Sessions, 27.08.–04.09.2026, 117
publish.commit-Events, 193 publish-Aufrufe insgesamt):

Kennzahl	Wert
`publish`-Aufrufe mit Exit 42 (mass-update, needs-clearance)	62 von 193 = 32 %
Median geänderter Dateien je `publish.commit`	9
Aktuelle Schwelle (`gate.cleared` → `threshold`)	10
`publish.commit` mit >10 Dateien	46 von 117 (39 %)
Sessions mit ≥1 mass-update-Refusal	53
davon mit einer nachfolgenden `gate.cleared` in derselben Session	28
davon ohne jede nachfolgende Clearance	25

Der Median-Publish liegt praktisch auf der Schwelle. Das ist keine Fehlfunktion - das Gate tut
genau das, wofür es gebaut ist (instructions/gates.md § Mass-Update Gate), und alle 62
Refusals sind sauber: kein Fall von Selbstöffnung, kein --yes/-y, kein Confirm ohne
vorherige Refusal (siehe die gate-not-self-opened- und clearance-was-asked-for-Regeln, die
über diese Traces ok laufen, #52 ausgenommen). Die Frage ist nicht Korrektheit, sondern ob
die Schwelle noch die Größe beschreibt, die tatsächlich „zu groß zum ungeprüften Publizieren"
bedeutet, oder ob sie mittlerweile die normale Publish-Größe dieses Corpus ist.

Warum das für den Produktivbetrieb relevant ist

Diese Traces stammen überwiegend aus Stack-Entwicklung und Korpus-Migrationen
(link-taxonomy-migration/*, publish-cleanup/*) - beides Arbeit mit naturgemäß vielen
betroffenen Dateien. Ein produktiver wiki-ingest/wiki-manage-Alltag mit einem gewachsenen
Korpus (mehr Seiten, mehr Querverweise pro Seite) dürfte eher öfter als seltener über die
Schwelle laufen, nicht seltener. Eine Schwelle, die schon jetzt am Median liegt, wird mit
wachsendem Korpus zur Regel statt zur Ausnahme - und ein Gate, das bei jedem zweiten Publish
auslöst, verliert die Aufmerksamkeitswirkung, für die es gebaut ist (vgl. das gehäufte
Anrennen in #52).

25 von 53 refused Sessions ohne jede Clearance ist der zweite Punkt: das kann heißen, dass
die Klärung in einer späteren Session nachgeholt wurde (Sessions sind hier granular, teils pro
Arbeitseinheit - link-taxonomy-migration/u1, /u2, /u3 ...), oder dass ein Teil dieser
Changesets nie publiziert wurde. Die Traces allein beantworten das nicht; kb/log.md und die
Commit-Historie müssten gegengeprüft werden.

Nicht Gegenstand dieses Issues

Ob 10 die richtige Zahl ist, ist eine Betreiberentscheidung (kind/decision), keine, die eine
Sitzung selbst treffen soll - siehe AGENTS.md Invariante 6 sinngemäß auf Gate-Parameter
angewandt: die Schwelle selbst ist im Tool eine Konstante, kein Wert, den ein Agent verändert,
ohne dass der Nutzer sie gesehen hat.

Vorschlag für die Klärung

Vor einer Entscheidung: die 25 ungeklärten Refusal-Sessions gegen git log/kb/log.md
gegenprüfen - wie viele davon sind tatsächlich versandet vs. in einer Folge-Session geklärt.
Wenn die Schwelle angehoben wird: mit Begründung, welche Publish-Größe für diesen Korpus
(nicht für Stack-Entwicklung) noch prüfbar bleibt - die 46 großen publish.commits stammen
fast ausschließlich aus Migrationen, nicht aus Alltags-Ingest.
Alternative zur Anhebung: --path <dir> (bereits vorhanden, siehe instructions/gates.md)
als Standardempfehlung in den Skills verankern, um große Changesets in reviewbare Batches zu
zerlegen, statt die Schwelle selbst zu bewegen.

Herkunft

Aufgefallen beim abschließenden Review vor dem produktiven Einsatz des Stacks (Sitzung
2026-09-04) bei einer Telemetrie-Analyse über reports/telemetry/. Verwandter Fund derselben
Analyse: #52.

## Befund Analyse der Telemetrie unter `reports/telemetry/` (568 Sessions, 27.08.–04.09.2026, 117 `publish.commit`-Events, 193 `publish`-Aufrufe insgesamt): | Kennzahl | Wert | |---|---| | `publish`-Aufrufe mit Exit 42 (mass-update, needs-clearance) | 62 von 193 = **32 %** | | Median geänderter Dateien je `publish.commit` | **9** | | Aktuelle Schwelle (`gate.cleared` → `threshold`) | **10** | | `publish.commit` mit >10 Dateien | 46 von 117 (39 %) | | Sessions mit ≥1 mass-update-Refusal | 53 | | davon mit einer nachfolgenden `gate.cleared` in derselben Session | 28 | | **davon ohne jede nachfolgende Clearance** | **25** | Der Median-Publish liegt praktisch auf der Schwelle. Das ist keine Fehlfunktion - das Gate tut genau das, wofür es gebaut ist (`instructions/gates.md` § Mass-Update Gate), und alle 62 Refusals sind sauber: kein Fall von Selbstöffnung, kein `--yes`/`-y`, kein Confirm ohne vorherige Refusal (siehe die `gate-not-self-opened`- und `clearance-was-asked-for`-Regeln, die über diese Traces `ok` laufen, #52 ausgenommen). Die Frage ist nicht Korrektheit, sondern ob die Schwelle noch die Größe beschreibt, die tatsächlich „zu groß zum ungeprüften Publizieren" bedeutet, oder ob sie mittlerweile die *normale* Publish-Größe dieses Corpus ist. ## Warum das für den Produktivbetrieb relevant ist Diese Traces stammen überwiegend aus Stack-Entwicklung und Korpus-Migrationen (`link-taxonomy-migration/*`, `publish-cleanup/*`) - beides Arbeit mit naturgemäß vielen betroffenen Dateien. Ein produktiver `wiki-ingest`/`wiki-manage`-Alltag mit einem gewachsenen Korpus (mehr Seiten, mehr Querverweise pro Seite) dürfte eher öfter als seltener über die Schwelle laufen, nicht seltener. Eine Schwelle, die schon jetzt am Median liegt, wird mit wachsendem Korpus zur Regel statt zur Ausnahme - und ein Gate, das bei jedem zweiten Publish auslöst, verliert die Aufmerksamkeitswirkung, für die es gebaut ist (vgl. das gehäufte Anrennen in #52). **25 von 53 refused Sessions ohne jede Clearance** ist der zweite Punkt: das kann heißen, dass die Klärung in einer späteren Session nachgeholt wurde (Sessions sind hier granular, teils pro Arbeitseinheit - `link-taxonomy-migration/u1`, `/u2`, `/u3` ...), oder dass ein Teil dieser Changesets nie publiziert wurde. Die Traces allein beantworten das nicht; `kb/log.md` und die Commit-Historie müssten gegengeprüft werden. ## Nicht Gegenstand dieses Issues Ob 10 die richtige Zahl ist, ist eine Betreiberentscheidung (`kind/decision`), keine, die eine Sitzung selbst treffen soll - siehe AGENTS.md Invariante 6 sinngemäß auf Gate-Parameter angewandt: die Schwelle selbst ist im Tool eine Konstante, kein Wert, den ein Agent verändert, ohne dass der Nutzer sie gesehen hat. ## Vorschlag für die Klärung - Vor einer Entscheidung: die 25 ungeklärten Refusal-Sessions gegen `git log`/`kb/log.md` gegenprüfen - wie viele davon sind tatsächlich versandet vs. in einer Folge-Session geklärt. - Wenn die Schwelle angehoben wird: mit Begründung, welche Publish-Größe für *diesen* Korpus (nicht für Stack-Entwicklung) noch prüfbar bleibt - die 46 großen `publish.commit`s stammen fast ausschließlich aus Migrationen, nicht aus Alltags-Ingest. - Alternative zur Anhebung: `--path <dir>` (bereits vorhanden, siehe `instructions/gates.md`) als Standardempfehlung in den Skills verankern, um große Changesets in reviewbare Batches zu zerlegen, statt die Schwelle selbst zu bewegen. ## Herkunft Aufgefallen beim abschließenden Review vor dem produktiven Einsatz des Stacks (Sitzung 2026-09-04) bei einer Telemetrie-Analyse über `reports/telemetry/`. Verwandter Fund derselben Analyse: #52.