Configurator MVP: publish immutable application templates per tenant #92

Current Status (2026-10-06)

Tenant-bound draft/publish persistence, immutable versions, strict parameter policies and fork-free Application Owner catalogue/ordering are implemented locally. Explicit retirement and durable version-bound deployment policy are now implemented and locally validated. Customer publication acceptance under authoritative verified tenancy is complete in the intended local runtime; ordering is not cloud execution.

• Persist tenant-bound drafts and publication with server-side Platform Engineer permission checks.
• Add explicit retirement and server-side visibility/order rejection for retired offers, preserving historic versions and existing instances.
• Publish immutable versions bound to reviewed compiler/Accelerator metadata and a compatible approved platform-contract version.
• Enforce allowed input schema/options/defaults. Fixed organisation, target and role policies cannot be overridden by a client or chat.
• Expose only permitted published templates to Application Owners without a GitHub fork.
• Use the honest application-project-with-base-services contract; do not advertise VM/cluster creation that is not implemented.
• Persist direct versus approval-required deployment policy and enforce it server-side; the current approval-required/customer-Apply restriction must remain enforced.
• Test unpublished visibility, tenant isolation, immutable versions and attempted parameter/policy overrides.
• Add retirement/direct-policy regressions, including concurrent retirement/order, immutable policy snapshots, rejected overrides and explicit Apply restrictions.
• Complete customer publication acceptance under authoritative verified tenancy (Configurator MVP: verify organisation tenants and STACKIT user bindings #91).

Existing instances retain their selected immutable version. Publishing/retiring a template does not upgrade or destroy existing instances. Upgrades are separate explicit operations (#93).

Historical Evidence and Next Step (before current activation)

Current implementation: landing-zone-configurator/app/apps/api/src/applications/ and its persistence/tests, plus the Application Owner and project-template UI. Documentation: landing-zone-configurator/docs/project-template-drafts.md, template-parameters-and-bindings.md, plan-execution.md.

Final local gates: 312 unit tests, 28 isolated PostgreSQL identity/catalogue cases and all 148 desktop/mobile browser cases passed. Retirement is immutable/idempotent, hides offers from new AO orders and preserves existing instances/replays. Policy-only publication changes create a new version; clients cannot override order policy. Direct policy still reports executionEnabled:false, cloudPlanExecuted:false and requiresExplicitApplyApproval:true.

Evidence is recorded in the readiness/runtime reports. Migrations 021/022 are not activated in the running customer API; the bilingual UI uses capability flags for older APIs. Current additions are uncommitted/unreleased. Next required acceptance: authoritative tenancy (#91), activation and customer publication verification. No customer Apply, package rebinding, release or merge occurred.

Final Publication Acceptance (2026-10-06)

The existing Public template was actually published as immutable version 1 from the saved configuration, with the approved current server-derived platform contract, eu01/public-eu01 target, default Application Owners group and approval-required policy. It persists in the real catalogue after reload. No duplicate version or cloud resources were created.

Group CRUD is now in User management, not an extra Applications tab. Adding/removing members and deleting a temporary group passed through the actual protected UI and survived reload. Default membership and workspace users remain intact; assigned template ACLs block group deletion. Role updates preserve custom memberships. Both actual group members display confirmed STACKIT email addresses rather than UUIDs; foreign sessions/tenants and non-managers cannot obtain the email list.

All required publication criteria listed in this issue are complete. Production OIDC/two-organization security rollout stays in #91, actual Application Plan/Apply/quotas/upgrades/recovery in #93 and release gates in #95. Closing #92 does not claim the entire MVP or cloud execution is complete.

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

Verified tenancy (#91) is required before production customer publication. Consumed by instances (#93); chat (#94) must use identical policies. Symbolic network binding remains blocked until #96 qualifies the actual egress path.

Historical Milestones

Draft authoring: 0e62c5e. Parameter contract/order preview: 244e936 (2026-10-01). Their earlier statements that publication/order were still absent and their test counts describe those historical revisions, not the current implementation. Native blocked capabilities remain blocked.