Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 18 additions & 2 deletions KNOWN_ISSUES.md
Original file line number Diff line number Diff line change
Expand Up @@ -40,7 +40,7 @@ vorkommen — die Einstufung „nur Linux" heißt genau das und ist per
| KI-24 | SQLite-Lastklasse: einzelne Store-Tests scheiterten unter paralleler Last mit `database is locked (code: 5)` bzw. `pool timed out` — `store::continuous::tests::stale_fence_cannot_complete_claim_and_expiry_does_not_reclaim` (Linux, Run 35288206709 auf `main` @ `4e409d9`, 17.09.) und `workers::tests::an_agent_that_exits_during_respawn_is_not_revived_as_running` (Linux, Run 35025975338, 15.09.) | niedrig (bearbeitet, beobachten) | Aus `STAND.md` übernommen 2026-09-24. **Bearbeitet** mit W1-25 (PR #77: Transaktionen schließen, Pool-Frist) und W1-25b (PR #85: Store-Schreiber gegen fremde Schreiber). Nicht reproduziert ist der ursprüngliche Drop-Wettlauf (`.pa/report_w1-25.md`, „Nicht abgedeckt"). Der frühere `delivery_recovery`-Fall ist mit W1-04 (PR #55, 20/20 unter Last) abgenommen. Tritt einer der Tests wieder auf, ist das ein neuer Befund mit Run-ID, kein „Flake". **Nachgeführt 2026-10-02 (KI-OBS): tritt wieder auf, offen.** Suche über 301 abgeschlossene CI-Läufe vom 25.09. bis 02.10. (50 rot, alle per `gh run view --log-failed` auf `database is locked` / `pool timed out` und die Testnamen geprüft): die beiden in diesem Eintrag genannten Tests scheiterten nicht erneut, aber die Lastklasse trat zweimal auf der Windows-Bahn von `main` auf, mit anderen Tests: Run 36165944208 (25.09., `main` @ `a18dcd6`; `api::tests::review_route_maps_store_refusals_and_replays_at_the_seam` und `review_route_takes_the_reviewer_run_from_the_credential_not_the_body`, `api.rs:4775`: „failed to reopen migrated database … (code: 5) database is locked“, in beiden Versuchen) und Run 36215024767 (26.09., `main` @ `da20f22`; `store::development_launches::tests::schema15_upgrade_keeps_old_launch_identity_without_inventing_baseline`, `development_launches.rs:705`: „failed to open …projecta.db … (code: 5) database is locked“, in beiden Versuchen). Beide Stellen öffnen eine Test-DB erneut, die kurz vorher geschlossen wurde; das sieht nach dem Windows-Dateisperr-Fenster aus, ist aber nicht gemessen. Neuer Befund mit Run-ID, wie oben vorgesehen; Paketkandidat für die Store-Lane. |
| KI-28 | Der Capture-Host (`bin/pa-capture-host.rs`) läuft nur unter Windows | — (dokumentierte Grenze) | Entscheidung 16.09. (W3-05, `docs/decisions.md`; `pa-capture-host.rs:142`). Aus `STAND.md` übernommen 2026-09-24. Die frühere Einschränkung „acht native Tests laufen in CI nie" gilt nicht mehr: W3-06 (PR #75) fährt sie im Gate `native-tests` der Windows-Bahn. Linux-CI prüft nur die Kompilation. |
| KI-29 | F-SEC-4, Restrisiko des OmniRoute-Schlüssel-Syncs: wer den Opt-in einschaltet, schickt die Vault-Schlüssel an den Listener auf dem OmniRoute-Port, ohne dessen Identität zu prüfen | niedrig (bewusst in Kauf genommen) | Default ist seit W1-24 (PR #62) „kein Push"; W1-24b (PR #98) hat daraus ein ausdrückliches Opt-in-Setting gemacht, das im UI das Restrisiko benennt (`.pa/report_w1-24b.md`, „Hinweise und Folgearbeiten"). Eine Listener-Identität gibt es nicht: `/api/version` bräche Builds, die es weglassen, und ein Management-Token als Bearer gäbe es einem Horcher mit (PLAN, frühere Entscheidung Nr. 13). Solange der Sync aus bleibt, besteht kein Risiko. Paket W1-24c. |
| KI-30 | Windows-Gate `native-tests`: vier der acht `real_native_*`-Tests scheitern sporadisch in Merge-Queue-Läufen, jedes Mal nach grüner `rust-suite` | mittel (Flake, blockiert die Queue) | Stand 2026-10-05 (V16-01): Ursache für den Early-Exit-Fall belegt und behoben, die serielle Minderung ist entfernt. Offen bleibt der Beleg über die nächsten 40 Queue-Läufe und die Ursache der übrigen drei Tests. Details im Abschnitt „KI-30“ unten. |
| KI-30 | Windows-Gate `native-tests`: vier der acht `real_native_*`-Tests scheitern sporadisch in Merge-Queue-Läufen, jedes Mal nach grüner `rust-suite` | geschlossen 2026-10-09 (KI-30-CLOSE): 42 abgeschlossene Queue-Läufe, kein `real_native_*`-Fehler | Beleg und Methode im Abschnitt „KI-30“ unten (Schluss). 1 non-KI-30 failure (run 37910399142, goal_task_audit_control_uses_one_connection), already fixed by #843. Tritt ein `real_native_*`-Test wieder rot auf, ist das ein neuer Befund. |

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Halte KI-30 bis zur kanonischen Plan-Abnahme offen

Am geprüften Head führt docs/PLAN.md:292 den 40-Läufe-Nachweis noch als laufend; docs/PLAN.md:303-306 verlangt ausdrücklich, das bestehende Beobachtungsfenster nicht neu zu starten und KI-30 nicht vorzeitig zu schließen. Diese Zeile erklärt KI-30 dagegen anhand eines erst nach #737 beginnenden Fensters für geschlossen. Damit widerspricht der Status der einzigen kanonischen Planung und kann den Release-Vorgänger fälschlich als erfüllt erscheinen lassen; KI-30 sollte offen bleiben, bis der Plan durch den zuständigen Owner synchronisiert und die dortige Abnahme erfüllt wurde.

AGENTS.md reference: AGENTS.md:L53-L56

Useful? React with 👍 / 👎.

| KI-31 | In-App-Update aus einem main-Build blockiert den nächsten Start (`update-recovery.json`, `IdentityMismatch`) | hoch (Release-Blocker R-1; Journal-Pfad behoben, siehe Stand) | Nach einem echten Update vergleicht die Startprüfung den Hash der laufenden exe mit dem Hash des Update-Pakets und den Datenbank-Snapshot-Hash mit der Live-Datenbank; beides passt nach dem Update nicht mehr, die App startet nicht. Befund aus PR #457 und Berater Fable 5.1 (05.10.). **Workaround:** kein In-App-Update aus main-Builds vor W3-02j; die Datei `update-recovery.json` im App-Datenordner zu entfernen löst den Block. **Stand 2026-10-05:** für Updates, die über den Journal-Pfad installiert werden, behoben durch W3-02j (PR #462, Trust-on-first-run-Handshake: die Startprüfung übernimmt exe- und Datenbank-Identität als Erbe des Journals). **Offen:** ein echter Lauf „Update installieren und neu starten“ auf dem Windows-PC ist nicht belegt; Updates, die nicht über den Journal-Pfad installiert wurden, deckt der Fix nicht ab. Der Workaround gilt bis dahin für diese Fälle. |

## Behoben
Expand Down Expand Up @@ -251,4 +251,20 @@ Das belegt keine gemeinsame Ursache mit KI-24b oder den früheren KI-30-Tests;
der Befund bleibt offen. Zur Eingrenzung im bestehenden Z4-ARCH-11 aufnehmen,
solange der Schnitt bei dieser Klasse bleibt; vorhandene Store-Reservierung,
Windows-RED, Größen-/Tier-A-Gates erhalten. Keine Blanket-Retries oder
abgeschwächte Assertionen aus dieser Dokumentation ableiten.
abgeschwächte Assertionen aus dieser Dokumentation ableiten.

**Schluss 2026-10-09 (KI-30-CLOSE).** Nachzählung: `gh run list --workflow ci.yml
--limit 200 --json databaseId,headBranch,createdAt,status,conclusion`
(Exit 0), gefiltert auf `headBranch` mit Präfix `mergify/merge-queue` und
`createdAt` nach 2026-10-09T01:11:29Z. Ergebnis: 43 gestartet, 42 abgeschlossen
(41 success, 1 failure), 1 `in_progress` (zählt nicht). Erster abgeschlossener
Lauf [37868576516](https://github.com/Cuarroc/ProjectA/actions/runs/37868576516)
(01:11:43Z), letzter [37958364523](https://github.com/Cuarroc/ProjectA/actions/runs/37958364523)
(16:20:10Z). Der eine Fehlschlag, Lauf 37910399142 (Windows; 1 non-KI-30 failure,
`goal_task_audit_control_uses_one_connection`, already fixed by #843), brach in der
`rust-suite` ab; `gh run view 37910399142 --log-failed` (Exit 0) enthält keinen
`real_native_`-Treffer, der Schritt `native-tests` kam nie zum Laufen. Damit
0 `real_native_*`-Fehler in 42 ≥ 40 abgeschlossenen Läufen; das Kriterium
(„Beleg über die nächsten 40 Queue-Läufe“) ist erfüllt. Offen bleibt, dass
die Ursache der drei übrigen Tests nie einzeln belegt wurde; der Beleg ist
statistisch (keine Wiederholung in 42 Läufen), kein Ursachenbeweis.
Loading