ByteFleet Ship-Preflight

Finaler Kandidat: 00f87b673ade95c32d02ba010599d1c2d2075637

Problem und Ergebnis

Skill-Texte enthielten eine personenbezogene Bezeichnung, und der PR-Workflow erzeugte einen ausführlichen Preflight-Nachweis, obwohl bei erfolgreichen Prüfungen keine Dokumentation gewünscht ist.

Personen werden jetzt nur noch generisch als „User“ bezeichnet. Der PR-Skill prüft weiterhin vollständig, bleibt bei Erfolg still, erzeugt standardmäßig keinen separaten Nachweis und fragt nur bei einem ungelösten Fehler oder einer notwendigen Entscheidung.

Finale Sicherheitskorrekturen

Die Skill-Beschreibung bleibt kurz und schließt reines PR-Monitoring, Merge, Release und Deployment klar aus.
Veröffentlichte PR-Inhalte müssen Secrets, private URLs und lokale Pfade entfernen.
Nur ein ausdrücklich gestarteter Ship-Ablauf verlinkt bereits genehmigte Schaffa-Evidence; der normale PR-Skill erstellt sie nicht.

Ziel und Umfang

Branch: main
Delivery-Ziel: Bestehender, abgesicherter ByteFleet-Canary
Änderungsumfang: PR- und Ship-Skill-Regeln sowie die zugehörigen Baseline-Tests
Nicht betroffen: Fleet-Zuweisungen, Control-Plane-Verhalten und Rollout-Konfiguration

Prüfstatus

Format/Lint, TypeScript, 38 Tests, Produktions-Build, beide Skill-Validatoren und Secret-Scans sind erfolgreich. Die unabhängige Opus-Prüfung des finalen Kandidaten meldet keine offenen Befunde.

Es gibt keine sichtbare UI-Änderung; Screenshots würden keinen zusätzlichen Nachweis liefern.

Risiko und Rückweg

Das Risiko ist auf die Formulierung der beiden Delivery-Skills begrenzt. Falls sich das neue Verhalten als falsch erweist, kann der einzelne Kandidaten-Commit zurückgenommen und der Canary wieder auf den vorherigen, bereits gesunden Stand synchronisiert werden.

Weg nach Freigabe

Kandidaten-Commit nach main übertragen.
Forgejo-Qualitäts- und Image-Jobs bis zum grünen Endzustand beobachten.
Den bestehenden Canary auf den genehmigten SHA synchronisieren.
Agent-Status, verwaltete Skill-Links und ByteFleet Doctor abschließend prüfen.