Repository navigation
Configurator MVP: provision isolated application instances from platform contracts #93
Description
Source and release checkpoint (2026-10-23)
#135 merged after all 13 CI checks passed. Published recovery migration 064 remains unchanged; new source/identity migrations follow as 065/066. The user-authorized qualified Dev release 39925017270 stopped before build/deployment because the repeated real-model suite failed the same DNS completion case twice (122/124 passed); the continuous journey passed. Current Dev therefore remains on #136. A bounded DNS intent correction is under investigation; no release guard is bypassed and no new cloud qualification is claimed.
#141 is also merged: isolated Compose database restore and deterministic local native interruption CI passed. First-Apply local-State completeness remains separately open in #140; hosted Runner/S3 and complete-service recovery are not established by those local fixtures.
Public Application acceptance (2026-10-23)
The user reports successful creation of a Public Application Landing Zone including an Observability instance. Both the real Plan and Apply succeeded on the first attempt. Together with the Corporate acceptance and same-order partial-Apply recovery already recorded in #93, both Public and Corporate provisioning paths now have positive real-user acceptance. This does not qualify the effective-egress Observability ACL feature in #96, Automatic Corporate IPv4 in #135, cross-instance lock contention, upgrades, quotas or hard worker-loss/restore behavior. No customer Plan/Apply was executed by the agent.
Current implementation and acceptance scope (2026-10-22)
Corporate Application provisioning and recovery from a reported partial Apply failure have now succeeded in Dev. The user published a source-bound Corporate template, ordered it as an Application Owner, and completed the real Plan/Apply flow. After the earlier routing-table creation timeout, the checkpoint-based self-service path introduced in #136 allowed a fresh Plan in the same existing order. That Plan refreshed 12 retained resources and proposed only the three missing resources. The subsequent user-executed Apply completed with 3 added, 0 changed, 0 destroyed. The existing project and instance State were retained; no replacement order or empty State was required. The earlier statement that the Corporate failure cause was unknown and cloud acceptance remained blocked is superseded by this result. The timeout did not recur; this is not proof of its upstream root cause or of general timeout handling.
The user subsequently confirmed Internet/DNS connectivity after manually configuring outbound NAT, and external SSH through a manually configured firewall port forward after attaching the VM SSH security group and creating the missing guest user with its authorized key. This demonstrates the manual firewall-administrator handover for the tested Corporate instance. It does not qualify automated firewall policy, all-traffic enforcement, removal of direct VM public access, HA policy synchronization/failover, or negative isolation tests; see #101 and #65.
Current Dev deployment: #136, source 3d2f0af26e5bac23f23ff7c462cff1cec0f165b7, release 39767149101. The separately authorized release used dev-skip-assistant-qualification, Runner pool size 1 and build_only=false. Build/publication/deployment, migrations and isolated cold/warm Runner probes passed. Read-only runtime checks confirmed health/access boundaries, Assistant enabled and Application execution enabled. This release intentionally skipped live Assistant qualification; normal qualified-release guards remain unchanged. Existing Application packages retained the reviewed Accelerator source 9e7fb46c329aca32e878ce1f0ea3b944ea240354.
The confirmed Corporate run used an explicit network prefix. Automatic IPv4 selection and post-login identity completion tracked in #135 (subsequently merged; see the current release checkpoint above) are not accepted or deployed by this evidence. No customer Plan/Apply or firewall/VM configuration change was performed by the agent; the real operations and connectivity confirmations above were performed/reported by the user. No production action was performed.
The deployed Dev runtime has Application execution enabled. The Application root, isolated Runner integration, delegated Plan/Apply endpoints, bounded grants, instance-specific S3 State keys, saved-plan artifacts and recovery APIs already exist. Earlier statements below that Application execution is globally disabled are historical. executionEnabled: false in compiler/preview/prepared-job responses means those calls do not themselves perform a cloud operation; actual execution capabilities are reported separately.
A successful real Platform Apply and HTTP-to-S3 migration are documented in #90. This does not qualify Application provisioning. Live testing exposed the older API restriction to Public projects with a local network, even though the native Application root supports broader project foundations.
PR #131 removes that blocker for new source-bound template versions: Public with or without local networking and Corporate using the approved SNA target, each with optional Secrets Manager and Observability. It pins the Application package to reviewed native source 9e7fb46c329aca32e878ce1f0ea3b944ea240354, extends exact SQL source allowlists through migration 061, and retains immutable existing publications/orders/State bindings. It also explains missing personal organization proof, template draft selection and unsupported services in the UI. PR #131 merged as 54d9eba0c7fcf809692d9df5713db937ddb66a99. PR #132 subsequently merged as 4315a86f3ee8422dd591ea139efc7a5ef498e97f, fixing only the bounded Runner package-test budget and documenting the confirmed Platform-Kubernetes-only Namespace boundary. Those changes were first deployed in Dev through the explicitly authorized qualified release 39678187447. All four release jobs succeeded: live Assistant qualification (118/118 repeated cases and 13/13 continuous journey), build, immutable buildpack publication and deployment. Versioned database migrations and the isolated image, Platform engine and Application engine probes passed. Runtime checks confirm LZC_RUNNER_POOL_SIZE=1, LZC_ASSISTANT_ENABLED=true and LZC_APPLICATION_EXECUTION_ENABLED=true. The isolated Runner probe passed both cold execution and warm-pool reuse; public health/access and desktop/mobile guest checks passed against changed deployed assets. This is Dev deployment/runtime evidence, not a real Application cloud Apply.
Remaining acceptance
- Merge feat(configurator): enable Public and Corporate application orders #131 and obtain separate authorization for a qualified Dev release with Runner pool size 1.
- Review and merge fix(ci): budget Runner package inspection and clarify Namespace scope #132; complete a fresh qualified Dev release/runtime verification with Runner pool size 1.
- Publish a new Corporate template against the released Application source and create an acceptance order without rebinding existing orders or saved Plans.
- Complete the equivalent Public template/order acceptance: user reports first-attempt Plan/Apply success including an Observability instance (2026-10-23).
- Complete a real user-executed Corporate Application Plan/Apply and same-order checkpoint-based recovery after a reported partial Apply failure, retaining existing resources and State.
- Complete real Public Application Plan/Apply, including an Observability instance.
- Qualify cross-instance State separation, locking contention and concurrent cloud retries without duplicate projects.
- Qualify least-privilege provider/API behavior and live grant expiry/revocation; see Configurator MVP: verify organisation tenants and STACKIT user bindings #91 and Create projects without default owner role #69. Job-bound credential access does not reduce the underlying cloud IAM permissions.
- Enforce quotas and verify concurrency/idempotency against actual cloud project creation.
- Support explicit instance upgrade Plans while new template publications leave existing instances unchanged.
- Demonstrate recovery from the reported Corporate partial Apply failure through checkpoint verification, a fresh Plan and successful Apply.
- Qualify interrupted/lost workers, additional failure modes and backup/restore; preserve platform/customer State boundaries.
Namespace services have always belonged exclusively to Platform Kubernetes in the Accelerator and are excluded from Application project ordering. Centrally managed Platform Kubernetes inside an SNA requires the later private execution/reachability work in Feature: Private/SNA SKE cluster support with two-stage runner model #37 (and regional targeting in Support explicit regional cluster targeting for landing-zone namespace services #80 where relevant). Namespaces inside an Application-owned cluster belong to its workload, not an Application Landing Zone Namespace Building Block. Possible future Building Blocks layered on Application Landing Zones are a separate, much later product decision; they are not an acceptance dependency here. Symbolic Observability network-ACL bindings remain blocked under Qualify effective egress-source bindings for application Observability ACLs #96.
Local evidence for #131: 997 unit tests; 51 real isolated PostgreSQL identity/Application cases; 63 platform/state/recovery cases; 108 desktop/mobile organisation cases plus 10 catalogue regressions after new assertions; 16 native Application tests, 9 project-module tests and 28 tests on the exact pinned source (including 12 compiler-produced Public/Corporate/region/Observability combinations). The full local Linux Runner package and package source identity were verified. This is implementation/mock/isolation evidence, not a real Application cloud deployment.
No production action or new customer infrastructure operation was performed as part of this implementation. This issue remains open for the criteria above.
The checkpoints below are retained as history and do not override the current scope above.
Historical status (2026-10-06)
The versioned non-secret platform-contract producer/import and durable application orders now exist. The earlier claim that there is no producer or persistent caller is obsolete. Application cloud execution remains disabled (executionEnabled: false): a validated Plan input/state key is not a real Plan, deployment or state file.
- Produce/import versioned non-secret platform contracts with approved folders/regions/SNAs/service references and explicit PE approval bound to verified human identity and tested SA access.
- Persist each application order, immutable published template/contract version, trusted owner, strict inputs, policy and separate reserved backend key.
- Revalidate tenant/organisation/platform revision, role, identity and ownership when producing deterministic application Plan input. Never expose full platform state.
- Integrate the reviewed application root into the approved native runner artifact and actual dispatch with least-privilege, bounded job grants.
- Make ordering durable and idempotent so double clicks/retries do not duplicate orders.
- Enforce quotas and prove retries cannot duplicate real cloud projects.
- Persist/enforce direct versus approval-required policy server-side (Configurator MVP: publish immutable application templates per tenant #92), preserving explicit customer-Apply approval during rollout. Migration 022 is locally activated with immutable version/instance snapshots and compiler binding; Application execution and real cloud acceptance remain disabled/outstanding.
- Support explicit upgrade Plans without changing existing instances on new template publication.
- Prove distinct platform/application state ownership, real backend locking and failure/recovery behavior.
- Complete a separately approved real application cloud Plan/Apply acceptance; no claim of execution from preview/compiler output alone.
Historical evidence and next step
Sources: src/application/, landing-zone-configurator/app/apps/api/src/applications/, contracts/domain application compiler, associated unit/PostgreSQL/browser tests. Contract and Plan-input documentation: landing-zone-configurator/docs/plan-execution.md.
The active Platform runner is pinned to Accelerator commit c4b43c36af198985980b17626c48d357795e3fbd. This is not activation or cloud qualification of the separate Application runner; old plans/packages were not rebound. Current local work is not automatically released. Next: reviewed application-root packaging and bounded dispatch/state integration, before cloud qualification and quotas/upgrades.
Historical publication and source acceptance (2026-10-06)
The current successful Platform Apply exports the real non-secret contract and is approved through the protected server-derived workflow. Existing Public template version 1 is published with that contract, public-eu01, default Application Owners access and approval-required policy. The Apply selector now shows the frozen configuration name plus completion date instead of a state-key hash. Only current successful/unlocked tenant-scoped Applies with valid human proof remain selectable; owner proof can be renewed after binding.
Application execution remains explicitly disabled. Publication is not a real Application Plan or Apply. Quotas, explicit instance upgrade Plans, real distinct state/locks and failure/recovery, least-privilege bounded dispatch and separately approved cloud acceptance remain open.
Local-only commits: a8447b6 (#91), 53b806b (#92), 798661a (#93). Final validation: 403 unit tests, 30 real isolated identity/PostgreSQL cases, 49 platform broker cases and all 32 desktop/mobile management/publication/proof flows passed. Schema 039 activated after fresh private backup, full restore, repeated migration and unchanged operational-table verification. No push, merge, release or new Application cloud execution.
Dependencies
Durable Apply/state (#90), verified tenants/job grants (#91) and published template policies (#92). No automatic migration of existing monolithic state, autonomous Apply or shared platform-state exposure.
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 5, 2026
Local Application Runner Checkpoint (2026-10-05)
The current feature work was checkpointed locally as 4ad9367 and additionally saved in a verified full Git bundle outside the synced workspace. The application source pin is 4d15d78; worker/package/documentation changes are local commit 21801fd. These commits have NOT been pushed or released.
Implemented and locally qualified:
Evidence: canonical check 346 passed/33 gated skipped; focused worker 80 passed/1 gated skipped using a controlled engine; real OpenTofu native mock tests 14 application + 3 network passed. A fresh Darwin ARM64 package actually passed backend-free init/validate with readonly lock and signed provider mirror. Package SHA-256: 848c402a75ba8906abd958158044ba07cda2dfbb6f7fe14353048a157c9cb0d1. Gitleaks found no secrets in staged commit content; editor diagnostics clean.
This does NOT satisfy the complete runner/dispatch criterion: executionEnabled remains false. Persisted instance jobs, PE-authorized bounded application credential grants, real backend locks, quotas/cloud retry idempotency, explicit upgrades, Linux runtime and separately authorized live Plan/Apply acceptance remain outstanding. New template versions must explicitly use the new application pin; existing versions/plans are not rebound. API/customer DB/active runner unchanged, no customer credentials or cloud operations used. Browser/PG were not rerun in this UI/SQL-free slice (previous evidence 152 browser and 31/29 PG). Issue stays OPEN and mvp:required.
lweberru commentedon Oct 5, 2026
Prepared Application Jobs / Grants Checkpoint (2026-10-05)
Local issue-specific commit: ad4842f. A verified full Git bundle additionally preserves this revision outside the synchronized workspace. No code push or release in this step.
Migration 026 and HTTP/service boundaries now implement explicit idempotent prepared application Plan jobs, SQL-derived immutable grant snapshots and monotonic revocation by requester or current approving PE. New publications must explicitly select the reviewed application source revision; this creates a new immutable template version, while old versions/default remain unchanged. Arbitrary source revisions and caller credential overrides are rejected.
Actual SQL guards validate the live issuer session, verified tenant organization, approving PE membership, requester identity/owner, version/policy and bounded expiry. App role cannot read the sessions table or directly insert/rebind grants. Job responses contain only metadata and executionEnabled:false/cloudPlanExecuted:false; there is no credential or ticket output and no runner dispatch.
Evidence: canonical lint/types/build + 346 unit passed/33 gated skipped; 29 real PostgreSQL identity/application cases extended with source-version, job/grant/idempotency/RLS/revocation and actual Fastify auth/origin/CSRF/tenant/strict body tests; all 31 real platform-broker PostgreSQL cases under the new migration pass. Editor diagnostics clean; staged Gitleaks scan clean. No UI change/browser rerun; prior browser evidence 152. Customer migrations 021-026 not activated, no API/native restart, no customer Plan/Apply.
Issue remains OPEN and mvp:required. Next is one-time credential release under current PE/profile authority plus explicitly approved instance S3 backend/lock binding and dispatch. A prepared grant record is not a real cloud credential release/state/Plan. Quotas/cloud retry safety, explicit upgrades and separately approved live acceptance remain required.
lweberru commentedon Oct 5, 2026
Weiterer lokal qualifizierter #93-Schritt: Commit e7cbe63 bindet vorbereitete Application-Jobs nach expliziter PE-Freigabe an ein registriertes Tenant-S3-Backend mit festem applications///terraform.tfstate-Key und Lockfile. SQL prueft aktuelle Rollen, echte Sessions und Human-Identitaeten; Freigabe ist immutable, sessiongebunden, begrenzt und wird durch Retry nicht verlaengert. AO erhaelt nur einen nicht geheimen Beleg, keine Backend-Credentials. HTTP prueft Session/Origin/CSRF/Tenant/strikte Bestaetigung. Parallele Freigaben idempotent; Backend-Wechsel 409, widerrufener oder abgelaufener Grant gesperrt. Gates: canonical 346 pass/33 gated skip, 29 erweiterte echte isolierte Identity/Application-PG-Faelle, 31 echte Plattform-Broker-PG-Faelle unter Migration 027; staged Gitleaks sauber. Vollstaendiger Feature-Branch zusaetzlich als externes verifiziertes Git-Bundle gesichert. Kein Push, Live-Migrations-/API-/Paketwechsel, Cloud-Plan/Apply oder S3-Zugriff. #93 bleibt OPEN/mvp:required: einmalige Credential-Ausgabe, Runner-Dispatch, echter State/Lock, Cloud-Abnahme, Quoten und Upgrade-Pfad sind weiterhin offen.
lweberru commentedon Oct 5, 2026
Naechster gesicherter lokaler #93-Commit: 50e0e76 implementiert Migration 028 und einen internen einmaligen Claim fuer den vorbereiteten Application-Grant. Nur die tatsaechliche aktuelle PE-Backend-Freigabesession darf claimen; keine AO-PE-Impersonation. Revalidierung aller 027-Grenzen, atomare Grant-Zeilensperre und immutable Verbrauchsbeleg. Zwei konkurrierende Claims: genau ein Erfolg. Claim/Widerruf-Rennen: genau eine Aktion erfolgreich, niemals beides. Andere echte PE-Session, abgelaufene/widerrufene Freigabe, direkter INSERT/DELETE und Consume-Replay abgewiesen. Widerruf nach Verbrauch explizit 409; Job-Vorbereitungs-Replay meldet nicht erneut prepared. Kein Browser-/Runner-Claim-Endpunkt (HTTP404 getestet), keine Secret-Ausgabe oder Runner-Start. Gates: canonical 346 pass/33 gated skip, 29 bestehende erweiterte echte Identity/Application-PG-Faelle, 31 echte Broker-PG-Faelle unter 028, Editor-Diagnostik0, staged Gitleaks sauber. Vollstaendiges externes Feature-Git-Bundle verifiziert. Kein Push, API-/Runner-/Kundendatenbankwechsel, Cloud-/S3-Zugriff oder Apply. #93 bleibt OPEN/mvp:required: Credential-Pruefung/Ausgabe/finale Autoritaetskontrolle und ticketgebundener Dispatch, reale State-/Lock-/Cloud-Abnahme, Quoten und explizite Upgrades fehlen weiterhin.
lweberru commentedon Oct 5, 2026
Neue verbindliche Architekturgrenze lokal umgesetzt und gesichert: Commit c4b43c3 (lokaler Feature-Branch) erhaelt den Accelerator als unabhaengiges CLI-Produkt; Configurator ist optional, keine notwendige API/DB/Session/Template Engine. Der Plattform-Root kann fuer NEUE Plattformen ohne Application-Instanzen betrieben werden und exportiert einen nicht geheimen platform_contract (Org/Folder/Region/SNA/Next-Hop/Nameserver, deterministische UUID-Revision, CLI-Namespace standardmaessig Org). Manuell aufgeloestes Application-JSON und S3-Backend-Beispiel inklusive separatem State/Lock/normalen Credentials und explizitem Saved-Plan-Apply sind dokumentiert. Herkunft: landing_zone_accelerator=true immer auf label-faehigen Ressourcen; landing_zone_configurator=true zusaetzlich fuer Configurator-Inputs. CLI-Application default ohne Configurator-Marker; Kundenlabels erhalten. Labels sind keine IAM-Grenze/Audit-Signatur. Bestehende Quell-Pins, Pakete, Publikationen und States nicht umgebunden. Eigenstaendige Accelerator-CI testet Application-Root. Lokal: canonical348 pass/33 gated skip, 8 native Plattform/Public/Corporate/eu01+eu02-Mocks, 16 native Application-Mocks mit manuellem JSON und beiden Herkuenften, 3 Netzwerk-Mocks, 29 Identity/Application-PG und31Broker-PG; Terraform fmt rekursiv PASS. Vollstaendiger Commit-Secret-Scan vom Repo-Root: 1 Commit/25KB/keine Leaks; komplettes externes Git-Bundle verifiziert. Kein Push, API-/Kundenbackend-/Paketwechsel oder realer Cloud-Apply. OPEN/required bleibt: reale Zwei-Phasen-CLI-/S3-/IAM-Abnahme und bestehende State-Migration, explizite neue Application-Source/Paket-Qualifizierung, eigentliche Credential-Ausgabe/Dispatch, Quoten und Upgrades. Die bestehenden Gesamtkriterien werden nicht gestrichen.
lweberru commentedon Oct 5, 2026
Lokaler Fortschritt im Feature-Branch:
39fd7d0(kein Push, keine Aktivierung).c4b43c36af198985980b17626c48d357795e3fbdist explizit qualifiziert: neue immutable Publikationsversion und eigener Grant-Snapshot. Alte Versionen/Jobs bleiben unverändert; der neue Worker lehnt Altjobs auf dem neuen Paket ab.runner-local-20261005-application-cli.tar.gz, SHA-256bd87f44d1bafa0a3c9d974c735aa1edfd70add08d8ad9f1e503500bbe8af8aa7. Native Init/Validate, readonly Application-Lock und signierter Provider-Mirror bestanden (darwin_arm64/OpenTofu 1.12.6; kein Linux-/Cloud-Nachweis).releaseJobCredential: nur die originale echte PE-Freigabesitzung, einmaliger Claim vor technischer Credential-Prüfung/Vault-Zugriff, feste Source-/Profil-/Secret-Version/Key-ID/Service-Account-Bindung und erneute SQL-Live-Autorisierung unmittelbar vor Rückgabe. Kein synthetischer PE und keine AO-Credential-Freigabe.Nachweise: kanonischer Lint/Types/Build-Gate und 349 Unit-Tests bestanden; 33 umgebungsabhängige Fälle bewusst übersprungen; 29 erweiterte Identity/Application- und 31 Platform-Broker-Fälle in isoliertem echten PostgreSQL bestanden; Worker 81 Fake-Engine-Fälle/1 native-gated skipped. Keine UI-Änderung, Browser-Suite nicht erneut ausgeführt. Secret-Scan ohne Befund.
#93 bleibt offen. Diese interne Freigabe ist noch kein Runner-Ticket, Dispatch oder Cloud-Plan. Weiter fehlen reale Instanz-State-/Lock-/Recovery-Abnahme, Quoten, ausdrückliche Upgrade-Plans und separat freizugebende Cloud-Plan/Apply-Abnahme.
executionEnabled:falsebleibt bestehen. Keine Kunden-Credentials/-Daten/-Backends gelesen; Kunden-API, aktives Paket, gebundene Kundenplans und alte Publikationen unverändert. Migrationen nicht live aktiviert, kein Cloud-Plan/Apply, State-Migration, Release oder Merge. Der Accelerator bleibt ohne Configurator nutzbar.lweberru commentedon Oct 5, 2026
Weiterer lokaler Teilstand im Feature-Branch:
538d79c(kein Push/keine Aktivierung).runnerInput: Ticket/Grant-Verbrauch vor technischem Zugriff; immutable Job-Variablen plus freigegebener S3-Instanz-Key/Lockfile; vorhandener HCL-Serializer und S3-Broker; erneute Live-Autorisierung nach S3-Credential-Freigabe. Ausschließlich application-plan, kein Apply/Bootstrap/Plattform-State. Backend-Abweichung oder Rechteentzug liefert keinen Input zurück.Nachweise: 349 Unit-Tests/33 bewusst gated skipped plus Lint/Types/Build bestanden; 29 erweiterte echte isolierte Identity/Application-PostgreSQL-Fälle und 31 Platform-Broker-PostgreSQL-Fälle unter 031/032 bestanden. Dispatch-Tests verwenden einen Fake-Runner und Vault/Cloud/S3-Credential-Mocks, keinen echten Application-Prozess oder Cloud-Plan. Root-staged Secret-Scan ohne Befund. Vollständige private externe Branch-Bundle-Sicherung verifiziert.
Noch keine aktive Application-Ausführung. Produktionsverdrahtung enthält keinen Application-Runner; kein HTTP-Start-/Ticket-/Credential-Endpunkt. Report-/Artefakt-/Result-Anbindung und Operator-Reconciliation sind noch zu implementieren, bevor native/Cloud-Aktivierung überhaupt geprüft werden kann. Quoten, Upgrade-Plans und reale State-/Lock-/Recovery-Abnahme bleiben offen. Deshalb bleiben ursprüngliche Dispatch-/Cloud-Kriterien und #93 insgesamt offen; executionEnabled:false unverändert.
Migrationen 021–032 nicht live aktiviert; aktive Kunden-API, Runner-Paket, Kundenplans und CLI-Unabhängigkeit unverändert. Keine Kunden-Credentials/-Daten/-Backends gelesen, kein Cloud-Plan/Apply, State-Migration, Push, Release oder Merge.
lweberru commentedon Oct 5, 2026
Lokaler Zwischenstand 2026-10-05, Commit 975cc94 (nur lokaler Feature-Branch, kein Push/Release/Merge):
Evidence: npm run check PASS (lint/types/build,370unit pass/33environment-gated skip); expanded isolated identity/catalogue/policy PostgreSQL29PASS; existing platform broker/state/grant PostgreSQL31PASS; focused worker84PASS/1nativeSkip, HTTP21PASS, local process8PASS/1nativeSkip; repo-root staged Gitleaks0. No browser or current Application native-runtime rerun; existing older source/root/package native proofs do not prove this new broker transport. Full verified private Git bundle retained.
Active API, package, customer DB/state and Cloud resources were NOT changed. Original criteria remain open: fresh native package qualification/approved activation and real Application Plan/Apply/state locking, owner plan visibility, quotas, explicit upgrades, operator reconciliation/recovery and live acceptance. #93 remains OPEN; this is not a feature-parity or Cloud sign-off.
lweberru commentedon Oct 5, 2026
Label-Korrektur vor Cloud-Apply, 2026-10-05: local feature commit fb334a0, no push/release/merge.
User-supplied saved bootstrap plan shows management project labels only managed_by=opentofu. Both canonical compilers already add landing_zone_accelerator=true and landing_zone_configurator=true. Known active API process started Oct4, before that change. The pinned older Terraform root passes var.labels to the unchanged management project resource; source pin alone is not the cause.
Fix: NEW preparation must bind exactly serializeTfvars(recordValues(saved document)); legacy or modified exports without either mandatory label cannot produce a new preparation. Tests cover legacy/common/platform documents and absent/false provenance. Native existing standalone test now checks actual planned management project labels plus preserved customer label (not only root locals), with mocked STACKIT/Vault/Time.
Evidence: 27focused compiler/preparation tests PASS; npmruncheck lint/types/build +370unit PASS/33gatedskip;31isolated platform broker PostgreSQL PASS; native credential-free init/validate +9mock tests PASS;editor0;root-staged Gitleaks0; full private verified provenance-preparations.bundle retained.
Active API, database, package and saved plan unchanged; no Cloud action. No rewriting/rebinding old plan. Fresh preparation and Plan of SAME configuration needed after activation; do NOT apply checksum c496daff4861c86eccabba14a8a2bdb34488d06911ead28ced4c35d9ea7ca75a. Runtime activation via local startup would also apply pending migrations021-033, so separate explicit approval + private customer DB backup required before doing that broader step. #93 remains OPEN.
lweberru commentedon Oct 5, 2026
Label-Korrektur: freigegebene lokale API-Aktivierung (2026-10-05)
landing_zone_accelerator=trueundlanding_zone_configurator=trueverbindlich; Kundenlabels bleiben erhalten. Die zuvor dokumentierten nativen Management-Projekt- und kanonischen Vorbereitungstests gelten weiterhin.Lokale Commits:
fb334a0(Label-Bindung) und8e4e39c(Aktivierungsnachweis). Kein Push/Release/Merge. #93 bleibt OPEN: echte native Application-Broker-/State-/Lock-/Cloud-Abnahme, Owner-Planansicht, Quoten, explizite Upgrades und Recovery/Reconciliation sind dadurch nicht erledigt.17 remaining items
lweberru commentedon Oct 10, 2026
Local qualification update — 2026-10-10 (#93)
Extended the existing real PostgreSQL order-idempotency test: eight parallel repeats through a new Applications service and separate runtime pool return the same frozen instance, settings and state key, leaving exactly one order. Existing publication does not change earlier instance bindings.
Evidence: all 31 real isolated identity/PostgreSQL cases pass with --testTimeout=30000; targeted Biome and full typecheck pass. Single-case selection lacks shared earlier identity fixtures; full suite is required. Default 5-second timeout remains a final-CI qualification risk as documented in mvp-acceptance.md.
This proves durable ORDER idempotency, not real CLOUD PROJECT idempotency. Quotas remain unimplemented and must use an authoritative tenant-wide view rather than an Application Owner RLS-filtered count. Explicit instance upgrade Plans, approved current runner dispatch, real distinct state/locks, least-privilege and separately authorized Cloud Plan/Apply/recovery remain open. No runner or cloud project was started, no user database migration/rollout occurred. Issue remains open.
lweberru commentedon Oct 16, 2026
The reviewed source implementation is included in #102: immutable template/contract/instance bindings, strict deterministic Application inputs, ownership and separate backend identity, idempotent ordering and native Runner contracts are covered by the Configurator/native integration checks.
This issue remains open until actual Application cloud execution is separately accepted, including effective provisioning permissions, quotas and retry/no-duplicate behavior, upgrades, distinct state ownership/locking and interrupted recovery. Native export, a preview or a mocked dispatch is not a successful real Application Plan/Apply. The MVP integration creates no production environment and performs no customer Apply.
lweberru commentedon Oct 21, 2026
Next acceptance step after successful platform Apply (2026-10-21)
The operator completed a real platform saved-plan Apply, including both firewall HA bootstrap steps, project-qualified management buckets, Observability and HTTP-to-S3 State migration. The Apply emitted a non-secret platform contract. See #90 for sanitized evidence and remaining operational limits.
The next requested scope is testing the Application Owner role and Application Landing Zone templates: verify current platform-contract approval/import, published immutable template versions, visibility/role boundaries, parameter validation and durable application orders. A successful platform Apply does not itself approve or publish a template.
The currently released Application service still reports
executionEnabled: false. Template selection, orders and deterministic Plan inputs must not be described as actual Application cloud Plans or Applies. Application-root runner integration, bounded dispatch grants, distinct State/locking, quotas/upgrades and separately approved cloud execution remain open. No Application infrastructure Apply or production action is authorized by this update.The old platform-runner pin in the historical issue text is superseded: Dev release 39608332090 uses native Accelerator
9e7fb46c329aca32e878ce1f0ea3b944ea240354. This does not activate Application execution.lweberru commentedon Oct 21, 2026
PR #131 is now ready for independent review on
3047e05fa75cc41a13e9fa994b81b41ef6167031. All applicable GitHub checks pass, including native contracts, PostgreSQL isolation/migrations and all 312 desktop/mobile browser cases: https://github.com/stackitcloud/stackit-landing-zone/actions/runs/39635678637 . A fresh shallow checkout also successfully fetches and tests the exact reviewed Application source. Protected main still requires review; no merge or deployment has been performed.feat(configurator): enable Public and Corporate application orders (#131
lweberru commentedon Oct 21, 2026
PR #132 is ready for independent review on
67bb5daa28bb699ccb6c00ac179cc3a8b7ea0a2c. All applicable CI checks pass, including the repaired real package-inspection test, native contracts, PostgreSQL isolation/migrations and all 312 desktop/mobile browser cases: https://github.com/stackitcloud/stackit-landing-zone/actions/runs/39654012523 . No model or production timeout/assertion changed. The failed release remains recorded; Dev is healthy and unchanged. The already authorized qualified Dev release will continue after review/merge, with a fresh source-bound qualification.fix(ci): budget Runner package inspection and clarify Namespace scope (…
lweberru commentedon Oct 21, 2026
Qualified Dev deployment completed successfully after independent review/merge of #132.
4315a86f3ee8422dd591ea139efc7a5ef498e97f;release_mode=qualified,runner_pool_size=1,build_only=false.SUCCEEDED, Runner pool1, Assistant and Application execution bothtrue.The Public/Corporate implementation is now available in Dev. Publish new immutable template versions and create new orders against the released source; existing publications/orders/State bindings were not rebound. Real Public/Corporate Application cloud Plan/Apply acceptance remains outstanding and requires its own user approval. Namespace services remain exclusive to Platform Kubernetes and excluded from Application project ordering (#37).
No production deployment or customer infrastructure Apply was performed. This tracker remains open for the listed acceptance criteria.
lweberru commentedon Oct 22, 2026
Real Application acceptance remains blocked: a newly published Corporate template reaches a dispatched Plan job but reports
plan_failed. The authorized requester could read only the first package-verification startup line from its retained output. The underlying OpenTofu error is not available, so Corporate cloud execution is not accepted as working.PR #134 repairs two independently demonstrated diagnostic defects: the UI exposes logs only for Apply, and immutable Application report storage accepts the first startup snapshot but rejects every changed progress/failure snapshot. Migration 063 permits only content/hash/truncation changes for exact-bound active output records through existing authorization; immutable artifacts/recovery/metadata and terminal output remain protected. The UI exposes requester-only Plan/Drift/Destroy logs and selects a newer Destroy Plan rather than an older Apply. Application workers publish redacted progress while executing.
Local validation: full check 1,000 passed/71 environment-gated skipped; real isolated PostgreSQL identity/Application suite 51/51; full desktop/mobile organization/Application browser suite 112/112. Independent code/security review found no blocker; the noted Destroy retry-log selection edge was fixed and regression-tested. GitHub CI is running. No deployment or customer infrastructure operation was performed for this correction. Prior rejected output cannot be reconstructed from its first stored snapshot; further root-cause qualification needs correctly retained diagnostics.
Archive/catalogue separation and safe deletion of never-ordered retired template versions are separately reviewed in #133. Neither change closes the outstanding real Public/Corporate acceptance criteria here.
lweberru commentedon Oct 22, 2026
Dev deployment completed after review/merge of #133 and #134.
81da93ae9b8489f60577960ba0a0535a8e4765fa; release https://github.com/stackitcloud/stackit-landing-zone/actions/runs/39739649550dev-skip-assistant-qualification,runner_pool_size=1,build_only=false. Assistant remains enabled; this is not a qualified live-model receipt. The prior qualification-only run was cancelled at the user's request before deployment. Normal qualified-release checks are unchanged.SUCCEEDED, pool1, Assistanttrue, Application executiontrue.Archive and safe removal are available in Dev. For the unresolved Corporate
plan_failed, refresh the UI and create a fresh Plan in the existing order, then inspect Execution logs. State/order/backend bindings are retained; existing terminal logs cannot be rewritten to recover rejected historical output. The underlying Corporate cloud failure is not declared fixed or accepted. No production deployment or customer Plan/Apply was performed by the agent. This issue stays open.lweberru commentedon Oct 22, 2026
Corporate acceptance update:
504 Gateway Timeout. A read-only CLI inventory found no matching Application routing table. The checkpoint is not yet verified, so this is not successful end-to-end acceptance or a basis for a blind Apply retry.Automaticwith configured DNS previously failed the pinned provider's IPv4 validation. PR #135 resolves the regional SNA default in the native module while preserving DNS and explicit overrides; it also pins the reviewed source, improves diagnostic details and qualifies Assistant advice/proposals.Local validation: full app check 1010 passed/71 environment-gated skipped; PostgreSQL 51/51; focused desktop/mobile identity flow 6/6; catalogue flow 10/10; native suites 16+13+36; seven local-only real-provider cases; actual Runner-package probes 3 passed/131 unselected; final targeted real-model cases twice, 10/10. PR CI/review and deployment remain pending.
Operational gap: current Application recovery diagnosis reports stored job evidence, not an S3 checkpoint inspection. The bound Application State must be checked separately against its exact State key. Keep this issue open pending recovery and real Corporate/Public acceptance.
docs(connectivity): document Corporate VM firewall, NAT and SSH setup (…
fix(configurator): support Automatic Corporate networks and post-logi…
fix(assistant): ground DNS completion in saved metadata context (#142)
lweberru commentedon Oct 23, 2026
Dev deployment completed successfully: promotion 39943140329 deployed the exact immutable qualified build 39930756409, source
d74689be46b45ffed9981fac844e1f36550c4120, withrunner_pool_size=1. Both source-bound real-model qualification and the complete build passed. The original run stopped at its superseded-branch publication guard after the test-only #143 merge; no deployment occurred in that run. The documented operator backfill verified the exact protected buildpack tag, and explicit artifact promotion retained the original source and checksums. No guard was relaxed.The promotion passed versioned migrations, isolated Runner/binding checks and public route checks. Independent read-only verification confirmed health, STACKIT authentication, protected session/Assistant/recovery APIs and the recovery UI. Assistant and execution remain enabled. No customer Plan/Apply was initiated by this release.
This makes #135 and #142 available in Dev. It does not qualify Automatic IPv4 on a newly source-bound cloud order, hosted interruption/reconciliation, full-service restore or other outstanding acceptance criteria. The user has identified a disposable not-yet-executed order for a future targeted hosted drill; its identifiers remain private.