Repository navigation
Configurator MVP: durable bootstrap state, reviewed Apply and recovery #90
Description
Current Status (2026-10-06)
Customer Apply and immutable saved plans are implemented locally. The explicitly reviewed same-state, output-only upgrade was applied successfully on 2026-10-06: zero resource changes, existing S3 state version 5 to 6, and real Platform contract export verified. Hard runner loss, real partial-failure acceptance and interrupted-run reconciliation remain open; this successful export does not prove those remaining operational criteria.
- Implement encrypted durable bootstrap checkpoints and protected partial-failure recovery receipts; temporary bootstrap is not a permanent central customer-state bucket.
- Prove checkpoint/recovery behavior during real partial failure and hard runner loss before accepting customer Apply operationally.
- Bind an immutable encrypted saved plan and expiry to configuration, reviewed engine, credential version, state version and runner identity; show safe change/replacement/deletion counts.
- Persist explicit approval bound to the exact saved plan; reject stale/replaced plans, changed bindings and changed authority.
- Serialize deployment mutations and enforce existing bounded capacity/active-job limits.
- Reconcile interrupted/untracked workers and verify serialization across all direct operational paths.
- Implement management-backend creation through the LZA, exact state migration verification, native S3 primary state and independent protected recovery evidence.
- Accept real Apply, management credential switch, S3 migration, interrupted migration/recovery and follow-up Plan; verify safe retries without retrying Apply automatically.
- Read existing state for later plans; reject backend-free initial plans on known partial deployments, source aliases and unmapped legacy state (Configurator MVP: execute supported configurations from the common editor #89).
- Document portable backend/configuration export, manual recovery and the absence of automatic destroy.
- Exercise backup/restore and operator recovery against the agreed acceptance environment.
Evidence and Next Step
Implementation: landing-zone-configurator/app/apps/api/src/plans/, apps/api/src/deployments/, apps/worker/, migrations 017-020; lifecycle documentation in landing-zone-configurator/docs/plan-execution.md and docs/runtime-validation-report.md.
Latest scoped compiler plus isolated PostgreSQL broker suite: 61/61 passed. Canonical check: 397 passed, 52 environment-gated skipped, with TypeScript/build/lint passing. Four positive/negative mocked export browser cases passed across desktop/mobile. Separately, the authenticated real output API returned 200 and the actual UI export generated a 559-byte JSON Blob with schema 1 and two targets. The integrated browser did not expose a download event, so filesystem delivery is not claimed. Local commits 0487531 and 55d78cc are activated selectively in the isolated local API/UI; no push, merge or release. Customer schema remains 001-034 and Application execution is disabled.
Next: close the interrupted-run reconciliation/operational gaps before a separately approved real customer lifecycle acceptance. A Plan success is not an Apply/migration/recovery acceptance.
Constraints and Dependencies
Each customer Apply requires the user's separate explicit consent in the protected workflow. Infrastructure Apply permission does not cover customers. Folder destroy is affected by #22. No permanent central customer-state bucket; no automatic destroy, silent Apply retry or automatic migration of monolithic states. Depends on #89; application integration #93; operational evidence #95.
Activity
lweberru commentedon Oct 4, 2026
MVP audit 2026-10-04: Updated the description and acceptance checklist against the current implementation. Implemented criteria are checked; remaining requirements are retained. Local tests are not a release or live customer acceptance. This issue stays open until its remaining criteria are met. The first remaining safety fix (#89, backend-free initial plans on existing/partial/legacy state) is now implemented locally: 23/23 isolated PostgreSQL tests and the full check gate (310 unit tests) pass. No customer Apply, API restart, native artifact rebind, commit or merge was performed.
lweberru commentedon Oct 6, 2026
Recovery-Sperre beim erneuten Plan sichtbar machen
Der Benutzer sieht nach fehlgeschlagenem Plattform-Apply trotz neuer Vorbereitung und gesetzter Bestätigung einen deaktivierten Plan-Button. Diagnose:
Plans.resultsetzt fehlgeschlagene Apply-Ergebnisse bewusst aufrecovery_required; sowohl Server-Startprüfung/SQL-Indizes als auch UI sperren weitere Plans. Ein Status-Refresh oder eine neue Konfigurationsrevision löst das nicht.Lokaler Commit
76a22dcerklärt diese bestehende Sperre direkt am Button, auf Deutsch/Englisch und über aria-describedby. Der bestehende Recovery-Browsertest prüft ausgewählte Vorbereitung + gesetzte Bestätigung, weiterhin deaktivierten Button, Sprachwechsel und null Plan-Mutationen. Desktop/Mobil bestanden, Screenshots/Breitenprüfung kontrolliert; Build/Testtypen/Editor-Diagnostik/diff-check und Root-Gitleaks bestanden (bestehende nicht blockierende Hinweise unverändert). Aktive lokale UI liefert den neuen Build; API/Paket/State/Laufstatus nicht verändert. Kein Cloud-Lauf, Retry, Destroy oder State-Reset; kein Push/Release/Merge.Weiterhin offen und für den Kunden blockierend: ein geregelter owner-/tenantgebundener Operator-/UI-Recovery-Abgleich, der persistierten Teilstate, etwaige Recovery-Nachweise und Runner-/Lock-Status prüft und die Freigabe unveränderlich auditiert. Vorliegend ist die tatsächliche Live-State-Sicherung noch nicht unabhängig nachgewiesen. Runner-Recovery-Upload ist kein Bedienweg zur Entsperrung. Es wurde kein ungesicherter Statuswechsel hinzugefügt; #90 bleibt offen.
lweberru commentedon Oct 6, 2026
Konkrete Recovery-Diagnose: Bootstrap-Checkpoint vorhanden, Lock frei
Nach ausdruecklicher Benutzerfreigabe wurde fuer genau den freigegebenen Plan eine rein lesende lokale Metadatenabfrage in
BEGIN READ ONLYausgefuehrt. Kein Ciphertext/State-Inhalt, Session oder Zugangsschluessel wurde gelesen oder ausgegeben; kein Cloud-Aufruf oder Statuswechsel.Bestaetigte Betriebsmetadaten: Apply
recovery_required, Fehlercodeapply_failed, gespeicherte Plan-Pruefsumme entspricht dem Benutzerreview; Bootstrap-State vorhanden und gespeichert, Version 0 beim Apply-Start -> aktuelle Version 1; kein State-Lock, keine pending Backend-Migration und kein separater Recovery-Upload. Damit ist das Vorhandensein eines gespeicherten Teilstates nachgewiesen, nicht dessen Ressourceninhalt, Integritaet oder Abgleich mit der Cloud.Die verbleibende Plansperre haengt am konservativen Recovery-Status. Ein freier Lock allein berechtigt nicht zum Umsetzen auf failed/entsperrt. Naechste sichere Stufe ist die geschuetzte Checkpoint-Pruefung und ein ausdruecklich freigegebener auditierter Recovery-Abgleich unter Beibehaltung des Teilstates. Die operative/UI-Funktion und Live-Abnahme bleiben offen. Kein Destroy, State-Reset, Import, Apply-Retry oder automatischer neuer Plan.
lweberru commentedon Oct 6, 2026
Local implementation: user-reviewed bootstrap recovery continuation
Local feature commit
cc77434(not pushed) adds the protected UI correction workflow requested after a failed bootstrap Apply:Evidence: canonical check 370 unit tests passed / 36 gated skips; all 34 isolated PostgreSQL Platform broker tests passed, including HTTP authorization, snapshot conflict, audit immutability, concurrent confirmation and corrected revision against retained state version 1; eight focused desktop/mobile mocked browser cases passed with DE/EN screenshots and overflow checks. Build/typechecks/editor diagnostics and root-staged Gitleaks passed.
Migration 034 has only run in isolated tests. Live customer DB/API and runner package remain unchanged; no customer checkpoint inspection, recovery confirmation, Plan or Apply has been executed by the agent. Activation requires an approved private backup, migration and API restart; the user will perform the actual inspection/confirmation in their own authenticated browser. Issue stays OPEN pending original recovery/S3/live acceptance requirements.
lweberru commentedon Oct 6, 2026
Approved local activation completed — user recovery actions remain explicit
The user approved a private backup, migration 034 and API restart. Activation is now complete. Evidence recorded in local documentation commit
0363972(not pushed):The user can now inspect and explicitly confirm retaining the existing checkpoint through their authenticated UI, then select a corrected preparation and request a fresh Plan against the same state. No automatic Plan/Apply, checkpoint decryption/confirmation, unlock, import, reset or destroy was executed by the agent. Actual user acceptance and original S3/other recovery requirements remain pending; issue stays OPEN. No push/release/merge.
lweberru commentedon Oct 6, 2026
Lokaler Recovery-Fix und Aktivierung: Commit 0fd12d0 auf feature/landing-zone-configurator, nicht gepusht. Benutzer meldet erfolgreiches Platform-Apply und erfolgreiches HTTP-zu-S3 init -migrate-state, danach state_failed in der UI. Mit dem tatsächlichen gepinnten OpenTofu-1.12.6-Runner wurde lokal reproduziert, dass die Migration eine neue Lineage und Ziel-Serial 1 erzeugt; die frühere Gesamt-Hash-Prüfung lehnte diese ansonsten exakte Kopie ab. Akzeptiert wird nun nur Vollgleichheit oder diese eng begrenzte native Metadaten-Transformation mit vollständig identischem übrigen kanonischen Inhalt. Die geschützte Checkpoint-Prüfung und separate Backend-Migrations-Bestätigung erlauben einen regulär beendeten state_failed mit gebundener offener Migration ohne erneuten Apply abzuschließen. Quellversion/SHA und exakter S3-Objektstand werden vor dem atomaren Backend-Wechsel und unveränderlichen Auditbeleg erneut geprüft; Locks, andere Inhalte, separate Recovery und unklare Abbrüche bleiben gesperrt. Kein S3-Schreiben, automatischer Apply, Unlock, Import oder Destroy. Nach frischem privatem Backup und Prüfung auf null aktive Jobs wurde ausschließlich die lokale API mit demselben unveränderlichen Runner-Paket neu gestartet, Application-Ausführung bleibt deaktiviert, keine Schemaänderung. Alle 33 bestehenden Tabellen einschließlich Recovery-Belegen blieben unverändert. API/Proxy health200, geschützte Guest-Routen401, deaktivierter Application-Runner404. Nachweise: kanonisches Gate 376 Unit-Tests, 42 isolierte PostgreSQL-Brokerfälle, 16 Backend-Tests einschließlich echter synthetischer lokaler Native-Migration, 12 Desktop-/Mobil-Browserfälle; Gitleaks0. Der tatsächliche Kunden-S3-State wurde vom Agenten weder gelesen noch bestätigt. Echte Prüfung und Bestätigung bleiben ausdrücklich Benutzeraktionen im angemeldeten UI. Issue bleibt OPEN: ursprüngliche Akzeptanzkriterien und Kunden-/Cloud-Nachweise sind damit nicht vollständig erfüllt.
lweberru commentedon Oct 6, 2026
Follow-up: Checkpoint-Klick des Benutzers liefert bisher nur die allgemeine Fehlermeldung. Lokaler Commit d5c6915, nicht gepusht, ergänzt kontrollierte DE/EN-Meldungen für abweichenden Migrationsinhalt, ungültigen State, fehlenden Checkpoint/Backend, unklare Migrationsbindung und ungültige Antwortstruktur. Keine Backend-, Freigabe- oder State-Änderung; keine Kunden-State-Leseaktion durch den Agenten. Bestehende S3/Bootstrap-Prüfung bleibt strikt. Nachweis: 376 Unit-Tests im kanonischen Gate und 14 Desktop-/Mobil-Checkpoint-Browserfälle, einschließlich mismatch/invalid und Unterdrückung privater Serverdetails. Aktueller UI-Build lokal aktiv, kein API-Neustart nötig. Exakter Fehler des Kundenlaufs weiterhin unbekannt: Benutzer muss nach Reload erneut Checkpoint prüfen und die nun konkrete Fehlermeldung nennen. Issue bleibt OPEN.
lweberru commentedon Oct 6, 2026
Export-Diagnose lokal verbessert in baf4925, kein Push/Live-Update. Read-only-Prüfung der bestehenden lokalen Laufzeit zeigt: erfolgreicher historischer Apply ohne applied_state_version; aktueller platform_state.version=5. Der strikte Export-Gate kann daher den Apply nicht dem aktuellen State zuordnen und lehnt vor dem State-Lesen ab. Zusätzlich ist pending_backend_id gesetzt (Backend-Übernahme ausstehend), migration_version=4. Keine aktiven Plan-/Apply-/Recovery-Jobs. Diese historischen Datensätze wurden ausdrücklich NICHT verändert; kein neues Apply und keine automatische State-/Backend-Freigabe. Recovery-/Zuordnungsabnahme bleibt offen. UI unterscheidet jetzt erlaubte Fehlercodes platform_contract_unavailable und state_failed in DE/EN; unbekannte Codes bleiben generisch, keine Ausgabe ungeprüfter Servertexte/State-Daten. Bestehender Export-Negativtest auf Desktop/Mobil erweitert: DE/EN, State-Lesefehler, proto, ungültige Nutzlast, Downloads=0. Canonical check erfolgreich (395 Unit bestanden, 45 umgebungsabhängig übersprungen), scoped Diagnosen 0 und staged Gitleaks 0. Laufender Login-only-Stand/Schema034/Runner-Pin unverändert. Hintergrundprüfung: nur Web/API benötigt; alte Server-IDs bereits beendet, ein altes registriertes Testterminal geschlossen, nur eigens gelabelten synthetischen PG-Testcontainer gestoppt (nicht gelöscht). Kundendatenbank und fremder Container erhalten; Web/API health200. Issue bleibt offen.
lweberru commentedon Oct 6, 2026
Root cause fixed and activated locally in 567288d: successful explicitly reviewed S3 recovery did not persist applied_state_version after migration increments the state version. New completion records the actual version atomically. Legacy completion can repair ONLY the same owner/run and original reviewed receipt, exact post-migration version, matching backend/migration refs, no lock/checkpoint ciphertext and unchanged remote identity verified by existing S3 reader. No new Runner/Cloud Apply/S3 writes. Regression RED/GREEN verified; 48 isolated PostgreSQL broker tests PASS, canonical check395PASS51gatedskip, scoped diagnostics0/Gitleaks0. Fresh private full DB backup restore-qualified across33tables. ONLY two Recovery hunks transferred to isolated login-only API; types PASS; active PID85705, schema034, same pinned native runner, Applicationfalse, web/APIhealth200. Existing data proof unchanged after restart. Real authenticated historical repair/export still pending: shared browser session expired (401; no unexpired DB session); no auth bypass, no repair POST yet. Requires user re-login; keep issue OPEN. No035/036 migration, push/merge/release. Own restore container removed, original DB and two needed services retained.
lweberru commentedon Oct 6, 2026
Contract-Export: zwei lokale API-Korrekturen qualifiziert und in der isolierten lokalen API aktiviert (kein Push/Release): 567288d ordnet erfolgreicher Recovery die tatsächliche post-migration applied_state_version zu; 79c483f liest den nativen platform_contract und behält den bisherigen Namen als Fallback. Die historische Zuordnung wurde nach echter Anmeldung über den geschützten API-Pfad erfolgreich repariert (HTTP 200). Private Tabellenprüfung bestätigt ausschließlich die erlaubte Run-Versionsänderung neben den Anmeldemetadaten; State, Backend und Recovery-Belege bleiben unverändert. Frisches privates Backup vorhanden.
Live-Akzeptanz weiterhin BLOCKIERT, nicht erledigt: GET outputs bleibt HTTP 409/platform_contract_unavailable, weil der tatsächliche State keinen Contract-Output enthält. Strukturdiagnose: 15 Ressourcen/16 Outputs; weder nativer noch alter Contract vorhanden. Die tatsächlich verwendete Accelerator-Revision a256f68 deklariert keinen platform_contract. Keine Vertragsdaten erfunden, keine Tenant-/Org-Gates gelockert, kein S3-Schreibzugriff, kein Cloud Apply, keine Source-Rebindung. Temporäre Diagnose vollständig entfernt. Migrationsstand 034, Applications-Ausführung deaktiviert, vorhandenes Platform-Paket unverändert.
Verifikation: alle 48 isolierten PostgreSQL-Broker-Tests bestanden; kanonisches npm run check: 395 bestanden/51 bewusst gated übersprungen, Typprüfung/Build ohne Fehler; Secret-Scan ohne Funde. Unabhängige Accelerator-Nutzung bleibt erhalten. Issue bleibt offen: Für den tatsächlichen Export braucht es ein ausdrücklich freigegebenes Upgrade-Preview für dieselbe Landing Zone/denselben State, danach einen neu gespeicherten echten Plan und separat die Freigabe exakt dieses Apply. Kein Upgrade oder neuer Apply automatisch gestartet.
lweberru commentedon Oct 6, 2026
Abschlusspräzisierung zur Live-Prüfung: Der letzte Check nach Entfernung aller temporären Diagnosen bestätigt API-Health HTTP 200, aber die Browser-Sitzung ist inzwischen nicht mehr authentifiziert (outputs HTTP 401). Die zuvor gültig authentifizierte Prüfung hatte HTTP 409 und strukturell den fehlenden Contract-Output bestätigt; die zugehörige Apply-Revision a256f68 enthält diesen Output nachweislich nicht. Daher weiterhin kein erfolgreicher Live-Export und kein Download-Akzeptanznachweis. Kein Auth-Bypass, kein neuer Apply, kein Upgrade/Rebinding durchgeführt. Finaler lokaler Commit 79c483f; beide qualifizierten Fixes laufen in der isolierten API.
lweberru commentedon Oct 6, 2026
Platform contract export: actual failure resolved (2026-10-06)
0487531binds the explicitly selected fixed acceleratorc4b43c36af198985980b17626c48d357795e3fbd, server-derived tenant namespace, and matching immutable native package. Existing configurations, old preparations and saved-plan artifacts were not rebound.7e24e966bd8c00d8e501eec584ada33f0b99526e385f45727d78d5e3bcecf2eb. Same S3 state: version 5 to 6, applied version 6, unlocked; saved configuration revision 2 unchanged.55d78ccaccepts bounded safe opaque STACKIT container references instead of wrongly requiring UUIDs. Tenant, organization, revision, current applied-state and sensitive-output gates remain strict. The UI validates the full API contract before exporting only the compatibility fields. Both temporary private structural diagnostics were removed.schema_version,organization_id,targets; native anchor click invoked. The integrated browser did not provide a download event/path, so OS filesystem receipt is unverified. Separate ordinary Playwright desktop/mobile download tests passed.Issue remains OPEN. The real partial-failure/hard-runner-loss, interrupted-worker reconciliation, serialization across direct operational paths, interrupted migration/recovery and remaining operator acceptance criteria are not closed by this export.
fix(configurator): explain recovery plan blocker (#90)
feat(configurator): reconcile reviewed bootstrap checkpoints (#90)
docs(configurator): record approved recovery activation (#90)
fix(configurator): verify native HTTP to S3 migration (#90)
fix(configurator): explain checkpoint verification failures (#90)
fix(configurator): preserve complete checks across state migration (#90)
fix(configurator): explain unavailable platform contract exports (#90)
fix(configurator): retain reviewed recovery state provenance (#90)
lweberru commentedon Oct 10, 2026
Local qualification update — 2026-10-10 (#90)
Application recovery diagnosis, immutable original-approver review receipts (new migration 051) and read-only reconciliation metadata (052) are locally implemented and qualified. Start-unresolved, completion-unresolved, failure and recovery-state-required are distinguished. Current tenant/session/PE/human identity, revocation, snapshot hashes and idempotent review replay are enforced.
Runner stop, actual cloud credential revocation, state lock and cloud state remain explicitly unknown; authorizesExecution stays false. A review receipt does not unlock, retry, push state or correct a job to success. Reports and historical bindings remain immutable.
Evidence: 31 real isolated PostgreSQL cases including fault injection and revocation, strict contract/HTTP checks, desktop/mobile DE/EN recovery cases and final 278 browser suite; canonical app check 436 unit passes (53 gated skips). The latest full PostgreSQL run used --testTimeout=30000; the default 5-second budget timed out a separate platform-contract case and cascaded into a later session assertion. Final CI timing still needs qualification.
User API/database remain at migration 050 without review opt-in. No user DB rollout, cloud/state mutation, release or push. Fresh live adapters, explicit recovery operation, hard-runner-loss/restore and full Platform migration/follow-up-plan acceptance remain outstanding. Issue remains open.
lweberru commentedon Oct 16, 2026
Implementation and final source-validation evidence are consolidated in #102: encrypted saved-plan/approval binding, durable bootstrap/recovery contracts, source/state/credential checks, explicit migration handling and stateful broker regressions are included.
Operational acceptance is not being replaced by mocked tests. This issue remains open for real partial failure/hard runner loss, management-backend migration and credential switch, interrupted recovery, safe follow-up Plan, and backup/restore acceptance. Operator CI mutations are serialized; that is not proof of native S3 locking against arbitrary direct CLI writers. No customer Apply, forced unlock or recovery mutation was performed for the MVP source merge.
lweberru commentedon Oct 17, 2026
Apply availability diagnostics are now live in Development through #109–#114 and successful manual release 38986171056, source
3ab7bfaa92236fc4a4242028a27a901df0c1496dverified in both API and Runner.Expected server eligibility denials are surfaced on Plan and Apply rather than discarded; a blocked action remains visibly disabled. Eligible saved plans still require explicit unchecked approval plus the exact target-organization UUID. Hosted direct links/reload now work. Isolated PostgreSQL eligibility/replay/error checks passed 60/60; the complete browser suite passed 308/308, with additional hosted synthetic desktop/mobile approval checks.
No customer Apply, state migration, interrupted-worker recovery or backup/restore acceptance was performed. The historical customer denial remains unverified; no capability gate was relaxed. This is diagnostic/UI delivery, not completion of the open operational criteria in this issue.