`job list` + `job trigger` — Faelligkeits-Jobs von Hand starten
Ein Eintrag der worker-automatic-checks-Registrierung war bis hierher NUR
startbar, indem man den Auftrag direkt in die BullMQ-Warteschlange schrieb —
genau der manuelle Eingriff, den die Tooling-first-Regel ausschliessen soll.
Die Route POST /jobs/:name/actions/trigger existierte, war aber von keinem
Werkzeug erreichbar: `ay` weist operator-only-Module ab, MCP sperrt jede
Nicht-GET-Methode in Produktion, `ayauto su` kann nur get/set auf EINEN
Datensatz. Form uebernommen von `su`/`queue`: benannter Eintrag, kein
Platzhalter, confirm-gated.
🔴 DER TRAGENDE BEFUND: die ausgelieferte Registrierung verschweigt
`defaultData`. Gemessen am laufenden Dienst enthaelt GET /jobs die Zeichenkette
null-mal, waehrend optionsSchema und queueName da sind (Positiv-Kontrolle) —
`serializeRegistry` gibt das Feld schlicht nicht aus. Zugleich reicht die
Ausloese-Route den Rumpf WOERTLICH als Auftragsdaten durch. Ein Hand-Start ohne
Nutzlast stellt also {}; ein Verbraucher, der auf `op` besteht, weist ihn ab —
und der Aufruf sieht trotzdem wie ein Erfolg aus (200 mit Auftrags-Kennung).
Genau das beschreibt der Eintrag HR_BENEFIT_RECEIPTS_MONTHLY woertlich.
Deshalb liest `job trigger` `defaultData` ZUSAETZLICH aus dem Arbeitsbaum und
zeigt es im Trockenlauf — ausdruecklich als Hinweis aus der QUELLE, nicht aus
der ausgelieferten Registrierung. Gesendet wird es nur mit --use-local-default.
Erfunden wird NIE etwas: ohne Angabe geht {} hinaus, und der Trockenlauf sagt,
was das bedeutet.
Der Extrakt hat zwei Riegel, beide mit eigener Probe: Zeilen-Kommentare werden
entfernt (der Quelltext WARNT an mehreren Stellen mit dem Wortlaut
`defaultData: { dryRun: false }` davor, es nachzutragen) und Zeichenketten
werden laengentreu maskiert (die Beschreibungen SPRECHEN ueber defaultData und
op). Echt-Abgleich gegen die Registrierung: 22 Vorkommen in der Quelle, 22 vom
Extrakt gefunden.
Optionen werden gegen das optionsSchema des Eintrags geprueft — ein vertippter
Schluessel wird abgewiesen samt Nennung der gueltigen, statt still zu
verpuffen. Ein erfundener Job-Name und ein `enabled: false`-Eintrag werden
abgewiesen, ohne etwas einzureihen.
23 Proben mit Umkehr- und Positiv-Kontrollen, gruen; Bau gruen.
Abnahme am laufenden Dienst: Trockenlauf zeigt den vollen Auftrag inkl. op ·
erfundene Option/erfundener Name je Exit 2 ohne Einreihung · echter Start von
check-all-health lief DURCH (recent-runs: manual:true, active→completed,
4621 ms), die Nachbarzeile desselben Takts traegt manual:false.
OFFEN: der saubere Rueckweg ist eine Zeile in serializeRegistry
(`defaultData: d.defaultData`) — sie liegt in domains/monitoring/
worker-automatic-checks, ausserhalb der beanspruchten Pfade, und ist als
eigener Vorgang erfasst.
startbar, indem man den Auftrag direkt in die BullMQ-Warteschlange schrieb —
genau der manuelle Eingriff, den die Tooling-first-Regel ausschliessen soll.
Die Route POST /jobs/:name/actions/trigger existierte, war aber von keinem
Werkzeug erreichbar: `ay` weist operator-only-Module ab, MCP sperrt jede
Nicht-GET-Methode in Produktion, `ayauto su` kann nur get/set auf EINEN
Datensatz. Form uebernommen von `su`/`queue`: benannter Eintrag, kein
Platzhalter, confirm-gated.
🔴 DER TRAGENDE BEFUND: die ausgelieferte Registrierung verschweigt
`defaultData`. Gemessen am laufenden Dienst enthaelt GET /jobs die Zeichenkette
null-mal, waehrend optionsSchema und queueName da sind (Positiv-Kontrolle) —
`serializeRegistry` gibt das Feld schlicht nicht aus. Zugleich reicht die
Ausloese-Route den Rumpf WOERTLICH als Auftragsdaten durch. Ein Hand-Start ohne
Nutzlast stellt also {}; ein Verbraucher, der auf `op` besteht, weist ihn ab —
und der Aufruf sieht trotzdem wie ein Erfolg aus (200 mit Auftrags-Kennung).
Genau das beschreibt der Eintrag HR_BENEFIT_RECEIPTS_MONTHLY woertlich.
Deshalb liest `job trigger` `defaultData` ZUSAETZLICH aus dem Arbeitsbaum und
zeigt es im Trockenlauf — ausdruecklich als Hinweis aus der QUELLE, nicht aus
der ausgelieferten Registrierung. Gesendet wird es nur mit --use-local-default.
Erfunden wird NIE etwas: ohne Angabe geht {} hinaus, und der Trockenlauf sagt,
was das bedeutet.
Der Extrakt hat zwei Riegel, beide mit eigener Probe: Zeilen-Kommentare werden
entfernt (der Quelltext WARNT an mehreren Stellen mit dem Wortlaut
`defaultData: { dryRun: false }` davor, es nachzutragen) und Zeichenketten
werden laengentreu maskiert (die Beschreibungen SPRECHEN ueber defaultData und
op). Echt-Abgleich gegen die Registrierung: 22 Vorkommen in der Quelle, 22 vom
Extrakt gefunden.
Optionen werden gegen das optionsSchema des Eintrags geprueft — ein vertippter
Schluessel wird abgewiesen samt Nennung der gueltigen, statt still zu
verpuffen. Ein erfundener Job-Name und ein `enabled: false`-Eintrag werden
abgewiesen, ohne etwas einzureihen.
23 Proben mit Umkehr- und Positiv-Kontrollen, gruen; Bau gruen.
Abnahme am laufenden Dienst: Trockenlauf zeigt den vollen Auftrag inkl. op ·
erfundene Option/erfundener Name je Exit 2 ohne Einreihung · echter Start von
check-all-health lief DURCH (recent-runs: manual:true, active→completed,
4621 ms), die Nachbarzeile desselben Takts traegt manual:false.
OFFEN: der saubere Rueckweg ist eine Zeile in serializeRegistry
(`defaultData: d.defaultData`) — sie liegt in domains/monitoring/
worker-automatic-checks, ausserhalb der beanspruchten Pfade, und ist als
eigener Vorgang erfasst.