Xyence Orchestrator
Create initiative

Initiative Brief: Application Platform Foundation & Content Management V1

EXECUTING

Intent — the specification; the plan below decomposes it into work items

# Initiative Brief: Application Platform Foundation & Content Management V1 ## Repository scope - Repositories remain explicit engineering resources but should not be the primary abstraction exposed to ordinary application managers. - Orchestrator must surface repository relationships sufficiently for administrators/developers to understand and operate them. - ---

hints: Repositories remain explicit engineering resources but should not be the primary abstraction exposed to ordinary application managers., Orchestrator must surface repository relationships sufficiently for administrators/developers to understand and operate them., ---created 8/16/2026, 8:31:10 PMby human:workspaces-orchestrator-app

Repository scope

targets the work spans — independent of where the brief was authored

Primary repository: Repositories remain explicit engineering resources but should not be the primary abstraction exposed to ordinary application managers.

  • Repositories remain explicit engineering resources but should not be the primary abstraction exposed to ordinary application managers.expected · primary
  • developers to understand and operate them.expected
  • orchestrator — Application Platform lifecycle: platformexpected
  • outshine — Doorway registration and authorization; the Outshine content provider (the reinterpreted Content Management V1); Composer delegation.expected
  • workspaces — Content Workspace surfaces and the content client, against the provider contract rather than an Outshine-canonical API.expected
  • hub — topologyexpected
  • A new repository for the new business website Application, created through the Application Platform rather than by hand.expected
  • stlouis-xyence-io — out of scope as the validation application for this initiative.expected
  • ---expected
  • outshinediscovered
  • orchestratordiscovered
  • hubdiscovered
  • workspacesdiscovered
  • stlouis-xyence-iodiscovered

Initiative Brief

Committed

The Initiative Brief is the reviewed contract Orchestrator plans and executes against. Source material (imported issues, direct intent) is provenance — nothing becomes binding until you commit, and a committed revision is never rewritten in place.

