From a9a18316c894be77cb2fce9b5b6c2573cb14a0f9 Mon Sep 17 00:00:00 2001 From: Cuarroc <47299143+Cuarroc@users.noreply.github.com> Date: Wed, 14 Oct 2026 14:53:51 +0200 Subject: [PATCH] docs(known-issues): move closed KI-30 to Behoben and condense its narrative The KI-30 row was closed on 2026-10-09 but still sat in the Offen table and its narrative filled ~175 lines. Move the row to Behoben, keep cause, fix and the closing evidence (42 queue runs, run 37910399142) in a short section and point to the last commit holding the full text. No-Test: documentation only Co-Authored-By: Claude Sonnet 5.5 --- KNOWN_ISSUES.md | 180 ++---------------------------------------------- 1 file changed, 5 insertions(+), 175 deletions(-) diff --git a/KNOWN_ISSUES.md b/KNOWN_ISSUES.md index 550d13ad..dcd756ab 100644 --- a/KNOWN_ISSUES.md +++ b/KNOWN_ISSUES.md @@ -52,7 +52,6 @@ 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:157`, Zweig `#[cfg(not(windows))]`). 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` | 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. | | 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.). **Hinweis 2026-10-14:** „Release-Blocker R-1“ bezog sich auf v1.5.0; v1.5.0 bis v1.6.3 sind seither veröffentlicht (`gh release list`), die Bezeichnung ist also historisch. Der Rest unten ist unverändert offen und nicht neu geprüft. **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 @@ -80,6 +79,7 @@ Ziel haben. | KI-23 | Die Attribution in `release_claimed_queue_entries` griff beim echten Start praktisch nie; ein gestarteter Claim fiel auf `ready` und wurde doppelt gestartet | 2026-09-24, Paket KI-23, PR #94 (`27b4769`): Reattach-Pass und Claim-Freigabe in `main.rs::reattach_workers_and_resolve_claims`, Dispatcher erst nach der Startfreigabe | Regressionen `queue::tests::a_claim_whose_worker_started_stays_with_it_after_the_reattach_pass`, `tests::the_dispatcher_starts_only_after_the_startup_claims_are_resolved` (beide rot → grün); `.pa/report_ki-23.md` | | KI-2 | `githubRemote` ist in `types.ts` non-optional, `toProject` setzt keinen Default | 2026-10-02, PR #85 (öffentliches Repo) | `toProject` normalisiert ein fehlendes Flag aus älteren Core-Payloads auf `false`; die Regression `src/lib/ipc.test.ts` belegt ein Projekt ohne `githubRemote`. | | KI-12 | Abgleich `cargo audit`/`npm audit` gegen die Dependabot-Alerts war nicht belegt | 2026-10-02, Paket KI-12: deckungsgleich, Tabelle unten. Dependabot-Alerts sind seit 2026-10-02 eingeschaltet; `gh api repos/Cuarroc/ProjectA/dependabot/alerts?state=open,fixed,dismissed,auto_dismissed --paginate` liefert genau einen Alert, Exit 0 | `cargo audit --json` in `src-tauri` (advisory-db 1280 Einträge, Stand 2026-10-02, 564 Kisten): 0 Vulnerabilities, 2 Warnungen; `npm audit --json`: 0 in allen Stufen | +| KI-30 | Windows-Gate `native-tests`: vier der acht `real_native_*`-Tests scheiterten sporadisch in Merge-Queue-Läufen, jedes Mal nach grüner `rust-suite` | 2026-10-09 (KI-30-CLOSE); Ursache behoben mit V16-01 (2026-10-05), PR #518 und #874 | 42 abgeschlossene Queue-Läufe, 0 `real_native_*`-Fehler; der eine Fehlschlag (Lauf 37910399142) war ein anderer Test, siehe Abschnitt „KI-30“ unten. Tritt ein `real_native_*`-Test wieder rot auf, ist das ein neuer Befund. | ### KI-12: Abgleich vom 2026-10-02 @@ -105,180 +105,10 @@ x86_64-pc-windows-msvc -i glib` liefert weiterhin nichts (2026-10-02). | KI-26 | Windows-PTY-Argumenttest `pty::tests::a_quote_and_a_variable_reach_the_process_unchanged` scheiterte sporadisch (Run 35266952403, 17.09.; Run 35917374303, 23.09.) | 2026-10-02 (KI-OBS): seit dem Node-Vorstart im Test (24.09.) kein erneutes Auftreten | Beleg: 301 abgeschlossene Läufe vom 25.09. bis 02.10., darunter die Windows-Bahn; in den fünf roten Windows-Läufen dieses Zeitraums steht der Test als PASS (0,3–0,5 s), nie als FAIL. Die Kaltstart-Erklärung ist damit nicht widerlegt (`.pa/report_ci_native_pty_marker.md`); wird der Test wieder rot, gilt sie als widerlegt. | | KI-27 | Ein nativer Provider, der vor dem Lesen seines Inputs endet (`exited_undelivered`), hielt Token-Reservierung und Delivery-Zeile auf `started` | 2026-10-02 (KI-OBS): mit DF-15a (PR #103) und DF-15b (PR #16, 25.09.) behoben; kein erneutes Auftreten | Beleg: 301 abgeschlossene Läufe vom 25.09. bis 02.10. (50 rot, alle durchsucht); die `exited_undelivered`-Tests in `store::development_launches::tests` stehen nie als FAIL. Der Mechanismus (Freigabe im Exit-Commit, abgeleiteter `effectiveState`, Start-Abgleich) steht im alten Eintrag und im Code; weiterhin fail-closed: ein Absturz zwischen Host-Ende und Store-Commit bleibt `spawning` mit gehaltener Reservierung. | -### KI-30: `real_native_*`-Flake auf der Windows-Bahn (Stand 2026-10-04) +### KI-30: `real_native_*`-Flake auf der Windows-Bahn (geschlossen 2026-10-09) -**Symptom.** Im Merge-Queue-Lauf scheitert das Gate `native-tests` -(`scripts/ci/native-tests.sh`, `cargo test --bin projecta real_native_ -- ---ignored`, acht Tests, kein `--test-threads`) mit 1 bis 2 roten Tests. Das -Gate `rust-suite` davor ist in allen sieben Fällen grün (zuletzt 1733 von 1733). -Beim selben Code laufen die acht Tests in anderen Queue-Läufen durch (40 bis -49 s). Ein Fehlschlag wirft den PR aus der Queue, obwohl er den Code gar nicht -berührt (Lauf 37104184524 gehörte zu PR #199, reinen UI-Texten). +Ursache (V16-01, 2026-10-05): Beendet sich der Provider vor der Eingabe, kehrte `execute_host_inner` (`process_capture/windows_capture.rs`) zurück, während ein Checkpoint noch in SQLite geschrieben wurde; die Bestätigung scheiterte (`checkpoint owner no longer waiting`), der Start blieb `unresolved`. Fix: der Undelivered-Pfad wartet höchstens 10 s auf jeden eingereichten Checkpoint. Wächter: `process_capture::managed::tests::real_native_owned_host_waits_for_pending_checkpoints_after_an_undelivered_exit`. -**Betroffene Tests** (Zeilen auf `main` @ `f48af09`): +Schluss (KI-30-CLOSE, `gh run list --workflow ci.yml --limit 200`, Exit 0): 42 abgeschlossene Queue-Läufe ab 2026-10-09T01:11:29Z (Lauf 37868576516 bis 37958364523), 41 success, 1 failure. Der Fehlschlag, Lauf 37910399142, war `goal_task_audit_control_uses_one_connection` in `rust-suite` (bereits durch #843 behoben), kein `real_native_`-Treffer, `native-tests` lief nie. Beleg ist statistisch, die Ursache der drei übrigen Tests wurde nie einzeln belegt. -| Test | Deklaration | Assertion, die auslöste | -|---|---|---| -| `workers::tests::real_native_provider_exit_before_input_delivery_reconciles_as_exited` | `src-tauri/src/workers.rs:4148` | `:4228` „native launch left unresolved instead of reconciled“ | -| `workers::tests::real_native_launch_service_owns_worktree_credentials_and_exit` | `src-tauri/src/workers.rs:3960` | `:4070` `drained.unresolved.is_empty()` ist `false` | -| `store::development_capture::managed_tests::real_native_runner_bounds_capacity_and_accepts_out_of_order_completion` | `src-tauri/src/store/native_managed_tests.rs:290` | `:449` `drained.unresolved.is_empty()` (der `unwrap` bei `:478` ist nur die Folge) | -| `store::development_capture::managed_tests::real_native_job_revokes_credentials_before_retirement_or_reconciliation` | `src-tauri/src/store/native_managed_tests.rs:133` | `:173` Fall 0: „native host did not complete cleanly; checkpoint owner no longer waiting; launch retained for reconciliation“ | - -**Belege.** Quelle: `gh run list --workflow ci --limit 300` (Läufe vom -2026-10-02 17:45 UTC bis 2026-10-03 06:47 UTC; davon 58 Queue-Läufe auf -`mergify/merge-queue/*`: 46 grün, 11 rot, 1 ohne Ergebnis) und `gh run view - --log-failed` für alle 33 roten Läufe der Stichprobe. Nur vorhandene Logs, -keine neuen Läufe. Sieben rote Queue-Läufe tragen einen der vier Tests: - -| Lauf (Queue) | Beginn UTC | Test(s) rot | -|---|---|---| -| 37068740486 | 10-02 21:45 | `…job_revokes_credentials…` und `…bounds_capacity…` | -| 37082745894 | 10-03 00:36 | `…provider_exit_before_input_delivery…` | -| 37085248919 | 10-03 01:13 | `…provider_exit_before_input_delivery…` | -| 37089103958 | 10-03 02:14 | `…bounds_capacity…` | -| 37096906110 | 10-03 04:32 | `…provider_exit_before_input_delivery…` und `…bounds_capacity…` | -| 37099907810 | 10-03 05:28 | `…launch_service_owns_worktree…` | -| 37104184524 | 10-03 06:47 | `…provider_exit_before_input_delivery…` | - -Die übrigen vier roten Queue-Läufe haben andere Ursachen und gehören nicht zu -diesem Eintrag: 37102667685 (`workers::tests::a_withdrawn_variant_costs_the_addition_not_the_respawn`, -`workers.rs:5418`, in `rust-suite`), 37044790937 (Runner-Start: `install-action` -„bash startup failure“, danach `pa-capture-host --self-test-host: Exit 2`) und -37063228246 sowie 37066349860 (`red-first`). Die Windows-Bahn eines gewöhnlichen -PR ist seit CI-03 ein Stub; deshalb taucht der Flake nur in Queue-, Push- und -Wochenläufen auf. Die Push-Läufe auf `main` der Stichprobe (69 grün, 4 -abgebrochen) zeigen keinen Fall. - -**Was die Logs über den Mechanismus hergeben.** Drei der vier Tests scheitern -immer am selben Punkt: nach dem Drain bleibt ein Start unaufgelöst -(`unresolved` nicht leer). Beim Early-Exit-Test steht im selben Log jedes Mal, -dass das Test-Temp-Verzeichnis nicht gelöscht werden konnte („The process cannot -access the file because it is being used by another process“, os error 32): -ein Prozess (Capture-Host oder Kindprozess) lief bei der Assertion noch oder -hielt das Verzeichnis offen. Die Laufzeit der acht Tests unterscheidet rote und -grüne Läufe nicht eindeutig (rot 39 bis 68 s, grün 40 bis 49 s). - -**Vermutung (nicht belegt).** Die acht Tests laufen im Gate parallel in einem -Prozess und starten je echte ConPTY-/Job-Objekt-Kindprozesse auf dem -gehosteten Windows-Runner. Unter Last gewinnt gelegentlich das Zeitfenster -(`drain`/`wait_completion` mit 10 bis 40 s, `shutdown` mit 25 s) oder die -Reihenfolge „Host beendet, Store-Abgleich, Prüfung“ nicht, sodass der Start -noch `unresolved` ist. Alternative: ein echter Fehler in der Abgleichsreihenfolge -(vgl. KI-27, DF-15), der nur bei knappem Timing sichtbar wird. Beides ist -nicht unterschieden. - -**Nächster Schritt.** (1) Kein Test wird abgeschwächt und kein Zeitlimit -„einfach“ erhöht, bevor die Ursache eingegrenzt ist. (2) Das Gate -`native-tests` führt die acht Tests vorübergehend mit `--test-threads=1` aus; -das ist eine Minderung für parallele ConPTY-Kindprozesse, keine Behebung der -Ursache. (3) Bei Reproduktion im Test den -Zustand von `unresolved` und die noch lebenden Prozesse ausgeben, bevor -assertiert wird. (4) Eigenes Paket mit rotem Regressionstest; die vier -Assertionen liegen in Nahtstellen-Nähe (`store/`, `workers.rs`), also -seriell und mit Prüfung der Stufe A. Auf Linux nicht nachstellbar: das Gate -verlangt ein echtes Windows (`native-tests.sh` bricht sonst ab). - -**Neue Beobachtung 2026-10-03 (PR #252, ARCH-08f).** Queue-Lauf 37154872281 -(Queue-Kopf `5a79d6a`): `rust-suite` 1749 von 1749 grün, `native-tests` 7 -grün, 1 rot: `real_native_runner_bounds_capacity_and_accepts_out_of_order_completion`, -`src-tauri/src/store/native_managed_tests.rs:449` (`drained.unresolved.is_empty()`), -Folgefehler `:478`. Dasselbe Muster wie oben; #252 ändert nur Frontend-Dateien. -Die Queue hat #252 um 21:54 UTC entlassen; der Koordinator reiht ihn genau einmal -unverändert neu ein (Queue-PR #257). **Nicht als gelöst vermerkt**: erst ein -frischer Lauf am gleichen Quellstand sagt etwas, und auch ein grüner Lauf belegt -die Ursache nicht. - -**Stand 2026-10-03 23:26 UTC (beobachtet; Quellstand `origin/main` cc95a57, Merge #260 um 23:16:34 UTC).** Die Ursache bleibt **unbekannt**; es gibt keine -Behebung und keinen Beleg für „Flake“ oder „echter Fehler“. Der erste Queue-Lauf -37154872281 von #252 scheiterte mit `native_managed_tests.rs:449`; der -kontrollierte einmalige Neulauf 37157889878 am gleichen Quellstand war grün. -Das widerlegt die Ursache nicht. PR #262 (Kopf `14e1532`) gibt nur -`unresolved`-IDs und Abschlussergebnisse in der Assertion-Meldung aus: er -ändert weder Bedingungen noch Timing noch Produktionscode. Die Änderung liegt -in Windows-Tests und wurde auf Linux nicht kompiliert; den Beleg liefert die -Windows-Bahn in der Queue. - -**Neue Beobachtung 2026-10-04 (Queue-PR #281, prüft #273 auf `effef1a`).** -Queue-Lauf 37196272431 (Beginn 10:43 UTC; `gh run view 37196272431 --log-failed`): -nur `gates (windows)` rot, `native-tests` 7 grün, 1 rot: -`workers::tests::real_native_provider_exit_before_input_delivery_reconciles_as_exited`, -`src\workers.rs:4069` „native launch left unresolved instead of reconciled: -["pty-1a1068ef219-1"]“. Im selben Log steht „failed to remove test temp -directory … os error 32“. Dasselbe Muster wie oben; #273 ändert nur -Review-Skripte und Doku. Eine Ursache wird daraus nicht abgeleitet; #262 -(Diagnose) war da schon in `main`. - -**Forschungsstand 2026-10-04.** In 8 von 42 untersuchten Queue-Läufen trat -KI-30 auf. Cluster B überschritt die Deadline um ungefähr 50 Sekunden; Cluster -A endete mit „unknown error“ und zusätzlich `os error 32`. Das grenzt den -Mechanismus ein, beweist aber weiterhin keine Ursache. Die serielle Ausführung -des unveränderten Bestands von acht `real_native_*`-Tests bleibt deshalb eine -als **TEMPORÄR** gekennzeichnete Minderung und wird mit der eigentlichen -KI-30-Behebung wieder entfernt. **Überholt:** `scripts/ci/native-tests.sh` -enthält seit V16-01 (2026-10-05, siehe unten) kein `--test-threads` mehr -(`grep -n test-threads scripts/ci/native-tests.sh`, 2026-10-14: kein Treffer). - -**Ursache belegt 2026-10-05 (V16-01, Branch `claude/w16-01-ki30-gate-drain`).** -In beiden roten Läufen vom 05.10. (37301269691, 37308669763) meldet der -Early-Exit-Test als einzigen Fehler `checkpoint owner no longer waiting; launch -retained for reconciliation`: Die native Seite war erfolgreich, nur die -Bestätigung eines Checkpoints scheiterte. Mechanismus: Beendet sich der -Provider, bevor seine Eingabe ankommt, wartet der Elternprozess auf keine -Quittung mehr. `execute_host_inner` (`process_capture/windows_capture.rs`) kehrte -zurück, während der Process-Checkpoint noch in SQLite geschrieben wurde. Damit -fiel der Antwortkanal weg, die Bestätigung des Checkpoint-Akteurs -(`checkpoints.rs`, `acknowledge`) scheiterte, `managed::run` übersprang -`finalize_native_undelivered_exit`, und der Start blieb `unresolved`. „os error -32“ ist nur Aufräumrauschen nach dem Panic. Belegt durch den deterministischen -Test `process_capture::managed::tests::real_native_owned_host_waits_for_pending_checkpoints_after_an_undelivered_exit` -(Process-Bestätigung 3 s verzögert): rot in Lauf 37323778974 mit -`[(Launch, Ok(())), (Process, Err("checkpoint owner no longer waiting"))]`, -grün nach dem Fix in 37325836015, 37327636278 und 37332693087 (37327651607 -dazwischen rot nur durch einen fremden Timeout in `rust-suite`, -`retention::tests::deletion_runs_in_chunks_until_the_table_is_clean`). Fix: Der -Undelivered-Pfad wartet, bis jeder eingereichte Checkpoint bestätigt ist -(höchstens 10 s); Ablehnung, Verlust und Zeitüberschreitung bleiben Fehler. -Danach ist `--test-threads=1` aus `scripts/ci/native-tests.sh` entfernt -(Lauf siehe PR-Text). **Nicht belegt:** ob dieselbe Ursache die anderen drei -Tests trifft (`…bounds_capacity…`, `…launch_service_owns_worktree…`, -`…job_revokes_credentials…`; Letzterer trug ebenfalls „checkpoint owner no -longer waiting“, aber neben einem nativen Fehler). Geschlossen wird KI-30 erst -nach 0 Fehlschlägen in den nächsten 40 Queue-Läufen (`docs/plan/v1.6.0/plan.md`, -V16-01). - -**Zusatzbeobachtung 2026-10-08 (KI-30, anderer Test).** In den Queue-Runs -[37810056116](https://github.com/Cuarroc/ProjectA/actions/runs/37810056116) -(Branch `mergify/merge-queue/cc3f3a946c`, Head `622f2e21`) und -[37814405700](https://github.com/Cuarroc/ProjectA/actions/runs/37814405700) -(Branch `mergify/merge-queue/f8a5121bb4`, Head `5b4452b7`) scheiterte -`store::development_capture::managed_tests::real_native_completed_receipt_survives_sqlite_writer_within_busy_timeout`. -Die gelesenen Windows-Logs nennen `native host did not complete cleanly` und -am Receipt-Checkpoint `checkpoint owner no longer waiting`; die Assertion -steht dort in `src-tauri/src/store/native_managed_tests.rs:195`, der folgende -Join-Fehler bei `:202`. Beide Runs: Windows rot, Linux und red-first grün. -Quelle: `gh run view --json headBranch,headSha,conclusion,jobs` und -`gh run view --log-failed`, jeweils Exit 0; kein neuer Testlauf. - -Root ordnet dies derselben Windows-Native-Flake-Klasse zu und meldet andere -grüne Batches im Zeitfenster sowie die erneute Einreihung von #663/#700. -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. - -**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. +Der volle Text (Testtabelle, Läufe, Beobachtungen, Forschungsstand) steht im letzten Commit davor: `git show 42ed6709:KNOWN_ISSUES.md`.