Repository navigation
Configurator MVP: operational acceptance and feature-branch merge readiness #95
Description
Hosted Plan interruption and recovery accepted (2026-10-24)
Current Dev: PRs #153 and #154, source f0e99c52b0a33641f3b35da77aa7218c1a9cf4ff, successful release 40105786298, Runner pool size 1, dev-skip-assistant-qualification, Assistant enabled.
- Interrupt the exact disposable hosted Application Plan: its Runner was independently observed DOWN 8.6 seconds after the native hold began, within the 30-second hold window.
- The order owner completes the interrupted Plan through the authenticated UI action. Independent database inspection confirms
failed/cancelled, a terminal timestamp and the immutable completion receipt bound to the exact Runner/source. No manual operator change to job status or execution authorization was used. - The owner starts a fresh Plan of the same order. UI acceptance and independent database inspection confirm success and a saved Plan artifact, without creating a replacement order.
- Exact backend inspection before and after recovery confirms the State remained unchanged and unlocked. This initial-Plan fixture had no State object; it remained absent. Temporary privileged diagnostic apps were removed after the read-only checks.
This qualifies the hosted Plan interruption → explicit owner completion → fresh successful Plan path. It does not qualify hosted Apply interruption, recovery of partially written State, orphan-lock clearance, or the remaining backup/restore, role-revocation, capacity and rollback criteria. The issue remains open for those criteria. No new Apply was started for this Plan-recovery verification.
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 acceptance scope decision (2026-10-23)
At the user's explicit decision, a second real STACKIT organization is removed from the current Dev/MVP acceptance scope because another organization is not available. Cross-organization live acceptance is deferred to a future expressly authorized customer validation; it is not recorded as passed and does not block completion of the current scope. Existing tenant/organization authorization and isolation guards remain required and unchanged.
Current live acceptance uses the available organization with separate Platform Owner and Application Owner accounts. Role/owner boundaries, stale sessions, queued jobs and grant expiry/revocation remain in scope within that organization. Automated cross-tenant isolation tests remain required. This scope decision does not authorize production or customer infrastructure operations.
Latest operational checkpoint (2026-10-22)
The real Platform Apply and HTTP-to-S3 migration acceptance in #90 is now complemented by successful Corporate Application provisioning and same-order recovery from a reported partial Apply failure; see the current acceptance record in #93. The fresh Plan retained 12 existing resources and the user-executed Apply completed with 3 added, 0 changed and 0 destroyed. The user also confirmed Internet/DNS and external SSH after manual firewall NAT/port-forward, VM security-group and guest-user/key configuration. These are positive acceptance results for the tested Corporate instance, not automated firewall-policy or HA/isolation qualification (#101).
Current Dev: #136 at 3d2f0af26e5bac23f23ff7c462cff1cec0f165b7, release 39767149101, Runner pool size 1, dev-skip-assistant-qualification, build_only=false. Deployment/migrations and isolated cold/warm Runner probes passed; the Assistant remains enabled. Live Assistant qualification was intentionally skipped for this unrelated fix and is not claimed by this release.
Two accounts have been exercised in one organization. A second real organization is outside the current acceptance scope by the 2026-10-23 user decision; live revocation and role-boundary acceptance remain outstanding. Public Application cloud acceptance has subsequently succeeded (see the 2026-10-23 checkpoint above). Hard Runner loss, backup/restore, capacity and rollback criteria remain open. #135 has subsequently merged but is not deployed; the current acceptance does not qualify its Automatic IPv4 and identity-completion changes. No production or agent-executed customer Plan/Apply was performed. Earlier queued-merge statements below are historical.
Historical source integration
PR #102 contains the reviewed MVP source integration. Final source: c0e95ac. All 13 final-revision native/Configurator CI checks passed. The configured real models passed a complete 114/114 repeated suite and 13/13 continuous journey; prior failed evidence remains recorded in the PR.
The PR is ready and protected auto-merge is enabled. Required human/code-owner review is still outstanding; repository protections were not weakened or bypassed. Source integration is not an application deployment, customer Apply or production acceptance.
Acceptance checklist
- Maintain current capability/boundary documentation, linked implementation issues and a distinction between source/mock/native and real customer evidence.
- Freeze and verify the final revision through build/unit/browser/PostgreSQL isolation, native OpenTofu contracts and catalogue checks.
- Accept separate users/roles in the available organization, revocation, interrupted Runner and recovery paths; retain automated cross-tenant isolation coverage. A second real organization is deferred to later customer validation and does not block current acceptance.
- Verify PostgreSQL/Secrets Manager/artifact backup/restore, credential rotation and safe operator recovery diagnostics against the acceptance environment.
- Complete capacity, job cleanup, migration rollback/forward recovery and release rollback compatibility acceptance.
- Review CODEOWNERS/main protection and CI/CD transition; Configurator provisioning and deployment are now exclusively manual.
- Prepare a reviewable PR and secret scan with a clean worktree. The sole history scanner result was independently verified as a synthetic mocked-provider password, not a credential.
- Obtain the user decision authorizing source integration; no customer Apply or production creation is implied.
- Complete source integration of feat: integrate Landing Zone Configurator MVP #102: GitHub records it merged on 2026-10-16 as
0835c7a31618a5ffd007000bd3d9bcf4b3e693ee. This records merge completion, not independent verification of every historical review event.
Maintained references
The Configurator README in #102 links the user guide, component diagrams/architecture, MVP scope and development map. CONTRIBUTING describes the cross-component workflow; AGENTS.md references the preserved Terraform style guide. Dated workstation handoffs and historical readiness/runtime ledgers have been removed from the maintained tree and are not current acceptance evidence.
Native CI: https://github.com/stackitcloud/stackit-landing-zone/actions/runs/38898519075
Configurator CI: https://github.com/stackitcloud/stackit-landing-zone/actions/runs/38898519039
Remaining scope
This issue remains open for the operational acceptance above. No production environment was created; production identity, network, backup/recovery, capacity and operator qualification are a separate follow-up. Local/model/CI success does not certify every live customer topology.
Product acceptance continues to depend on #89, #90, #91, #92, #93 and #94. #94 is linked for source-merge closure; the other issues retain their unaccepted live criteria.
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 16, 2026
MVP source integration is prepared in #102: all changes are committed/pushed; automatic native/Configurator checks are separated from manual cloud operations; public user/architecture docs and contributor/operator references are separated; CONTRIBUTING and AGENTS.md are added/updated; obsolete workstation/evidence artifacts are removed from the maintained tree. Existing main rules and required reviewer approval are unchanged. The user has authorized integration, but that does not bypass repository review rules.
The PR records exact CI/model evidence and retained failed attempts. The final complete Assistant run is 114/114 plus a 13/13 journey. The final workflow-hardening commit is being verified separately; no deployment, customer Apply or production setup has occurred.
Keeping this operational acceptance issue open. Two-organization/revocation acceptance, real interrupted-runner/migration recovery, backup/restore/rotation and production capacity/rollback/operator qualification remain separate uncompleted requirements. Source integration and green test jobs are not a declaration that those live paths were accepted. Maintained references are the user guide, architecture, MVP scope and development map linked from the Configurator README in #102, rather than the removed dated readiness/runtime ledgers.
lweberru commentedon Oct 16, 2026
Final integration update: all 13 checks on c0e95ac passed. PR #102 is ready, and exact-head protected auto-merge is enabled with the required review still pending. The issue checklist now reflects the completed source/CI/documentation work without marking untested live acceptance complete. #59, #82, #84 and #94 are linked for closure when the PR merges; no deployment or production resource was created.
lweberru commentedon Oct 17, 2026
Development delivery follow-up: #109–#114 are merged. The normal manual release 38986171056 succeeded on exact source
3ab7bfaa92236fc4a4242028a27a901df0c1496d; only the existing protected Development environment was approved. API and Runner current staged droplets were independently verified at that exact source.Exact-run evidence: configured Qwen model 114/114 repeated cases and 13/13 continuous dialogue; 817 unit tests passed (66 environment-dependent skips), 60 isolated PostgreSQL cases, 308 browser cases and pinned native contracts. Final actual-host browser smoke passed 5/5, including direct Plan/Apply URLs and reload, both viewport approval/blocker flows, locale, protected boundaries and same-tab STACKIT login.
The first otherwise successful release exposed real hosted phase-URL 404s hidden by the Vite preview; #114 fixed the explicit API SPA allowlist and added actual-static-serving regression coverage. Earlier model/release/browser failures remain preserved, not replaced by unchanged-source qualification retries.
Apply UI cases use intercepted synthetic APIs, not customer state; they never click Apply and forbid execution writes. The particular customer denial has not been diagnosed, and Firewall/HA Plan-only restrictions remain intact. No customer Apply or production deployment occurred. Source integration/development delivery is now complete; this issue remains open for the separately agreed operational acceptance, recovery and production follow-up.
lweberru commentedon Oct 20, 2026
Dev release blocked by Model Serving transport failures
PRs #119 and #120 are merged. The authorized manual Dev release with
runner_pool_size=1, run 39406372348, used exact sourcefc8ec29141c209769fa905504f83c921e7c22efaand failed qualification before any build, publication, migration or deployment.dns-zone-role-advice, iteration 1: model-phaseconnection_failed, 5591 ms.dns-owner, iteration 2: model-phaseconnection_failed, 3192 ms.platform-public-corporate-networkscase passed both independent repetitions. Continuous dialogue: 13/13 passed./v1/modelschecks from the workstation returned HTTP 200 and listed the configured model. These checks are not inference qualification, do not reproduce the GitHub network path and do not resolve or replace the two failed repetitions.Failed receipts remain attached to the original run. No failed repetition was retried or reclassified, and no oracle, timeout, model or release protection was weakened. Investigating the original transport cause requires runner-side bounded cause diagnostics or corresponding service-side evidence; a speculative client change is not justified by the existing receipts.
The existing Dev public health check still succeeds. The new release has not been deployed; hosted warm handoff/replacement proof remains unverified. No customer Apply or production operation was performed.
lweberru commentedon Oct 20, 2026
Bounded production inference retry implemented in #121
Following the user discussion, #121 adds one additional request for selected transient pre-response network errors, with 250-500 ms jitter inside the original deadline. It preserves cancellation, never replays HTTP/body/semantic failures, and never retries Plan/Apply or persistence. Safe per-attempt codes are retained in production logs and synthetic receipts; no CI-only recovery path or factual oracle change.
Exact source:
8f65ea8928f6e23bf7c8d62a9a7b262de0d59667. Pinned canonical validation: 971 passed, 69 unchanged default-gated tests. Changed-source real-model DNS cases: 16/16, two independent repetitions; continuous dialogue 13/13, both exit 0. No actual transport failures occurred locally; controlled tests verify retry and exhaustion without claiming the original provider/network cause was reproduced. Knowledge SHA:6179c3ad16fe011412c165ed1a0d2d71bff0678b9ba3dc2642464fbc3a41db69.Normal protected squash auto-merge is queued; CODEOWNER review remains required. Original failed runs and receipts remain failed. Dev is not updated yet: after approved integration, a new exact-source manual release with
runner_pool_size=1must still pass full qualification and hosted warm evidence.fix(configurator): bound transient model transport retries (#121)
lweberru commentedon Oct 20, 2026
Next exact-source release: factual setup-routing defect identified
The user merged #121 as
0c5188bf60c332adcbecf5372e913021b298e126. Its tree matched the validated feature tree. The optional extra local full run was cancelled after four passing cases, with no failures, to avoid concurrent inference with the protected release; it is not qualification evidence.New manual Dev release 39412434669,
runner_pool_size=1, attempt 1: 113/114 cases, 13/13 dialogue, no transport-error events.firewall-metro-setup-operationsrepetition 1 omitted the unanswered operations decision. Build, publication, migration and deployment were skipped. The original failed receipt remains unchanged.Draft #122 fixes a reproduced structural cause: general
hafield hints could bypass the dedicated scope/evidence classifier on a broad setup continuation. Four red regressions prove that bypass; the fix preserves explicit narrow native updates and uses null-only evidence when no bounded quote fragments exist. No factual oracle or topic facts changed. Canonical validation is green: 977 passed, 69 unchanged default-gated tests. Real-model Firewall qualification and CI are in progress; review readiness waits for their results. Dev remains on the previous release, without hosted proof of the new warm pool.fix(configurator): preserve broad Firewall setup decisions (#122)
lweberru commentedon Oct 20, 2026
Dev release: qualification blocked; Model Serving maintenance confirmed
PR #122 is merged at
d0fc3d3ef1cb4c405fdfdb95e2a45cfb707b33c8.The fresh manual release run 39417609958
requested
runner_pool_size=1but did not build or deploy:dns-placeholder, repetition 2,upstream_status_403, at2026-10-20T12:04:25Z.The official STACKIT status API
reported AI Model Serving
under_maintenanceat2026-10-20T12:16:36Z:GPU Maintenance Notice Part 2,
in_progress,scheduled until 18:00 CEST / 16:00 UTC. The original notice text says
17:00 CEST instead; actual service recovery matters, not the advertised clock time.
Maintenance confirms possible service interruptions but does not establish
the specific reason for the observed HTTP 403.
Recovery boundary: wait for the component to become operational and relevant
maintenance to complete, then run a fresh complete protected manual release
against unchanged main, with
runner_pool_size=1and unchanged qualificationcriteria. Do not rerun individual failures, erase failed repetitions, retry 403,
switch models or weaken the gate. The failed run remains part of the evidence.
UI reproduction after recovery: Actions > Configurator Release > Run workflow,
branch
main,build_only=false,runner_pool_size=1.Normal protected Dev approval remains required after qualification/build.
No customer infrastructure Apply or production deployment is included.
lweberru commentedon Oct 21, 2026
Live platform acceptance update (2026-10-21)
The operator supplied a successful real saved-plan Apply log and confirmed the completed workflow. The retained partial-bootstrap deployment was resumed through checkpoint review, explicit same-state reconciliation, a new credential profile, a new configuration revision/preparation and a newly reviewed saved Plan. Existing firewall VMs were preserved.
Observed results:
Apply complete! Resources: 13 added, 0 changed, 1 destroyed.The replacement was only the taintedterraform_dataHA bootstrap step, not a firewall VM. Both backup and primary HA configuration commands completed successfully. All three project-qualified management buckets, Object Storage credentials, the audit archive destination, the Observability Starter instance and associated protected secret entries were created. The subsequenttofu init -migrate-statereported successful migration from the HTTP bootstrap backend to S3.Delivered by #128, #129 and #130 through Dev release 39608332090, with runner pool size 1. This was the explicit Dev qualification-exception mode, with the Assistant enabled; it is not production acceptance or a new successful full model qualification. Evidence here is a sanitized summary of operator-provided output, not independent access to customer infrastructure. Customer identifiers, credentials, raw plans and State are deliberately omitted.
A clean follow-up Plan has not been independently established by the supplied log. Actual HA failover, packet paths and audit-event delivery were deferred. Hard Runner loss, interrupted backend migration, backup/restore and multi-tenant acceptance are not proven by this successful run.
The source-merge checklist has also been corrected against GitHub: #102 merged on 2026-10-16. Operational acceptance remains open.
9 remaining items
lweberru commentedon Oct 24, 2026
PR #149 is merged and Dev release 40078665835 succeeded. Public health/authentication checks passed; the Assistant and execution remain enabled with Runner pool size 1. Only live Assistant qualification was intentionally omitted for this unrelated Dev fix.
The additional real CF preflight identified a narrow runtime mismatch before any disposable-order interruption: this foundation supplies shortened hexadecimal
CF_INSTANCE_GUIDvalues (8-4-4-4-4), so the initial RFC-UUID check correctly failed closed. PR #150 corrects only that runtime-instance format check; app/space/order UUIDs, exact Dev binding, route-free web context and expiry remain strict. Failed preflight receipts are retained.The corrected candidate passed in a credential-free, route-free temporary CF web app using actual unmodified CF metadata: a real pinned OpenTofu process group was confirmed stopped, automatically resumed after 30 seconds, and completed its synthetic local Plan. All four temporary web probes and all privileged recovery diagnostic apps were verified removed. This is candidate/runtime evidence, not recovery acceptance of a real dispatched Application job.
The exact approved disposable order was checked privately: its three prior Plans succeeded, no Apply ran, and its registered S3 backend is reachable with no initial State object or lock. After #150 passes CI and its Dev release is verified, the next step is the actual exact-job stop, independent durable-status/State/liveness inspection and a fresh Plan on the same order. Hard worker-loss, orphan-lock and Apply recovery remain unqualified; this issue stays open.
fix(recovery): accept actual STACKIT CF instance identifiers (#150)
fix(recovery): verify copied Runner droplet payloads (#151)
lweberru commentedon Oct 24, 2026
PRs #149 and #150 are merged and the final scoped Dev release 40081648583 succeeded on source
14a686c106ab8f430c1ecc9bd3b8bbc751c09e61. Independent reads verified the actual new app, exact Runner binding, enabled Assistant/execution, pool size 1, protected public routes and removal of privileged temporary apps. Live Assistant qualification was intentionally omitted for this unrelated Dev change; normal qualified-release gates remain intact.The actually deployed native hold module, including its exact pretested fingerprint, passed a separate credential-free CF web probe: real metadata accepted, ordinary execution without opt-in excluded, native Plan group confirmed stopped, automatic continuation after 30 seconds, successful synthetic Plan and fixture cleanup. The temporary app was independently confirmed removed; CAPI deletion visibility was asynchronous and no probe was replayed.
PR #151 is also merged after successful CI. It corrects only the local arming tool's copied-droplet verification: a CF copy has its own GUID, so require a valid identical SHA-256 payload, staged state and exact owning app while retaining the original broker source binding. The verifier accepted the real current-source clone and rejected the old different-source clone using only GETs. All 28 recovery/controller tests pass. No extra app release is needed for this operator-only change.
The actual disposable-order interruption remains pending the user's authenticated UI start. The controller is not armed and no new customer Plan/Apply or State mutation was performed. After coordination, the controller will target only the approved disposable order; actual Runner loss, durable status, State/lock disposition and fresh-Plan behavior must still be verified. No hosted recovery or orphan-lock/Apply qualification is claimed and this issue remains open.
lweberru commentedon Oct 24, 2026
Hosted Plan interruption remains unqualified. The latest disposable Plan completed successfully on a current-source cold Runner while the specifically prepared standby remained unassigned. The observer was stopped without issuing a cloud stop; exact backend inspection found no state object or lock. Temporary privileged diagnostics were removed.
A deterministic local PostgreSQL regression reproduced one way this fallback can occur: a readiness heartbeat briefly holds the slot row lock and the dispatch reservation immediately skips it. PR #152 adds bounded retries before any assignment, only while an eligible same-pool standby is visible. The live transient lock itself was not captured, so this is not yet proof of the complete operational cause or successful recovery.
The short-lock regression fails on the previous code and passes with the correction. All 15 pool database tests, 63 platform database tests and the complete application check pass. The next hosted interruption and fresh Plan on the same disposable order are still required. No Apply-recovery or orphan-lock acceptance is claimed.
fix: retain ready runner during brief claim contention (#152)
lweberru commentedon Oct 24, 2026
PR #152 is merged and deployed to Dev at
d282216ce973e388faf492dbe8f21794da374f4cthrough Configurator Release 40092110317. All applicable PR and release checks passed, including real database, browser, native-contract and cold/warm Runner operational checks. Runner pool size remains 1. Only live Assistant qualification was explicitly skipped; the Assistant remains enabled.Independent post-deployment checks confirm the new API build, exact current Runner source, protected public routes and removal of temporary privileged diagnostic apps. A route-free synthetic fixture on the actual new Runner confirmed the native Plan hold, automatic continuation after 30 seconds and successful completion; its app was removed. This remains synthetic evidence, not proof of interrupting an authenticated customer job.
The disposable order still has only successful Plan jobs and no Apply. Its exact backend has neither a state object nor a lock. The previous observer was stopped without issuing a Runner stop. No new interruption controller is armed while coordinating the next UI-triggered test. Actual interruption, durable recovery and a fresh Plan on the same order remain outstanding; this issue stays open.
lweberru commentedon Oct 24, 2026
The hosted Plan interruption has now been observed independently: the exact Runner process was DOWN 8.6 seconds after the native hold began, within the 30-second hold window. The bound backend remained unchanged with no State object, no lock and no saved Plan or recovery artifact.
This exposed a remaining recovery gap: the durable job stays in
planning, preventing the owner from starting a fresh Plan. PR #153 adds an explicit, owner-bound interrupted-Plan completion action, with read-only Runner/State checks, final binding revalidation and an immutable receipt. It does not stop execution, modify/unlock State or start a Plan/Apply.Local verification includes 1,098 app tests, 70 database tests, 63 platform database tests, 76 desktop/mobile lifecycle tests and a read-only real-CF driver check against the stopped Dev Runner. Hosted completion followed by a fresh successful Plan is still pending deployment; this is not yet complete recovery evidence. Apply interruption and orphan-lock handling remain separate work.
fix(configurator): safely complete interrupted application plans (#153)
fix(configurator): retain runner observation freshness (#154)
lweberru commentedon Oct 24, 2026
PR #153 and the observation-freshness correction #154 are merged. The corrected Dev release completed successfully: https://github.com/stackitcloud/stackit-landing-zone/actions/runs/40105786298
Independent runtime checks confirmed the exact deployed revision, migration installation, Runner pool size 1, active Assistant, protected recovery endpoint, shipped UI and removal of temporary privileged diagnostic apps. Read-only inspection using the real Runner credentials still identifies the exact interrupted Runner as stopped. The exact backend remains unchanged, with no State object or lock.
Validation for the final source: 1,100 app tests, 39 interrupted-Plan/CF-driver cases, all applicable PR CI and release checks. The preceding database suites passed 70 Application/database and 63 platform database cases; 76 desktop/mobile lifecycle cases passed locally. The final correction adds deterministic 29-second/31-second freshness regressions. The first Dev release was deliberately cancelled before deployment to include that correction.
The owner has been asked to use the new explicit completion action on the existing disposable order. An immutable completion receipt and a fresh successful Plan of that same order still need to be observed. This issue remains open; Apply interruption and orphan-lock recovery are separate remaining evidence.
fix(configurator): diagnose interrupted application applies (#155)
test(configurator): guard hosted apply interruption by checkpoint (#156)
lweberru commentedon Oct 25, 2026
Hosted Apply hard-stop checkpoint (2026-10-25)
Dev release 40118453190 deployed #155 successfully; #156 supplies the separately scoped operator observer. Runner pool size is 1, Assistant remains enabled, live Assistant qualification was explicitly skipped for this unrelated change.
The user started the Apply of the expressly disposable order through the normal authenticated UI. The controller requested one stop only after observing an exact active Apply and a stable native partial S3 checkpoint. Independent checks confirm the Runner STOPPED/DOWN, a retained serial-1 checkpoint with 3 managed resources, and the same orphan Apply lock. The order owner used Check interrupted Apply. Independent database inspection confirms terminal
reconciliation_required/cancelledand the immutable interruption receipt; the temporary privileged diagnostic apps were removed.Cloud reconciliation found the matching Application network and automation service account outside that checkpoint, plus the intended existing project-role assignment. There are no automation keys or buckets; the storage credentials group is the platform-created default. This is not proof that an already completed provider operation was omitted by OpenTofu: accepted/in-flight cloud requests during hard loss are also possible. No upstream engine-bug attribution is made.
Native imports into a private local copy, using the original bound inputs/source and OpenTofu 1.12.6 / STACKIT provider 0.114.0, preserve all three original resources and the lineage. The candidate has 6 managed resources (serial 4). A diagnostic local Plan retains 6 and proposes 6 creates, with no updates, deletes or replacements. This diagnostic is not an eligible Configurator Apply plan.
Still open: concrete authorization and guarded remote State/lock recovery, operator-attested same-order replanning after old execution grants expire, then a fresh reviewed user-started Apply and independent identity checks. Remote State and lock have not been changed. Do not count this checkpoint as complete hosted Apply recovery or close the operational acceptance issue. Related first-Apply checkpoint investigation: #140; this S3 observation does not establish the same cause as the local-backend finding.
feat(recovery): cover Application resources and owner self-service (#159