Committed brief — revision 3 (material)
Desired outcome
Create the first real business website through Orchestrator, migrate its existing Articles into application-owned structured content, manage those Articles through Content Workspace and Composer, preview them through the actual application, publish them safely, and deploy the resulting website. Every proposed work item is evaluated against that target: if it is not necessary for it and does not prevent an obvious architectural dead end, defer it. The objective is NOT to perfect the Application Platform.
Motivation
The first wave shipped work against an architecture the initiative did not intend. Content Management V1 was implemented as though content is canonically stored in Outshine and independently deployed applications retrieve their own managed content from an Outshine Content API, with stlouis-xyence-io as the validation application. That inverts the ownership model: an independently managed Application must not be required to store its content records in the Outshine database merely because Content Workspace needs to manage them. Correcting this now, before further work proceeds, is cheaper than continuing and it is what makes the intended lifecycle demonstrable. The desired outcome is architectural reconciliation followed by forward progress — not a restart.
Current state
• Wave 1 completed six work items: platform ADRs (outshine), a platform-topology manifest (hub), manifest ingestion plus Applications and Repository Relationship views (orchestrator), Content Management V1 backend with domain/RBAC/API (outshine), and a Content Management V1 client in packages/api-client (workspaces). • That Content Management V1 backend treats Outshine as the canonical content store for all applications, which is the misinterpretation this revision corrects. • The remaining planned item — Xyence/stlouis-xyence-io#183, consuming Content Management V1 from the St. Louis site — is still unclaimed and assumes both the Outshine-canonical store and stlouis-xyence-io as the validation application. • Application Platform work to date catalogs and displays existing repositories and applications; there is no path yet for CREATING a new Public Web Application. • The previous architectural clarification separating Application (software/lifecycle abstraction), Doorway (controlled Outshine integration boundary for independently deployed applications) and WorkspaceInstance (integration boundary for Workspace Applications) remains valid and in force. • This brief's own structured sections were nearly empty through wave 1 — only repository scope was carried across at intake — so the plan was generated against almost none of the brief's actual content. • Wave 2 completed six work items: wave-1 content dispositions recorded (outshine), the topology manifest spec extended for Application provisioning (hub), an Application Template registry with a Public Web Application scaffold, a GitHub repository creation and template scaffolding service, Hub manifest generation opening a PR to Xyence/hub, and a feature-flagged Create Application flow composing repository creation with Hub PR generation (orchestrator). • That Create Application flow exists behind a feature flag and has not yet been demonstrated against any target, real or sandboxed. Nothing has been created through it.
Product principles
• Workspaces expose state. Composer manipulates state. • The user should not need to understand the internal subsystem boundary: 'write a new article' and 'move Articles before About in navigation' are both things they simply ask for, even though one routes to a content provider and the other to Orchestrator. • Preview shows the real thing: a draft Article is rendered through the actual target Application — its layout, typography and Article route — not through a generic Content Workspace renderer. • Content Workspace V1 stays deliberately small: an Application selector, Articles split by Draft and Published, Article selection with rendered preview, Composer context and publication state. Nothing more. • Ordinary page structure and relatively static prose remain application/code operations performed through Composer and Orchestrator, not entries in a page CMS.
Architectural principles
• Application is the unit of software ownership and lifecycle. • Platform is the isolation and agent blast-radius boundary. • Orchestrator creates, modifies, provisions, deploys and operates Applications. • Applications own their structured content unless they explicitly elect to use an external or shared provider. • Content Workspace is a cross-application management surface, not the universal content database. • Content Providers connect Content Workspace to the content owned or selected by an Application. • Outshine-hosted content storage may be one Content Provider; it is not mandatory for all Applications. • Composer is the common natural-language interaction layer across Content and Orchestrator operations. • WorkspaceInstance is the Outshine integration mechanism for Workspace Applications. • Doorway is the controlled Outshine integration mechanism for independently deployed Applications. • The new business website — not the existing stlouis-xyence-io site — is the primary end-to-end validation application for this initiative. • Applications own their content; Content Workspace manages content exposed by applications; Orchestrator manages the applications that render that content; Composer provides the common interaction layer.
Domain concepts
• Application: The unit of software ownership and lifecycle: template, repository, resources, database, preview and production environments, routes, Doorway registration and content contract. It owns its content. • Platform: The isolation and agent blast-radius boundary an Application is created within. • Content Provider: The implementation behind the content contract that translates content operations to the persistence mechanism owned by the Application. An application-owned provider (e.g. the business website's own database) and an Outshine provider are both legitimate. • Content Contract: The explicit, smallest practical declaration by which an Application exposes manageable structured content: its content capability, the collections it exposes, a schema/field contract and supported operations. For V1 it need only support Articles. • Content Workspace: A management plane over application-owned content. It discovers compatible Applications and their exposed collections, shows deterministic state, establishes Application and Content context for Composer, invokes content operations and renders previews. It is not the system of record. • Doorway: The controlled Outshine integration boundary for an independently deployed Application. Registration may be automatic; Outshine data exposure remains explicit and governed by existing authorization and publication controls. • WorkspaceInstance: The Outshine integration boundary for Workspace Applications, as distinct from a Doorway. • Route: Where an Application is reachable, owned by Application → Environment → Route. Distinct from and not a responsibility of a Doorway. • Article: The only structured content type this initiative manages. Persisted as a resource owned by the validating Application, with fields such as id, title, slug, summary, body, author, status, published_at, created_at and updated_at as implementation requires.
Decisions
• Stop the currently planned Xyence/stlouis-xyence-io#183 implementation as validation of Content Management V1. — It assumes content is canonically stored in Outshine, that applications retrieve their managed content from the Outshine Content API, and that stlouis-xyence-io is the primary validation application. None of those reflect the intended architecture. Mark it superseded by the revised plan rather than treating its architecture as the target state; stlouis-xyence-io may eventually consume Outshine-managed content, but it is not the application that establishes the Content V1 ownership model. • An Application owns its content records, including in its own provisioned database, and Content Workspace manages them through an explicit application/content contract. — Ownership is architectural, not a UI distinction. Requiring an independently managed Application to store its records in the Outshine database merely so the Workspace can manage them inverts the model the initiative exists to establish. • Reinterpret the existing Outshine Content Management V1 work as a Content Provider implementation rather than discarding it. — Outshine may legitimately own platform, shared, Doorway/community content, and the content of applications that explicitly elect Outshine-hosted storage. The implementation stays useful for those; it must simply stop implicitly defining storage for all Applications. • Introduce an explicit Content Provider contract through which an Application declares compatible content capabilities. — Content Workspace must not connect directly to arbitrary application databases or infer editable content by scanning schemas. Applications declare capabilities, collections, a schema/field contract and supported operations — list, retrieve, create draft, update, publish, unpublish where practical, preview, and archive/delete where justified. • The primary validation target is the new business website, created through the Application Platform. — Pointing an already-existing application at an Outshine API does not exercise the lifecycle this initiative establishes: platform, application, template, repository, resources, database, preview and production environments, routes, Doorway registration and content contract. The new site must be created through the emerging platform rather than created manually and registered afterward, unless an implementation constraint makes a transitional step unavoidable. • Application provisioning is restored as a primary deliverable of the next wave. — The platform must be able to CREATE and operate an Application — create/select platform, create application, select the Public Web Application template, create or associate a repository, scaffold conventional source, provision resources and an application-owned database, establish preview and production environments and routes, register the Doorway, provision Doorway credentials securely, establish the content contract and deploy. A static manifest describing applications created elsewhere may participate, but does not substitute for this. • Classify every issue and completed artifact from wave 1 as RETAIN, RETAIN WITH REINTERPRETATION, MODIFY or SUPERSEDE before planning replacement work. — The planner must avoid both failure modes: rebuilding useful completed work, and silently preserving an architectural mistake merely because an implementation already shipped. Platform/Application modeling, repository associations, topology manifests and Orchestrator application visibility are likely RETAIN — verify rather than assume. Outshine Content Management V1 is the likely RETAIN WITH REINTERPRETATION. stlouis-xyence-io#183 is SUPERSEDE for this initiative's purposes unless review finds a separate reason to keep it outside the initiative. • Doorway registration for an Outshine-connected Public Web Application may be automatic; Outshine data exposure must remain explicit. — Creating a Doorway must not grant or publish arbitrary Outshine data. Existing Doorway authorization and publication controls remain authoritative. • Routing stays outside Doorway authority in the Application Platform model. — A Route determines where an Application is reachable (Application → Environment → Route); a Doorway determines the controlled authority through which an independently deployed Application interacts with Outshine. Legacy coupling may remain where broad refactoring is unnecessary, but new architecture must not deepen it. • Plan the corrective wave in phases: reconcile existing work, then application provisioning, then the content provider boundary, then Content Workspace/Composer, then the business website itself. — The shortest coherent path to the actual validation target. Unrelated generalized platform work does not begin before that path is functional. • The new business website Application is created in the repository Xyence/www-xyence-io, and is the application for the www.xyence.io website. — The Create Application flow needs a definite name and repository slug before it can instantiate anything. Recorded in answer to the wave-2 continuation checkpoint, which gated wave 3 on exactly this. • The preview site is served at www.staging.xyence.io. Production www.xyence.io continues to serve the existing site until an explicit, separately authorized operator cutover. — A different version of www.xyence.io is already live in production. Replacing what that hostname serves is an operator decision about a live business site, not a side effect of delivering this initiative. DNS for the preview hostname already resolves to the host the new application will run on. • The Articles currently published on www.xyence.io are the migration source, extracted from the live site and populated into the new application-owned content store. — Answers which Articles are migrated and from what source. The existing site is the only authoritative record of that content. • The Create Application flow is demonstrated in dry-run and in one sandbox execution before the real Application is created, and that demonstration is the first work of the wave. — The flow was built in wave 2 but has never been run. Pointing an undemonstrated creation path at a real repository and a live business hostname makes the first execution both the test and the production event. The wave-2 checkpoint set this as the condition for proceeding; it is recorded here because the planner reads the brief and does not read the checkpoint's answer.
Rejected / deferred alternatives
• Outshine as the canonical content store for all application content. — It makes Content Workspace the system of record and requires independently managed Applications to keep their records in the Outshine database. Outshine remains one legitimate provider, for its own, shared, Doorway/community content and for applications that explicitly elect it. • stlouis-xyence-io as the primary Content V1 validation application. — Consuming an Outshine API from an existing site validates none of the application lifecycle this initiative establishes. • A universal CMS schema language, or a generalized page CMS. — V1 needs only Articles. Ordinary page structure and static prose stay in application source, changed through Composer and Orchestrator. • Content Workspace connecting directly to application databases, or inferring editable content by scanning schemas. — Applications must explicitly declare compatible content capabilities through the contract. • An Application Platform that only catalogs and displays applications created elsewhere. — The platform must ultimately create and operate the Application; manifests may participate in the implementation but do not replace the lifecycle. • Discarding and rebuilding the shipped Outshine Content Management work. — Its role changes, not necessarily its code. Each component is classified before replacement work is planned. • [deferred] Routing as an intrinsic Doorway responsibility. — Routes belong to Application → Environment. Existing legacy coupling may remain temporarily where refactoring it is unnecessary.
Constraints
• This is a corrective wave, not a restart: preserve compatible work and do not replace working code merely because its architectural role has been clarified. • Do not assume an existing implementation is architecturally authoritative merely because it has already shipped. • Do not expand the wave into a generalized page CMS or a universal content schema language; V1 supports Articles only. • Do not begin unrelated generalized platform work before the validation path is functional. • The exact Article schema and contract format follow existing platform conventions and implementation requirements; the field list in this brief is illustrative, not a mandatory universal schema. • Before planning replacement implementation, inspect the original brief, this revision, all existing initiative issues, completed implementation from prior waves, relevant ADRs, and the current Orchestrator Application/Platform, Outshine Content, Workspaces Content client and Doorway implementations. • Do not change what www.xyence.io serves. The existing production site stays live for the duration of this initiative; pointing that hostname at the new Application is a separate, explicitly authorized operator step and is not in scope here. • Do not create the real Application until the Create Application flow has been demonstrated in dry-run and in one sandbox execution, with the results reviewed. Sequence the demonstration first.
Invariants
• The business website's Article content belongs to the business website Application, even though Content Workspace and Composer can manage it. • Content Workspace is a management plane over application-owned content, never the canonical persistence layer for all content. • An independently managed Application is never required to store its content records in the Outshine database in order to be manageable. • Creating a Doorway never implicitly grants or publishes arbitrary Outshine data; existing Doorway authorization and publication controls remain authoritative. • Draft Articles never become publicly accessible; production exposes only Published content. • A Route determines where an Application is reachable; a Doorway determines the controlled authority through which it interacts with Outshine. The two remain separate. • Application and content context are explicit enough that Composer cannot accidentally modify another Application. • Where this revision conflicts with an earlier planned issue, implementation assumption or interpretation of the brief, this revision is authoritative.
Repository scope
• Repositories remain explicit engineering resources but should not be the primary abstraction exposed to ordinary application managers. • Orchestrator must surface repository relationships sufficiently for administrators/developers to understand and operate them. • Xyence/orchestrator — Application Platform lifecycle: platform/application creation, templates, repository creation and scaffolding, resource and database provisioning, environments, routes, deploy. • Xyence/outshine — Doorway registration and authorization; the Outshine content provider (the reinterpreted Content Management V1); Composer delegation. • Xyence/workspaces — Content Workspace surfaces and the content client, against the provider contract rather than an Outshine-canonical API. • Xyence/hub — topology/manifest participation where it remains useful. • A new repository for the new business website Application, created through the Application Platform rather than by hand. • Xyence/stlouis-xyence-io — out of scope as the validation application for this initiative.
Expected behavior
• The Create Application flow is demonstrated end to end in dry-run and in one sandbox execution, and the created repository, scaffold and Hub manifest PR are inspected before any real Application is created. • A new Public Web Application can be created through the Orchestrator Application Platform. • The new business website is represented as an Application rather than merely an externally created repository. • The Application has appropriately scoped repository and resources. • The Application can receive an application-owned database resource where required. • The Application has Preview and Production concepts. • The Application can have routes managed through the Application lifecycle. • The Outshine-connected Application can receive an associated Doorway registration. • Doorway registration does not implicitly publish Outshine data. • The Application explicitly exposes an Article Content capability. • A provider/contract boundary exists between Content Workspace and content persistence. • The business website's Articles are owned by the business website Application. • Content Workspace does not require those Articles to be canonically stored in Outshine. • Existing Outshine Content Management functionality is either retained as an Outshine provider, adapted appropriately, or explicitly superseded based on code review. • Content Workspace can discover and manage the business website's Articles. • Composer can create and edit Article drafts. • Draft Articles can be rendered through the actual business website preview. • Published Articles appear through the production website. • Draft Articles do not appear publicly through production. • Existing selected Articles from the current business website are migrated with appropriate metadata, including author and date. • Static page and application changes can continue to be performed through Composer and Orchestrator without requiring a generalized CMS. • The new business website can be deployed through the resulting Application lifecycle. • stlouis-xyence-io is not required as the primary Content V1 validation application. • www.staging.xyence.io serves the new application's preview site. • www.xyence.io continues to serve the existing site, unchanged, until an operator cuts it over.
Open questions
• Is Xyence/stlouis-xyence-io#183 preserved for a separate reason outside this initiative, or closed as superseded? • If an implementation constraint makes creating the new site entirely through the platform impossible in this wave, what transitional step is acceptable, and what is then required to make the lifecycle real rather than retrofitted? • Which resource provisioning is in scope for V1 beyond an application-owned PostgreSQL database?
Need to change the committed intent? Begin a revision — the current brief stays in force until you commit the new one.
Revision history (3)
  • r1 · superseded · material · Initiative Brief: Application Platform Foundation & Content Management V1 — created from an Initiative Brief
  • r2 · superseded · material · Initiative Brief: Application Platform Foundation & Content Management V1 — Implementation and planning of the first wave exposed an architectural misinterpretation: Content Management V1 was built as if Outshine were the canonical store for all application content, and stlouis-xyence-io was taken as the validation application. This revision corrects the ownership boundary (applications own their content; Content Workspace manages it through an explicit provider contract), corrects the validation target to the new business website created through the Application Platform, and restores application provisioning as a primary deliverable. The initiative's overall goals continue; compatible work is retained. Where this revision conflicts with an earlier planned issue or implementation assumption, this revision is authoritative.
  • r3 · committed · material · Initiative Brief: Application Platform Foundation & Content Management V1 — Records the operator's answer to the wave-2 continuation checkpoint so wave 3 can be planned against it: the target repository and application (Xyence/www-xyence-io), the preview hostname (www.staging.xyence.io), the constraint that production www.xyence.io keeps serving the existing site until an authorized cutover, and the Articles on the current site as the migration source. Also sequences the dry-run and sandbox demonstration of the Create Application flow ahead of any real instantiation, and records what wave 2 delivered. The checkpoint answer is not part of the planner's context, so facts recorded only there would not reach wave 3's plan.

brief revision 3 — all 13 unmet criteria cleared

assessed with 64% confidence

Foundational platform, contract, UI, and tooling are in place (ADRs; Create flow with dry‑run; repo scaffold + Hub PR generators; topology manifest with Doorway/provider descriptors; Outshine Doorway APIs + security tripwires; Workspace provider‑boundary UI + clients; readiness/conformance/observability; migration tool). However, end‑to‑end delivery of the actual www‑xyence‑io Application is not evidenced: no record of executing the guarded Create run for the real app, no proof of a deployed Preview at www.staging.xyence.io, no per‑environment app‑owned DB actually provisioned/wired, no confirmed Doorway registration and secret injection for the app, no live provider serving Articles, no Composer authoring on the real app, no preview/production behavior demonstrated, and no executed Articles migration. These are end‑to‑end, user‑visible criteria; current evidence shows enabling components and documentation, not the assembled system in operation.

Waived

  • Ability to create a new Public Web Application end‑to‑end through Orchestrator (for www‑xyence‑io) — Worked in alternative brief. (human:workspaces-orchestrator-app)
  • Deploy the new business website to Preview at www.staging.xyence.io — Worked in alternate brief. (human:workspaces-orchestrator-app)
  • Deploy the application’s Production environment (published‑only) without cutting over www.xyence.io — Worked in alternative brief. (human:workspaces-orchestrator-app)
  • Application‑owned database provisioning (per‑environment) and wiring to provider — Worked in alternative brief. (human:workspaces-orchestrator-app)
  • Routes managed through the Application lifecycle (provision/update) — Worked in alternate brief. (human:workspaces-orchestrator-app)
  • Doorway registration performed for the www‑xyence‑io app with credentials injected (names only in Hub; secrets in Secret Manager) — Worked in alternate brief. (human:workspaces-orchestrator-app)
  • Content Workspace can discover and manage the business website’s Articles (actual app) — Worked in alternative brief. (human:workspaces-orchestrator-app)
  • Composer can create and edit Article drafts for the business website — Worked in alternate brief. (human:workspaces-orchestrator-app)
  • Draft Articles can be rendered through the actual business website preview — Worked in alternative brief. (human:workspaces-orchestrator-app)
  • Published Articles appear through the production website (app’s Production environment) and drafts never appear publicly — Worked in alternative brief. (human:workspaces-orchestrator-app)
  • Migrate selected existing Articles (author and date metadata preserved) — Worked in alternate brief. (human:workspaces-orchestrator-app)
  • Static page/app changes continue via Composer/Orchestrator (no generalized CMS) — Worked in alternative brief. (human:workspaces-orchestrator-app)
  • www.staging.xyence.io serves the new application’s preview site — Worked in alternative brief. (human:workspaces-orchestrator-app)

Plan waves — 6 approved waves

planning closed
  1. Wave 1completeAPPROVED6 work items

    Deliver the platform foundation for app-oriented topology (repos are an implementation detail, not the primary abstraction) and a minimal, shippable Content Management V1 that can serve content to a site. Foundation includes: a source-of-truth topology manifest in Hub, Orchestrator views for Applications and repository relationships, platform ADRs in OutShine, a basic content backend in OutShine, a typed client in Workspaces, and first consumer integration in the St. Louis site.

  2. Wave 2foundation-firstAPPROVED6 work items

    Wave 2 will restore Application provisioning as a primary deliverable and reconcile prior Content V1 work without restarting. This wave delivers: (a) a formal disposition of wave-1 artifacts and provider reinterpretation (docs), (b) an extended Hub topology manifest for application provisioning (envs, routes, DB, content capability pointer), (c) an Application template registry with a Public Web Application scaffold (including a placeholder content capability declaration for Articles), (d) repository creation + scaffolding in Orchestrator, (e) Hub manifest PR automation from Orchestrator, and (f) a feature-flagged Create Application flow that composes these pieces. Provider boundary adaptations, Workspace/Composer integration, Doorway automation, migration of existing Articles, and the actual business website instantiation are deferred to the next wave.

    Deferred scope

    • Doorway registration & credential provisioning for new apps (no implicit Outshine data exposure) — Requires a clear provider boundary and secure secret handling; out of scope for this wave to reduce risk while Create flow is validated. (unblocks: Complete sequences 0–5 and validate Create flow end‑to‑end in dry‑run and one sandbox execution.) · retracted
    • Content Provider boundary implementation and Workspaces client adaptation — Provider contract details need to be codified and exercised against an application; focus this wave on provisioning to avoid inventing identifiers prematurely. (unblocks: Provider reinterpretation doc (seq 0) approved; initial app repo exists via Create flow; then implement boundary and adapt client.) · retracted
    • Business website instantiation (name/repo selection), deployment, and routing to production — Depends on Create flow stability and operator choice of application name/repo and hostnames. (unblocks: Create flow validated in a sandbox; operator provides application/repo name and hostnames; Hub PR process validated.) · retracted
    • Articles data migration from current business website into the new application‑owned database — Requires the target app’s DB schema and data contract to be finalized under the provider boundary; source system and subset to migrate are open questions. (unblocks: Provider boundary implemented; target app repository and DB provisioned; operator confirms migration source/scope.) · retracted
    • Preview and publish pipeline integration (draft isolation, published visibility) — Needs provider boundary and application deployment pipeline in place; not blocking Create flow. (unblocks: Application deployed to Preview/Production; provider boundary implemented; establish preview isolation semantics.) · retracted
    • Composer integration for the new app’s Articles via Content Workspace — Requires the provider boundary, app’s content contract resolved, and the app reachable via Doorway where needed. (unblocks: Provider boundary and app content contract implemented; Doorway registration completed safely.) · retracted
    Continuation checkpoint: Proceed to wave 3 when sequences 0–5 are merged and the Create Application flow has been demonstrated in dry‑run and one sandbox execution. Operator confirms the business website’s application name/repo slug and route hostnames for production instantiation. · decided: The repo will be Xyence/www-xyence-io - it is for the www.xyence.io website. Note that a different version of www.xyence.io is already live in production. I'd like to leave it that way until I'm ready to cut it over. In the meantime, www.staging.xyence.io can be used for the preview site and the DNS is already pointing to the host on which the code will run. The articles on the current www.xyence.io should be extracted and populated in the new site.
  3. Wave 3foundation-firstAPPROVED8 work items

    Wave 3 focuses on making the Create Application flow safely demonstrable end-to-end (dry-run + one sandbox execution) and laying the enforceable boundary between Content Workspace and application-owned content: platform-driven Doorway registration with least-privilege credentials, manifest references, a provider-boundary aware client in Workspaces (behind a flag), and a scaffolded provider surface in the Public Web Application template. Real application creation (Xyence/www-xyence-io), Articles migration into the app-owned DB, and full Composer/Workspace UX over the new provider are deferred to the next wave gated on the demo’s success.

    Deferred scope

    • Create the real business website application repo (Xyence/www-xyence-io) via the Create flow and deploy to Preview — Gate on successful demo dry-run and one sandbox execution review per the brief; the creation event is operational and should not be the first execution of the flow. (unblocks: Wave 3 demo harness merged; operator confirms dry-run and sandbox results as acceptable; feature flag enabled for production run in coordination with ops.) · ✓ resolved
    • Articles data migration from current www.xyence.io into the new application-owned database — Requires the target app repository and DB to exist and its provider endpoints to be reachable; also requires finalization of field mapping to the app’s chosen schema. (unblocks: Business website repo created and deployed to Preview with provider endpoints reachable; operator confirms migration source/scope and mapping approval.) · ✓ resolved
    • Composer/Workspace UI integration for Articles management via provider (app selection, end-to-end flows) — Client support lands in this wave; full UI wiring is safer after the provider endpoints exist in the new app and Doorway credentials are provisioned. (unblocks: Business website app created; provider endpoints functional; Doorway reference resolvable via Hub; feature flag ready to enable UI path.) · ✓ resolved
    • Preview/publish pipeline enforcement and route wiring in the running app — Template scaffolds isolation; enforcement needs to be validated in the actual application context with real routes and deployments. (unblocks: Business website repo created and deployed to Preview; content provider endpoints in place; initial content available.) · ✓ resolved
    Continuation checkpoint: Proceed to wave 4 once: (a) Create Application demo harness is merged and used to complete a dry-run and one sandbox execution with logs/artifacts reviewed and approved; (b) Doorway registration integration is shipping but feature-gated; (c) Hub manifest updates for doorway/provider have merged; and (d) operator signs off on secrets storage choice and provides the sandbox repo/namespace. · decided: Credential store: do NOT use GitHub Repository Secrets. They are readable only by GitHub Actions workflows and are write-only through the API, so a deployed application cannot read its own Doorway credential at runtime; using them would mean injecting the credential at deploy time into a plaintext .env on the host, which is worse than what we already do. Use AWS Secrets Manager. Reuse the account, the KMS key and the operational practice that OutShine's integration already proves, but NOT OutShine's integration itself: the platform gets its own Secrets Manager client under its own prefix (e.g. xyence/apps/<app>), not outshine/*. Storing platform secrets by calling OutShine would make the platform depend on OutShine for its own credentials, inverting the very boundary Doorway exists to establish. Sandbox for the demo run: use the separate org Xyence-sandbox, which already exists. Application repos are created under Xyence-sandbox, and the Hub manifest PR targets Xyence-sandbox/hub, which also already exists. Scope the repository-creation credential to Xyence-sandbox alone, so a misconfigured owner value cannot create in the real org — a permission boundary rather than a naming convention, which is what an untested creation path warrants. Note that dry-run is all-or-nothing (the flow's dry-run state is the OR of the repository and Hub sub-services, forced together from the master flag), so the sandbox execution will create a real repository AND open a real Hub PR; both must point at Xyence-sandbox. For the later production run, the same settings move to owner Xyence and Hub repository Xyence/hub. Resource provisioning: confirmed, PostgreSQL only for V1. One operational note: APPLICATION_CREATE_FLOW_ENABLED, APPLICATION_CREATE_FLOW_DRY_RUN, APPLICATION_REPOSITORY_CREATION_* and HUB_MANIFEST_* are all currently unset on the box, so the flow resolves to disabled/preview. The demo needs those set deliberately by the operator before it can do anything.
  4. Wave 4foundation-firstAPPROVED5 work items

    Wave 4 will make the new business website application real and manageable end‑to‑end without cutting over production: finish the Public Web App provider scaffold so Articles are first‑class in app‑owned storage, equip Workspaces with a provider‑aware UI for Articles, add a guarded production‑run harness to the Create flow, and provide a one‑time migration tool to populate Articles into the new app via the provider contract. Preview/publish isolation is enforced in the app template so the created app immediately behaves correctly in Preview. Production cutover, media/image handling and any SEO/search niceties remain deferred.

    Deferred scope

    • Images/media for Articles (storage, URLs, migration) — planned for future (unblocks: Operator decision on image scope and storage strategy (e.g., S3 bucket and URL pattern); design doc approved.) · filed → RM-0001
    • Production cutover of www.xyence.io routing — Operator explicitly retains current production site until a separate authorized cutover; outside Wave 4. (unblocks: Operator authorization to cut over and a cutover runbook ready; preview validated by stakeholders.) · ✓ resolved
    • Richer Composer/Workspace UX (WYSIWYG, media pickers, search) — V1 brief rejects a generalized page CMS and rich editor scope; limit to minimal Articles flows for validation. (unblocks: Post‑V1 prioritization.) · ✓ resolved
    • Sandbox repo naming/cleanup policy — Operational hygiene for demos; non‑blocking for delivering the business site. (unblocks: Operator provides policy.) · retracted
    Continuation checkpoint: Eligible for Wave 5 when: (a) Template provider completed and merged (seq 0), (b) Workspaces provider‑aware UI merged (seq 1), (c) Production Create harness merged and a sandbox validation recorded (seq 2), (d) Hub docs updated (seq 3), and (e) Operator has executed the production Create run to create Xyence/www-xyence-io and deploy Preview, with a basic health check passing. Optionally, operator decides on image/media scope.
  5. Wave 5foundation-firstAPPROVED5 work items

    Wave 5 focuses on enabling real-world management of the new business website’s Articles through Workspaces over the provider boundary, hardening and operationalizing Doorway credentials (rotation and scope policy), adding operator observability for provider health and credential state, and documenting a production cutover runbook and redirect manifest proposal. It deliberately avoids media/images and the actual production cutover, which remain deferred pending operator decisions.

    Deferred scope

    • Images/media for Articles (storage, URLs, migration) — Operator decision on image scope and storage strategy is still pending; V1 remains PostgreSQL-only. Avoid adding object storage without the approved design. (unblocks: Operator approves storage strategy and URL pattern; design doc accepted) · ✓ resolved
    • Production cutover execution of www.xyence.io routing — The brief requires an explicit operator authorization to cut over a live business hostname; we are providing a runbook now and will only execute upon approval. (unblocks: Operator authorization recorded; preview validated; rollback plan accepted) · ✓ resolved
    • Richer Composer/Workspace UX (WYSIWYG, media picker, search) — Out of scope for V1; not required to demonstrate the application-owned content lifecycle. (unblocks: Post‑V1 prioritization decision by product/ops) · ✓ resolved
    • Automated/scheduled Doorway credential rotation — Operationally beneficial but not required for V1; manual rotation capability ships first to validate the path. (unblocks: Successful manual rotation executed and monitored; target rotation interval agreed with ops) · ✓ resolved
    • Sandbox repo/manifest cleanup automation and naming policy — Useful to keep the sandbox tidy, but not required to reach V1 outcome; requires operator policy on retention and naming. (unblocks: Operator provides naming convention and retention/cleanup expectations) · ✓ resolved
    Continuation checkpoint: Eligible for wave 6 when: (1) All wave 5 items are merged and validated; (2) Provider-boundary Articles management is enabled and successfully used for Xyence/www-xyence-io; (3) A successful credential rotation for www-xyence-io has been executed and observed without downtime; plus operator decisions: images/media strategy (if any for V1.5/next) and explicit authorization to execute production cutover when ready.
  6. Wave 6completeAPPROVED6 work items

    Wave 6 closes out Application Platform Foundation & Content Management V1 by hardening the provider boundary, making provider-backed Articles management generally available in Workspaces, surfacing repository/resource relationships and operational state in Orchestrator, stabilizing the Hub provider manifest docs as V1, and adding an Orchestrator conformance runner plus a readiness checklist so operators can verify www-xyence-io is production-ready without cutting over routing. No changes are made to the live www.xyence.io routing, and media/images remain out of scope per prior deferral.

Work items

#TitleRepositoryStateIssuePR / CIReview
w1·0Author ADRs: Application abstraction + Content Management V1 (platform decisions)outshineCOMPLETED#502#504merged · CI passedc1: request_changes, c2: approve
w3·0Create Application flow: dry‑run + sandbox demo harness, gating, and operator runbookorchestratorCOMPLETED#512#517merged · CI passedc1: approve
w2·0Document wave‑1 Content V1 dispositions and provider reinterpretation (RETAIN / MODIFY / SUPERSEDE)outshineCOMPLETED#511#512merged · CI passedc1: approve
w4·0Public Web App template: complete Articles provider (app‑owned DB) and preview/publish enforcementorchestratorCOMPLETED#522#527merged · CI passedc1: approve
w5·0Doorway provider credentials: add rotation support and harden scopes for Articles operationsoutshineCOMPLETED#535#536merged · CI passedc1: approve
w6·0Add provider conformance smoke-test runner and report UI for ApplicationsorchestratorCOMPLETED#543#546merged · CI passedc1: request_changes, c2: approve
w3·1Introduce platform-facing Doorway registration API for app providers (least-privilege credentials)outshineCOMPLETED#513#515merged · CI passedc1: approve
w5·1 ⛓Add Doorway credential rotation operation using AWS Secrets Manager for application providersorchestratorCOMPLETED#539#541merged · CI passedc1: approve
w1·1 ⛓Introduce platform-topology manifest (machine-readable application/repo relationships)hubCOMPLETED#69#70merged · no CI in this repoc1: approve
w2·1 ⛓Extend topology manifest spec for Application provisioning (envs, routes, DB, content capability pointer) and add Public Web App examplehubCOMPLETED#71#72merged · no CI in this repoc1: approve
w6·1Enable provider-boundary Articles management by default for eligible Applications; strengthen app scoping and empty statesworkspacesCOMPLETED#228#229merged · CI passedc1: approve
w4·1 ⛓Content Workspace UI: enable provider‑boundary Articles management for selectable apps (behind a flag)workspacesCOMPLETED#206#207merged · CI passedc1: approve
w5·2 ⛓Enable provider-boundary Articles UI for www-xyence-io by default; add provider health indicator and app scoping via HubworkspacesCOMPLETED#226#227merged · CI passedc1: approve
w6·2 ⛓Surface repository/resources, routes, Doorway and secrets state in Application vieworchestratorCOMPLETED#544#547merged · CI passedc1: request_changes, c2: approve
w4·2 ⛓Create Application: add a guarded production‑run harness for Xyence/www-xyence-ioorchestratorCOMPLETED#523#528merged · CI passedc1: approve
w1·2 ⛓Ingest Hub topology manifest and add Applications & Repository Relationship viewsorchestratorCOMPLETED#484#487merged · CI passedc1: request_changes, c2: approve
w2·2 ⛓Introduce Application Template registry and add “Public Web Application” scaffold (with Articles capability declaration placeholder)orchestratorCOMPLETED#501#506merged · CI passedc1: approve
w3·2 ⛓Create Application flow: integrate Doorway registration and credential injection (feature-flagged)orchestratorCOMPLETED#513#518merged · CI passedc1: approve
w3·3Topology manifest: extend docs/examples with doorway reference and provider descriptorhubCOMPLETED#73#74merged · no CI in this repoc1: approve
w4·3Docs/spec: clarify preview vs production route semantics; add www‑xyence‑io examplehubCOMPLETED#75#76merged · no CI in this repoc1: approve
w6·3Add tests asserting provider registration security invariants; document least-privilege and non-publication guaranteesoutshineCOMPLETED#537#538merged · CI passedc1: approve
w1·3 ⛓Implement Content Management V1 backend (domain, RBAC, API)outshineCOMPLETED#503#506merged · CI passedc1: approve
w2·3 ⛓Implement GitHub repository creation and template scaffolding service (feature-flagged, dry‑run + tests)orchestratorCOMPLETED#502#508merged · CI passedc1: request_changes, c2: approve
w5·3 ⛓Surface provider health and Doorway registration details in Application vieworchestratorCOMPLETED#540#542merged · CI passedc1: approve
w6·4Stabilize content provider manifest V1: version tag and canonical example for www-xyence-iohubCOMPLETED#79#80merged · no CI in this repoc1: approve
w3·4 ⛓Include doorway/provider references in generated Hub PR for new appsorchestratorCOMPLETED#514#521merged · CI passedc1: approve
w4·4 ⛓One‑time migration tool: import Articles from current www.xyence.io into the new app via provider endpointsorchestratorCOMPLETED#524#529merged · CI passedc1: approve
w2·4 ⛓Generate initial Hub manifests for new Applications and open a PR to Xyence/huborchestratorCOMPLETED#503#509merged · CI passedc1: approve
w1·4 ⛓Extend packages/api-client with Content Management V1 clientworkspacesCOMPLETED#191#193merged · CI passedc1: approve
w5·4Document production cutover runbook for www.xyence.io and propose redirect manifest schema (docs-only)hubCOMPLETED#77#78merged · no CI in this repoc1: approve
w6·5 ⛓Add V1 readiness checklist in Application view (non-blocking) to verify preview readiness for www-xyence-ioorchestratorCOMPLETED#545#548merged · CI passedc1: approve
w1·5 ⛓Consume Content Management V1 in St. Louis site (SSR page by slug)stlouis-xyence-ioCANCELLED#183——
w3·5 ⛓Public Web Application template: scaffold provider surface and preview/publish skeleton for ArticlesorchestratorCOMPLETED#515#519merged · CI passedc1: request_changes, c2: approve
w2·5 ⛓Wire a feature‑flagged “Create Application” flow composing repo creation and Hub PR generationorchestratorCOMPLETED#504#510merged · CI passedc1: approve
w3·6 ⛓Content client: add provider-boundary mode (behind a flag) using Doorway to target app-owned providersworkspacesCOMPLETED#204#205merged · CI passedc1: approve
w3·7 ⛓Provider boundary governance notes: reinterpret Content V1 as Outshine-owned provider (docs)outshineCOMPLETED#514#516merged · CI passedc1: approve

Release candidate

All work complete — merged, reviewed, and unblocked. Release and deployment remain manual.

outshinePR #504 · merged a680bf2e2d · review approve
orchestratorPR #517 · merged 960aff82f7 · review approve
outshinePR #512 · merged 7b10e90cf1 · review approve
orchestratorPR #527 · merged 4e38377ab5 · review approve
outshinePR #536 · merged 8b0225af98 · review approve
orchestratorPR #546 · merged 857043f6af · review approve
outshinePR #515 · merged 2a7e6b8371 · review approve
orchestratorPR #541 · merged eb380b9898 · review approve
hubPR #70 · merged 1ca607d12c · review approve
hubPR #72 · merged d512a003ae · review approve
workspacesPR #229 · merged 07ee77abb4 · review approve
workspacesPR #207 · merged cd192e04fa · review approve
workspacesPR #227 · merged 17aae885e5 · review approve
orchestratorPR #547 · merged 8566a92c16 · review approve
orchestratorPR #528 · merged 11c60f36ef · review approve
orchestratorPR #487 · merged 583a0ccffa · review approve
orchestratorPR #506 · merged e03aa69e62 · review approve
orchestratorPR #518 · merged e3b0a0a884 · review approve
hubPR #74 · merged f834443183 · review approve
hubPR #76 · merged 634346acea · review approve
outshinePR #538 · merged 873f8a70c8 · review approve
outshinePR #506 · merged ab287667a7 · review approve
orchestratorPR #508 · merged 18a856a30a · review approve
orchestratorPR #542 · merged 4400e93312 · review approve
hubPR #80 · merged 7ee720aefe · review approve
orchestratorPR #521 · merged 57ceb9da62 · review approve
orchestratorPR #529 · merged a2ce7026a6 · review approve
orchestratorPR #509 · merged 10b69968bd · review approve
workspacesPR #193 · merged 28c46bcda0 · review approve
hubPR #78 · merged f0af2bc4bb · review approve
orchestratorPR #548 · merged 6280076edb · review approve
stlouis-xyence-ioPR # · merged n/a · review n/a
orchestratorPR #519 · merged 7bed50b22f · review approve
orchestratorPR #510 · merged 257143c4a2 · review approve
workspacesPR #205 · merged f287c419f7 · review approve
outshinePR #516 · merged a50cd887e6 · review approve

Questions

agent:openai · 8/19/2026, 7:38:24 PM

Every work item is complete, but 19 brief criterions do not appear satisfied. Plan more work, or waive them?

ANSWERED

Foundational pieces are in place (Create Application flow with mandatory dry‑run, repo scaffolding, Hub manifest generation, Doorway registration API and integration hooks, Public Web App template with content capability and provider skeleton, provider‑boundary client/UI in Workspaces, migration tool, and Hub manifest spec additions). However, the assembled system the brief requires has not been demonstrated end‑to‑end: no evidence of a successful sandbox execution of the Create flow, no actual creation of the Xyence/www-xyence-io application repository and merged Hub manifest, no deployed Preview/Production environments or routes, no live Doorway registration and secret injection, no implemented-and-exposed provider HTTP endpoint in the app, no Preview site at www.staging.xyence.io, and no executed Articles migration. Workspace/Composer management is present behind flags but not shown working against the business website’s provider. Therefore the initiative’s user‑visible outcome and several acceptance criteria remain partial or unproven. Unmet criteria: - Create Application flow demonstrated end-to-end in dry-run and one sandbox execution with artifacts reviewed — Dry‑run harness and runbooks delivered (orchestrator #512, #523), Create flow endpoint with mandatory preview (orchestrator #504). No evidence the sandbox execution actually ran and was reviewed. - A new Public Web Application can be created through the Orchestrator Application Platform — Repo creation service (#502) and composed Create flow (#504) exist but are feature‑flagged; tests show dry‑run/guardrails. No successful execute path recorded. - Business website is represented as an Application (not just an external repo) — Hub manifest generator/PR service (#503, #514) and Orchestrator ingestion/views (#484) exist; #523 shows a dry‑run manifest for www‑xyence‑io. No actual PR merge or live manifest entry shown. - Appropriately scoped repository and resources for the Application — Public Web App template with scaffolded assets and capability pointer (#501, #515, #522) and Hub spec for resources (#71/#73). No actual resource provisioning evidenced. - Application can receive an application-owned database resource — Hub spec supports DB resources (#71), manifest generator includes application‑owned DB (#503/#514), template includes migrations (#523 artifacts). No provisioning/controller or created instances shown. - Preview and Production concepts exist for the Application — Spec/docs and template gating delivered (#71, #75, #515). No deployed environments shown. - Routes are managed through the Application lifecycle — Routes modeled in Hub spec and generated in PRs (#71/#73/#503/#514); Create flow composes this (#504). No end‑to‑end route activation beyond examples/dry‑run. - Outshine-connected Application can receive a Doorway registration — Outshine Doorway registration API (#513, outshine) and Create flow Doorway step (feature‑flagged) (#513, orchestrator) with dry‑run planning (#523). No live registration/secret injection shown. - Application explicitly exposes an Article content capability — Template carries content/capability declaration (#501/#515); dry‑run artifacts show capability.jsonc in new repo (#523). Not yet realized in a created app. - Business website’s Articles are owned by the business website Application — Template/provider skeleton and DB migration indicate app‑owned storage (#515/#523), and governance docs/ADRs reframe ownership (#502/#514). Not yet proven by a running app. - Content Workspace can discover and manage the business website’s Articles — Discovery/UI implemented behind a flag (#206) and Hub spec supplies descriptors (#73). Requires the business website app manifest/provider to be live and reachable; not shown. - Composer can create and edit Article drafts — Editor form/components and provider‑boundary write ops exist (#206 workspaces, #204 client). Lacks evidence of end‑to‑end save against the business website’s provider. - Draft Articles can be rendered through the actual business website preview — Template includes preview gating (#515) but no deployed Preview app or wired provider endpoints demonstrated. - Published Articles appear through the production website — No deployment/cutover to serve production from the new app; docs explicitly keep existing site live (#75). - Draft Articles do not appear publicly through production — Provider/environment gating scaffolds this (#515/#75). Needs production deployment to validate behavior. - Existing selected Articles are migrated (author/date metadata preserved) — One‑time migration tool delivered with dry‑run/execute and mapping (#524). No executed migration or verification of author/date mapping shown. - Static page and application changes via Composer/Orchestrator without a generalized CMS — Out of scope to generalize CMS; platform UIs exist, but no demonstration of such changes on the new app. - New business website can be deployed through the resulting Application lifecycle — No provisioning/deployment controller shipped; spec/docs only (#71/#75). - www.staging.xyence.io serves the new application’s preview site — Hostname documented and used in examples/dry‑run (#523/#75), but no deployed app serving there. The initiative stays in EXECUTING until each unmet criterion is either delivered by further work or waived deliberately.

Answer: Plan more work

agent:openai · 8/18/2026, 1:40:54 PM

Does stlouis-xyence-io#183 remain open for reasons outside this initiative, or may we explicitly mark it superseded in documentation cross-references? (No code change proposed either way.)

ANSWERED

Secrets handling location for Doorway credentials, scope of resource provisioning beyond Postgres, and the operator-provided sandbox repo/namespace are policy and operational decisions only the operator can decide. Proceeding without those answers risks unsafe defaults or failed demonstrations.

Answer: Already settled by the record, not an open decision. Xyence/stlouis-xyence-io#183 was closed as not planned on 2026-08-17, and its orchestrator work item is CANCELLED. The closing comment already states it is superseded by Initiative Brief revision 2 and gives the reason (it assumed content is canonically stored in OutShine and that stlouis-xyence-io is the primary validation application). So yes, treat it as superseded in documentation cross-references — the issue itself is the cross-reference. No code change either way, as the question notes.

agent:openai · 8/18/2026, 1:40:54 PM

Provide the sandbox repository name/namespace and any constraints for the Create Application flow demonstration (e.g., org, naming convention, retention/cleanup expectations).

ANSWERED

Secrets handling location for Doorway credentials, scope of resource provisioning beyond Postgres, and the operator-provided sandbox repo/namespace are policy and operational decisions only the operator can decide. Proceeding without those answers risks unsafe defaults or failed demonstrations.

Answer: Use the separate GitHub organisation Xyence-sandbox for the demonstration. Application repositories are created under Xyence-sandbox and the Hub manifest PR targets Xyence-sandbox/hub; both already exist and the GitHub App is installed on the org with repository selection 'all', which is required because the repositories it creates do not exist at install time (installation id 154727063). Note dry-run is all-or-nothing — the flow's dry-run state is the OR of the repository and Hub sub-services, forced together from the master flag — so a sandbox execution creates a real repository AND opens a real Hub PR; both must point at Xyence-sandbox. Naming convention and retention/cleanup expectations are NOT yet answered and are being put back to the operator.

agent:openai · 8/18/2026, 1:40:54 PM

Confirm PostgreSQL is the only resource to provision in V1. If additional resources (e.g., object storage for images) are required for Articles, list them so we can extend the manifest and secrets wiring.

ANSWERED

Secrets handling location for Doorway credentials, scope of resource provisioning beyond Postgres, and the operator-provided sandbox repo/namespace are policy and operational decisions only the operator can decide. Proceeding without those answers risks unsafe defaults or failed demonstrations.

Answer: Confirmed: PostgreSQL is the only resource to provision in V1. The follow-up about object storage for Article images is NOT answered and is being put back to the operator — do not assume either way. If images are in scope for the Articles migration from the current www.xyence.io, an object store and its secrets wiring would be additional V1 scope; plan on PostgreSQL-only until that is answered explicitly.

agent:openai · 8/18/2026, 1:40:54 PM

Confirm that GitHub Repository Secrets are an acceptable storage location for initial Doorway client credentials minted for the new application; if not, specify the secret store to integrate for wave 3.

ANSWERED

Secrets handling location for Doorway credentials, scope of resource provisioning beyond Postgres, and the operator-provided sandbox repo/namespace are policy and operational decisions only the operator can decide. Proceeding without those answers risks unsafe defaults or failed demonstrations.

Answer: No — GitHub Repository Secrets are not acceptable. They are readable only by GitHub Actions workflows and are write-only through the API, so a deployed application cannot read its own Doorway credential at runtime; using them would mean injecting the credential at deploy time into a plaintext .env on the host. Integrate AWS Secrets Manager. Reuse the account, KMS key and operational practice OutShine's integration already proves, but not OutShine's integration itself: the platform gets its own Secrets Manager client under its own prefix (e.g. xyence/apps/<app>), not outshine/*. Storing platform secrets by calling OutShine would make the platform depend on OutShine for its own credentials, inverting the boundary Doorway exists to establish. Recorded in full as the wave 3 continuation decision.

agent:openai · 8/17/2026, 10:24:38 AM

Every work item is complete, but 23 brief criterions do not appear satisfied. Plan more work, or waive them?

ANSWERED

What is delivered: (1) An application-centric topology manifest in Hub and Orchestrator views that ingest/render it (#69 Hub, #484 Orchestrator) — meets the “Applications are primary, repos are surfaced behind them” foundation. (2) A Content Management V1 module in Outshine with RBAC-gated authoring, audited draft→publish lifecycle, and a published-only public read surface behind a feature flag (#503 Outshine). (3) A typed read client in Workspaces to consume a content API (#191 Workspaces). What is not delivered relative to the brief’s end-to-end target: no Orchestrator-driven creation/provisioning of a new Public Web Application (repo scaffold, resources, app-owned DB, Preview/Production envs, routes), no Doorway registration step, no provider/contract boundary by which Content Workspace discovers/manages application-owned articles, no Content Workspace or Composer integration for article authoring/management, no application-owned article store or migration of existing site articles, no preview rendering path for draft articles or production rendering path for published articles via the new business website, and no evidence the new business website is deployed through the Application lifecycle. Additionally, the delivered Outshine content module centralizes content in Outshine, which conflicts with the brief’s architectural invariant that the business website Application owns its content records; it can be reused as an Outshine provider, but it does not satisfy the ownership model for the validation path. The Workspaces content client exists but is not shown working end-to-end against the implemented public read (and will need to align to the eventual provider contract and the chosen endpoints). Given the brief’s scope (assembled system behavior), these gaps keep the initiative from meeting its stated outcome. Unmet criteria: - A new Public Web Application can be created through the Orchestrator Application Platform (provisioning lifecycle) — No story provisions apps/resources; #484 is read-only ingestion and views. - The new business website is represented as an Application rather than merely an externally created repository — Representation via Hub manifest + Orchestrator views exists, but the new business website itself is not created or wired into that lifecycle. - Application has appropriately scoped repository and resources — No provisioning/scaffolding/resources delivered; manifest lists components but does not create resources. - Application can receive an application-owned database resource where required — No app-owned DB provisioning for the new site is implemented. - Preview and Production concepts for the Application — No environments created or exercised for the new site. - Application routes managed through the Application lifecycle — No route setup/management implemented for the new site. - Outshine-connected Application receives an associated Doorway registration — No Doorway registration flow delivered in this wave. - Doorway registration does not implicitly publish Outshine data — No new registration is implemented; existing controls are not exercised end-to-end for the new app. - Application explicitly exposes an Article Content capability (declared capability boundary) — No provider/contract by which an Application declares its content capability is delivered. - Provider/contract boundary exists between Content Workspace and content persistence — No content-provider contract or Workspace-side integration is implemented. - Business website’s Articles are owned by the business website Application (not canonically stored in Outshine) — Delivered content module centralizes in Outshine (#503), contrary to the brief’s ownership invariant; no app-owned article store for the new site exists. - Content Workspace does not require those Articles to be canonically stored in Outshine — Workspace content management against an app-owned store is not present; only an Outshine-centered module exists. - Content Workspace can discover and manage the business website’s Articles — No Workspace UI or discovery/management integration delivered in this wave. - Composer can create and edit Article drafts — No Composer integration/stories delivered here. - Draft Articles can be rendered through the actual business website preview — No preview environment or draft-rendering path for the new site is implemented. - Published Articles appear through the production website — No production rendering path for the new site implemented; St. Louis SSR consumer story (#183) is still open and not the primary validation per the brief. - Draft Articles do not appear publicly through production — Outshine public API enforces published-only and is feature-flagged (#503), but there is no end-to-end site integration demonstrating the production boundary. - Selected existing Articles are migrated with metadata (author/date) — No migration tooling or data movement delivered. - Static page and application changes continue via Composer and Orchestrator (no generalized CMS) — No Composer/Orchestrator flows for static/app changes delivered; nothing blocks it, but it is not shown working for the new site. - The new business website can be deployed through the resulting Application lifecycle — No deployment lifecycle for a new site implemented. - Invariants: Draft Articles never publicly accessible; production exposes Published only — Server-side enforcement exists in Outshine public read (#503), but no production site integration demonstrates the invariant end-to-end. - Invariants: Route vs Doorway remain separate in the Application Platform model — No new coupling introduced; however, without the new app lifecycle implemented, the separation is not exercised for this validation path. - Typed content read client for consumers — Workspaces #191 provides a read client, but it targets a generic '/content' shape; alignment to the delivered public endpoints/provider contract and end-to-end integration is not shown. The initiative stays in EXECUTING until each unmet criterion is either delivered by further work or waived deliberately.

Answer: plan more work

Timeline

No events yet.

    ← All initiatives