From cb5ca3ffbe4957ebf2990cf52c799a54521bcf2e Mon Sep 17 00:00:00 2001 From: Cuarroc <47299143+Cuarroc@users.noreply.github.com> Date: Fri, 9 Oct 2026 19:02:05 +0200 Subject: [PATCH 1/2] docs(known-issues): close KI-30 with queue evidence, record KI-34 No-Test: docs only (KNOWN_ISSUES.md) Co-Authored-By: Claude Sonnet 5.5 --- KNOWN_ISSUES.md | 33 +++++++++++++++++++++++++++++++-- 1 file changed, 31 insertions(+), 2 deletions(-) diff --git a/KNOWN_ISSUES.md b/KNOWN_ISSUES.md index 5179be1e..f6a2f54d 100644 --- a/KNOWN_ISSUES.md +++ b/KNOWN_ISSUES.md @@ -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). Der Fehlschlag in Lauf 37910399142 ist ein anderer Test, siehe KI-34. 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.). **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 @@ -53,6 +53,7 @@ Ziel haben. | KI-15 | Prompts standen im argv des Agentenprozesses (`workers.rs::with_system_prompt`, Zweig `SystemPrompt::Arg`) | 2026-10-03, PR #116 (Merge `c3de8410ff4e4335fc24a5149d0ecbc5bb515928`) | Claude nutzt das von `claude --help` dokumentierte `--append-system-prompt-file`, Kimi bereits `--agent-file`, und Codex verweist über `--config model_instructions_file=…` auf die private Prompt-Datei (Konfigurationsschlüssel laut offizieller Codex-Referenz). Regressionstests prüfen für Claude und Codex, dass der Koordinatorprompt nicht im argv steht und unverändert aus der Worker-Datei gelesen wird. `opencode --help` (1.18.34) zeigt keinen Systemprompt-Dateikanal und bleibt `unsupported`. Die Ollama-CLI war auf der Prüfmaschine nicht installiert, daher bleibt auch dieses Profil vorsichtig `unsupported`, ohne eine unbelegte Fähigkeit zu behaupten. Das Hook-Secret ist seit `933dfcd` über eine private `--config`-Datei geschützt. | | KI-16 | `PtyManager::spawn` lief synchron auf der Tokio-Runtime (openpty plus Prozesserzeugung) | Linux: PR #141 (Merge `376f75f55406d813732dc8a638c5a94d06e90e02`, 2026-10-03) und PR #438 (Merge `cd7ec3207e84b3cafd7947d92ae691701aa24a0e`, 2026-10-05) | `spawn_with_id` (und damit `spawn`) gibt den Runtime-Worker per `block_in_place` frei, sobald es auf einer Multi-Thread-Tokio-Runtime läuft (`off_runtime_thread`, `pty.rs`); ohne diese Runtime bleibt die Arbeit inline. Wächter: `pty::tests::blocking_spawn_work_leaves_the_runtime_worker_free`. Seit #438 ist der Tauri-Befehl `spawn_pty` (`main.rs`) `async` und ruft `PtyManager::spawn` auf diesem Runtime-Worker auf. Ein eigener Test für `spawn_pty` fehlt; die Windows-Bahn (ConPTY) ist hier nicht gelaufen. | | KI-33 | Windows-Gate: `retention::tests::deletion_runs_in_chunks_until_the_table_is_clean` überschritt das nextest-Limit (TIMEOUT nach 120 s) | PR #543 (Merge `04ea1a4313649d8882b70e0bd11643e7ee0ac525`, 2026-10-05); Windows-Queue-Beleg am 2026-10-08 | Der Test fügt seine 1200 Zeilen jetzt in einer Transaktion ein; Zeilenzahl und Assertions bleiben gleich. Zuvor Timeouts in den Läufen 37343111847 und 37327651607. Queue-Lauf **37767556830**, Kopf `729393d684f1fa94b00439ccfd5af80233a466f0` (enthält #543), Job `gates (windows)` **success**: Test **PASS [1.812s]**. Beleg: `gh run view 37767556830 --job 113278804180 --log`; keine Aussage über langfristige Flake-Freiheit aus diesem einzelnen Lauf. | +| KI-34 | Windows-Gate: `store::continuous::tests::goal_task_audit_control_uses_one_connection` lief in `Elapsed(())` (`continuous.rs:1598`), Queue-Lauf 37910399142 (09.10.) | offen, Beobachtung (niedrig, Flake) | Einmaliges Auftreten, keine gemeinsame Ursache mit KI-30 abgeleitet. Details im Abschnitt „KI-34“ unten. | | KI-32 | `main-red-guard` auf `main` rot, obwohl Linux und Windows grün waren (Lauf 37156370787, Kopf `dfe459f`) | 2026-10-04, kein Codefehler: der Schritt „red main -> issue + queue freeze“ bekam von GitHub bei `gh issue list` ein `503 Service Unavailable` mit leerem JSON (`SyntaxError: Unexpected end of JSON input`, Exit 1); `gates (linux)` und `gates (windows)` desselben Laufs waren `success`. | `gh run view 37156370787 --attempt 1 --log-failed` zeigt den 503; Versuch 2 desselben Laufs (nur der fehlgeschlagene Job neu gestartet) ist `success` auf demselben SHA `dfe459f`. Kein Code und keine Gate-Logik geändert. | | KI-20 | Doppelte Antwort auf die Cursor-Abfrage `ESC[6n`: der Reader-Thread antwortete mit `ESC[1;1R`, und xterm.js antwortete beim Scrollback-Replay ein zweites Mal | 2026-10-03, W1-27, PR #140 (Merge `56266cce31a905b6f3e946e774bfd3ad1ccd3044`; Advisor-Entscheidung: nur das Backend antwortet) | `CursorReportScanner::strip` entfernt die beantwortete Anfrage aus Scrollback und UI; Test `a_cursor_position_query_never_reaches_the_terminal_view`; `docs/decisions.md` (16.09., Auflösung). Die Antwort bleibt fest `1;1` (Kommentar an `CURSOR_POSITION_REPLY`). Kein Live-Kimi-Re-Smoke (W1-01b blockiert). | | KI-19 | Unix-Modus-Tests (0600) für Vault und API-Deskriptor fehlten | 2026-10-03, PR #123 (Paket KI-19, Linux-Server): Tests `providers::tests::a_vault_file_is_private_from_the_moment_it_exists` und `a_rewritten_vault_stays_private_and_leaves_no_temp_file`, `api::tests::the_api_descriptor_is_owner_only_even_over_a_stale_loose_file` sowie der Run-Deskriptor-Test (0600, `agent-access/` 0700) laufen grün; die Rechte waren schon richtig, kein Produktivcode geändert | `cargo test --bin projecta` (Filter auf die drei Tests), Exit 0 | @@ -251,4 +252,32 @@ 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. \ No newline at end of file +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), 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. + +### KI-34: `goal_task_audit_control_uses_one_connection` (Stand 2026-10-09) + +Queue-Lauf [37910399142](https://github.com/Cuarroc/ProjectA/actions/runs/37910399142) +(Branch `mergify/merge-queue/9759fd4ca9`, Head `a2cf14b0`, Windows): der Test +`store::continuous::tests::goal_task_audit_control_uses_one_connection` meldete +`audit must not acquire a second pooled connection while holding the writer: +Elapsed(())` (`src\store\continuous.rs:1598:10`); 1952 von 1953 Tests grün, +`native-tests` lief danach nicht mehr. Linux und red-first desselben Laufs +grün. Einmaliges Auftreten in den 42 abgeschlossenen Läufen des Fensters; keine +gemeinsame Ursache mit KI-30 abgeleitet, nicht Teil von KI-30. Offen: bei +Wiederholung Log und Zeitlimit des Tests prüfen. Quelle: `gh run view +37910399142 --log-failed`, Exit 0. From 0eb83b0c9ff52616013dd3dba3274b8de6697655 Mon Sep 17 00:00:00 2001 From: Cuarroc <47299143+Cuarroc@users.noreply.github.com> Date: Fri, 9 Oct 2026 19:19:26 +0200 Subject: [PATCH 2/2] docs(known-issues): drop KI-34, failure already fixed by #843 R874-R1: the run 37910399142 failure (goal_task_audit_control_uses_one_connection) was fixed by hotfix #843; a new KI id duplicated it. KI-30 closing text now names it as a non-KI-30 failure. No-Test: docs only (KNOWN_ISSUES.md) Co-Authored-By: Claude Sonnet 5.5 --- KNOWN_ISSUES.md | 19 +++---------------- 1 file changed, 3 insertions(+), 16 deletions(-) diff --git a/KNOWN_ISSUES.md b/KNOWN_ISSUES.md index f6a2f54d..f6ab4f97 100644 --- a/KNOWN_ISSUES.md +++ b/KNOWN_ISSUES.md @@ -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` | 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). Der Fehlschlag in Lauf 37910399142 ist ein anderer Test, siehe KI-34. Tritt ein `real_native_*`-Test wieder rot auf, ist das ein neuer Befund. | +| 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.). **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 @@ -53,7 +53,6 @@ Ziel haben. | KI-15 | Prompts standen im argv des Agentenprozesses (`workers.rs::with_system_prompt`, Zweig `SystemPrompt::Arg`) | 2026-10-03, PR #116 (Merge `c3de8410ff4e4335fc24a5149d0ecbc5bb515928`) | Claude nutzt das von `claude --help` dokumentierte `--append-system-prompt-file`, Kimi bereits `--agent-file`, und Codex verweist über `--config model_instructions_file=…` auf die private Prompt-Datei (Konfigurationsschlüssel laut offizieller Codex-Referenz). Regressionstests prüfen für Claude und Codex, dass der Koordinatorprompt nicht im argv steht und unverändert aus der Worker-Datei gelesen wird. `opencode --help` (1.18.34) zeigt keinen Systemprompt-Dateikanal und bleibt `unsupported`. Die Ollama-CLI war auf der Prüfmaschine nicht installiert, daher bleibt auch dieses Profil vorsichtig `unsupported`, ohne eine unbelegte Fähigkeit zu behaupten. Das Hook-Secret ist seit `933dfcd` über eine private `--config`-Datei geschützt. | | KI-16 | `PtyManager::spawn` lief synchron auf der Tokio-Runtime (openpty plus Prozesserzeugung) | Linux: PR #141 (Merge `376f75f55406d813732dc8a638c5a94d06e90e02`, 2026-10-03) und PR #438 (Merge `cd7ec3207e84b3cafd7947d92ae691701aa24a0e`, 2026-10-05) | `spawn_with_id` (und damit `spawn`) gibt den Runtime-Worker per `block_in_place` frei, sobald es auf einer Multi-Thread-Tokio-Runtime läuft (`off_runtime_thread`, `pty.rs`); ohne diese Runtime bleibt die Arbeit inline. Wächter: `pty::tests::blocking_spawn_work_leaves_the_runtime_worker_free`. Seit #438 ist der Tauri-Befehl `spawn_pty` (`main.rs`) `async` und ruft `PtyManager::spawn` auf diesem Runtime-Worker auf. Ein eigener Test für `spawn_pty` fehlt; die Windows-Bahn (ConPTY) ist hier nicht gelaufen. | | KI-33 | Windows-Gate: `retention::tests::deletion_runs_in_chunks_until_the_table_is_clean` überschritt das nextest-Limit (TIMEOUT nach 120 s) | PR #543 (Merge `04ea1a4313649d8882b70e0bd11643e7ee0ac525`, 2026-10-05); Windows-Queue-Beleg am 2026-10-08 | Der Test fügt seine 1200 Zeilen jetzt in einer Transaktion ein; Zeilenzahl und Assertions bleiben gleich. Zuvor Timeouts in den Läufen 37343111847 und 37327651607. Queue-Lauf **37767556830**, Kopf `729393d684f1fa94b00439ccfd5af80233a466f0` (enthält #543), Job `gates (windows)` **success**: Test **PASS [1.812s]**. Beleg: `gh run view 37767556830 --job 113278804180 --log`; keine Aussage über langfristige Flake-Freiheit aus diesem einzelnen Lauf. | -| KI-34 | Windows-Gate: `store::continuous::tests::goal_task_audit_control_uses_one_connection` lief in `Elapsed(())` (`continuous.rs:1598`), Queue-Lauf 37910399142 (09.10.) | offen, Beobachtung (niedrig, Flake) | Einmaliges Auftreten, keine gemeinsame Ursache mit KI-30 abgeleitet. Details im Abschnitt „KI-34“ unten. | | KI-32 | `main-red-guard` auf `main` rot, obwohl Linux und Windows grün waren (Lauf 37156370787, Kopf `dfe459f`) | 2026-10-04, kein Codefehler: der Schritt „red main -> issue + queue freeze“ bekam von GitHub bei `gh issue list` ein `503 Service Unavailable` mit leerem JSON (`SyntaxError: Unexpected end of JSON input`, Exit 1); `gates (linux)` und `gates (windows)` desselben Laufs waren `success`. | `gh run view 37156370787 --attempt 1 --log-failed` zeigt den 503; Versuch 2 desselben Laufs (nur der fehlgeschlagene Job neu gestartet) ist `success` auf demselben SHA `dfe459f`. Kein Code und keine Gate-Logik geändert. | | KI-20 | Doppelte Antwort auf die Cursor-Abfrage `ESC[6n`: der Reader-Thread antwortete mit `ESC[1;1R`, und xterm.js antwortete beim Scrollback-Replay ein zweites Mal | 2026-10-03, W1-27, PR #140 (Merge `56266cce31a905b6f3e946e774bfd3ad1ccd3044`; Advisor-Entscheidung: nur das Backend antwortet) | `CursorReportScanner::strip` entfernt die beantwortete Anfrage aus Scrollback und UI; Test `a_cursor_position_query_never_reaches_the_terminal_view`; `docs/decisions.md` (16.09., Auflösung). Die Antwort bleibt fest `1;1` (Kommentar an `CURSOR_POSITION_REPLY`). Kein Live-Kimi-Re-Smoke (W1-01b blockiert). | | KI-19 | Unix-Modus-Tests (0600) für Vault und API-Deskriptor fehlten | 2026-10-03, PR #123 (Paket KI-19, Linux-Server): Tests `providers::tests::a_vault_file_is_private_from_the_moment_it_exists` und `a_rewritten_vault_stays_private_and_leaves_no_temp_file`, `api::tests::the_api_descriptor_is_owner_only_even_over_a_stale_loose_file` sowie der Run-Deskriptor-Test (0600, `agent-access/` 0700) laufen grün; die Rechte waren schon richtig, kein Produktivcode geändert | `cargo test --bin projecta` (Filter auf die drei Tests), Exit 0 | @@ -261,23 +260,11 @@ abgeschwächte Assertionen aus dieser Dokumentation ableiten. (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), brach in der +(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. - -### KI-34: `goal_task_audit_control_uses_one_connection` (Stand 2026-10-09) - -Queue-Lauf [37910399142](https://github.com/Cuarroc/ProjectA/actions/runs/37910399142) -(Branch `mergify/merge-queue/9759fd4ca9`, Head `a2cf14b0`, Windows): der Test -`store::continuous::tests::goal_task_audit_control_uses_one_connection` meldete -`audit must not acquire a second pooled connection while holding the writer: -Elapsed(())` (`src\store\continuous.rs:1598:10`); 1952 von 1953 Tests grün, -`native-tests` lief danach nicht mehr. Linux und red-first desselben Laufs -grün. Einmaliges Auftreten in den 42 abgeschlossenen Läufen des Fensters; keine -gemeinsame Ursache mit KI-30 abgeleitet, nicht Teil von KI-30. Offen: bei -Wiederholung Log und Zeitlimit des Tests prüfen. Quelle: `gh run view -37910399142 --log-failed`, Exit 0.