Xyence Orchestrator
Create initiative

Initiative Brief: Instantiate the business website on the Application Platform

EXECUTING
Intent— the specification (8,124 chars); the plan below decomposes it into work items. Click to expand.

# Initiative Brief: Instantiate the business website on the Application Platform ## Desired outcome Use the Application Platform that already exists to create, deploy and populate the real business website: `Xyence/www-xyence-io`, serving a preview at `www.staging.xyence.io`, with the Articles from the current `www.xyence.io` migrated into it and manageable through Content Workspace and Composer. This initiative EXECUTES. It builds no new platform capability. Where something is missing it is a gap discovered by running the thing, and the smallest change that unblocks execution is the right one. The business website runs as an Application created by the platform. Its Articles are owned by that Application, edited through Composer and Content Workspace, previewed on `www.staging.xyence.io`, and published within the new application — while `www.xyence.io` continues to serve the existing site untouched. Every criterion is judged by the assembled system doing the thing, not by a component that could do it. ## Motivation The Application Platform Foundation initiative ran six waves and reached its wave cap. It delivered platform ADRs, topology manifest extensions for Application provisioning, an Application Template registry with a Public Web Application scaffold, a GitHub repository creation and scaffolding service, Hub manifest PR generation, a feature-flagged Create Application flow, a Doorway registration API with credential rotation through AWS Secrets Manager, a provider-boundary content client, Content Workspace provider-boundary Articles management, a one-time Articles migration tool, provider conformance smoke tests, and a V1 readiness checklist. Its brief assessment then found nineteen criteria unmet, and every one of them is an outcome rather than a component: "a new Public Web Application can be created through the Orchestrator Application Platform", "the business website's Articles are owned by the business website Application", "www.staging.xyence.io serves the new application's preview site". The assessment's own summary: *"The repository shows plans, harnesses, UI, docs, and tests, but not the executed creation and deployment of the www-xyence-io application, its app-owned provider and database, preview site at www.staging.xyence.io, or completed article migration. Where criteria require the assembled system to function (not just component correctness), evidence stops at scaffolds, specs, and dry-run artifacts."* `Xyence/www-xyence-io` does not exist. `Xyence-sandbox` contains only a `hub` repository, so even the sandbox demonstration has never run. Six waves of building were never followed by a wave of using. That is why this is a separate initiative rather than a seventh wave. The foundation is not in question; what is untested is whether it works when run. ## Current state - **The Create Application flow exists and is feature-flagged off.** `APPLICATION_CREATE_FLOW_ENABLED`, `APPLICATION_CREATE_FLOW_DRY_RUN`, `APPLICATION_REPOSITORY_CREATION_*` and `HUB_MANIFEST_*` are all unset on the box, so it resolves to disabled/preview and writes nothing. - **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. - **The flow can use its own GitHub identity** (`APPLICATION_CREATE_GITHUB_APP_*`, Orchestrator v0.4.22), so a sandbox run no longer has to repoint the platform's installation. - **No GitHub App currently holds the `administration` permission** that creating a repository requires. Both installations — `Xyence` and `Xyence-sandbox` — carry contents, pull_requests, issues, actions and metadata only. This is an operator prerequisite, not development work. - Doorway registration and credential rotation exist; credentials belong in AWS Secrets Manager under the platform's own prefix, never routed through OutShine. - Content Workspace provider-boundary Articles management is enabled by default for eligible Applications, with app scoping through Hub and a provider health indicator. - A one-time Articles migration tool exists and has never been run against real content. - `www.staging.xyence.io` resolves to the host the application will run on. `www.xyence.io` serves the existing production site. ## Architectural principles - The platform is the subject under test. Every step that could be done by hand should be done through the platform instead, because the initiative's whole value is discovering where it does not work. - A gap found by running is worth more than a gap found by reading. Where execution reveals a missing capability, record it as evidence rather than treating it as a plan defect. ## Rejected / deferred alternatives - Production cutover of `www.xyence.io`. - Images and media for Articles — storage, URLs and their migration. - Richer Composer authoring (WYSIWYG, media pickers, search). - A generalized page CMS or universal content schema; V1 supports Articles only. - New platform capability beyond what execution proves is missing. ## Constraints - Do not change what `www.xyence.io` serves. Production cutover is a separate, explicitly authorized operator step outside this initiative. - Do not build new platform capability. If execution is blocked, prefer the smallest change that unblocks it, and record what was missing. - Do not create the application by hand. Creating it outside the flow would prove nothing about the platform and is the one shortcut that makes this initiative pointless. - The sandbox demonstration precedes the real creation. Sequence it first. - PostgreSQL only. No object storage: Articles migrate text-only for V1. - Credentials go to AWS Secrets Manager under the platform's own prefix, never routed through OutShine to store them. ## Repository scope - `Xyence/orchestrator` - `Xyence/hub` - `Xyence/outshine` - `Xyence/workspaces` - `Xyence/www-xyence-io` — created by this initiative ## Expected behavior - The Create Application flow is demonstrated end to end in dry-run, and then in one sandbox execution under `Xyence-sandbox`, with the created repository, its scaffold and the Hub manifest PR inspected before any real application is created. - Sandbox artifacts are deleted after each run, so every demonstration exercises creation rather than the adoption path an existing repository takes. - `Xyence/www-xyence-io` is created through the flow — not by hand — with its scaffold and its Hub manifest PR. - The Application receives an application-owned PostgreSQL database and explicitly exposes an Article Content capability. - A Doorway registration is issued for it, its credential stored in AWS Secrets Manager under the platform's own prefix. - The application is deployed through the Application lifecycle and `www.staging.xyence.io` serves its preview site. - Articles from the current `www.xyence.io` are migrated with their metadata, including author and date. - Content Workspace discovers and manages those Articles; Composer creates and edits drafts. - A draft renders through the preview site and does NOT appear publicly; publishing makes it appear on the new application's production surface. - Routes are managed through the Application lifecycle rather than configured by hand. - The V1 readiness checklist and provider conformance smoke tests pass against the created application. ## Open questions - Which GitHub App gains the `administration` permission, and is it a new App scoped to application creation or the existing platform App? A separate App keeps repository-administration rights off the platform identity; the platform App is one permission change away. This is a prerequisite for any real or sandbox creation. - Should the sandbox demonstration run once and be deleted, or should a sandbox application be kept for future flow changes to test against? - Which Articles from the current site are in scope — all of them, or a selected set? The previous brief's answer said the Articles on the current site; a count and a source of truth would make the migration verifiable.

hints: `Xyence/orchestrator`, `Xyence/hub`, `Xyence/outshine`, `Xyence/workspaces`, `Xyence/www-xyence-io` — created by this initiativecreated 8/20/2026, 4:58:23 PMby human:workspaces-orchestrator-app

Repository scope

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

Primary repository: orchestrator`

  • orchestrator`expected · primary
  • hub`expected
  • outshine`expected
  • workspaces`expected
  • www-xyence-io` — created by this initiativeexpected
  • orchestratordiscovered
  • outshinediscovered
  • hubdiscovered
  • workspacesdiscovered

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 2 (material)
Desired outcome
Use the Application Platform that already exists to create, deploy and populate the real business website: `Xyence/www-xyence-io`, serving a preview at `www.staging.xyence.io`, with the Articles from the current `www.xyence.io` migrated into it and manageable through Content Workspace and Composer. This initiative EXECUTES. It builds no new platform capability. Where something is missing it is a gap discovered by running the thing, and the smallest change that unblocks execution is the right one. The business website runs as an Application created by the platform. Its Articles are owned by that Application, edited through Composer and Content Workspace, previewed on `www.staging.xyence.io`, and published within the new application — while `www.xyence.io` continues to serve the existing site untouched. Every criterion is judged by the assembled system doing the thing, not by a component that could do it.
Motivation
The Application Platform Foundation initiative ran six waves and reached its wave cap. It delivered platform ADRs, topology manifest extensions for Application provisioning, an Application Template registry with a Public Web Application scaffold, a GitHub repository creation and scaffolding service, Hub manifest PR generation, a feature-flagged Create Application flow, a Doorway registration API with credential rotation through AWS Secrets Manager, a provider-boundary content client, Content Workspace provider-boundary Articles management, a one-time Articles migration tool, provider conformance smoke tests, and a V1 readiness checklist. Its brief assessment then found nineteen criteria unmet, and every one of them is an outcome rather than a component: "a new Public Web Application can be created through the Orchestrator Application Platform", "the business website's Articles are owned by the business website Application", "www.staging.xyence.io serves the new application's preview site". The assessment's own summary: *"The repository shows plans, harnesses, UI, docs, and tests, but not the executed creation and deployment of the www-xyence-io application, its app-owned provider and database, preview site at www.staging.xyence.io, or completed article migration. Where criteria require the assembled system to function (not just component correctness), evidence stops at scaffolds, specs, and dry-run artifacts."* `Xyence/www-xyence-io` does not exist. `Xyence-sandbox` contains only a `hub` repository, so even the sandbox demonstration has never run. Six waves of building were never followed by a wave of using. That is why this is a separate initiative rather than a seventh wave. The foundation is not in question; what is untested is whether it works when run.
Current state
• **The Create Application flow exists and is feature-flagged off.** `APPLICATION_CREATE_FLOW_ENABLED`, `APPLICATION_CREATE_FLOW_DRY_RUN`, `APPLICATION_REPOSITORY_CREATION_*` and `HUB_MANIFEST_*` are all unset on the box, so it resolves to disabled/preview and writes nothing. • **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. • **The flow can use its own GitHub identity** (`APPLICATION_CREATE_GITHUB_APP_*`, Orchestrator v0.4.22), so a sandbox run no longer has to repoint the platform's installation. • **No GitHub App currently holds the `administration` permission** that creating a repository requires. Both installations — `Xyence` and `Xyence-sandbox` — carry contents, pull_requests, issues, actions and metadata only. This is an operator prerequisite, not development work. • Doorway registration and credential rotation exist; credentials belong in AWS Secrets Manager under the platform's own prefix, never routed through OutShine. • Content Workspace provider-boundary Articles management is enabled by default for eligible Applications, with app scoping through Hub and a provider health indicator. • A one-time Articles migration tool exists and has never been run against real content. • `www.staging.xyence.io` resolves to the host the application will run on. `www.xyence.io` serves the existing production site.
Architectural principles
• The platform is the subject under test. Every step that could be done by hand should be done through the platform instead, because the initiative's whole value is discovering where it does not work. • A gap found by running is worth more than a gap found by reading. Where execution reveals a missing capability, record it as evidence rather than treating it as a plan defect.
Decisions
• All nine Articles on the current www.xyence.io are in scope, and each Article's publish date is preserved through the migration. — A definite count makes the migration verifiable — nine in, nine out, and a mismatch is a failure rather than a judgement call. Publish dates are the ordering and the provenance of the content; a migration that resets them to the migration date silently rewrites the site's history and cannot be undone from the target. • Creation demos use a throwaway repository that is deleted after each run, and a SEPARATE durable sandbox application is kept for testing everything downstream of creation. When the template changes, the durable one is rebuilt from scratch. — These are two fixtures, not one. The creation path only runs when the repository is ABSENT — when it exists the flow returns `already-exists`, adopts it and returns early with no scaffold pushed — so a demo re-run against a surviving repo exercises almost nothing and still reports success. Keeping one sandbox forever means creation is never re-tested. But Doorway registration, provider health, Content Workspace scoping, the conformance smokes and the migration tool all need an application to EXIST, and recreating one each time is friction for no benefit. Rebuilding the durable fixture when the template changes is itself a creation test, run at the moment it is most worth running. Note the durable application holds a real Doorway credential, so it is a secret with an owner and a rotation story rather than a scratch artifact. • Application creation uses its own GitHub App, separate from the platform App, installed on Xyence-sandbox first and on Xyence only when the real creation is ready. It needs organization Administration (to create the repository) plus repository Contents, Pull requests, Workflows and Metadata. — GitHub App permissions are declared on the App, not per installation, so adding Administration to the platform App would grant repository-administration across every org it is installed on — including Xyence — as a side effect of enabling a sandbox demo. The platform App is the identity behind issue creation, PR merging and release publishing everywhere. Orchestrator v0.4.22 already provides APPLICATION_CREATE_GITHUB_APP_* for exactly this separation. Workflows is required because the Public Web Application scaffold contains .github/workflows/ci.yml and GitHub refuses a push touching that path without it; repository Administration is NOT required because the flow supplies no repository topics.
Rejected / deferred alternatives
• Production cutover of `www.xyence.io`. • Images and media for Articles — storage, URLs and their migration. • Richer Composer authoring (WYSIWYG, media pickers, search). • A generalized page CMS or universal content schema; V1 supports Articles only. • New platform capability beyond what execution proves is missing.
Constraints
• Do not change what `www.xyence.io` serves. Production cutover is a separate, explicitly authorized operator step outside this initiative. • Do not build new platform capability. If execution is blocked, prefer the smallest change that unblocks it, and record what was missing. • Do not create the application by hand. Creating it outside the flow would prove nothing about the platform and is the one shortcut that makes this initiative pointless. • The sandbox demonstration precedes the real creation. Sequence it first. • PostgreSQL only. No object storage: Articles migrate text-only for V1. • Credentials go to AWS Secrets Manager under the platform's own prefix, never routed through OutShine to store them.
Repository scope
• `Xyence/orchestrator` • `Xyence/hub` • `Xyence/outshine` • `Xyence/workspaces` • `Xyence/www-xyence-io` — created by this initiative
Expected behavior
• The Create Application flow is demonstrated end to end in dry-run, and then in one sandbox execution under `Xyence-sandbox`, with the created repository, its scaffold and the Hub manifest PR inspected before any real application is created. • Sandbox artifacts are deleted after each run, so every demonstration exercises creation rather than the adoption path an existing repository takes. • `Xyence/www-xyence-io` is created through the flow — not by hand — with its scaffold and its Hub manifest PR. • The Application receives an application-owned PostgreSQL database and explicitly exposes an Article Content capability. • A Doorway registration is issued for it, its credential stored in AWS Secrets Manager under the platform's own prefix. • The application is deployed through the Application lifecycle and `www.staging.xyence.io` serves its preview site. • Content Workspace discovers and manages those Articles; Composer creates and edits drafts. • A draft renders through the preview site and does NOT appear publicly; publishing makes it appear on the new application's production surface. • Routes are managed through the Application lifecycle rather than configured by hand. • The V1 readiness checklist and provider conformance smoke tests pass against the created application. • All nine Articles from the current www.xyence.io are migrated, with author and publish date preserved. The count is asserted: nine articles exist in the new Application afterwards. • A migrated Article's publish date matches its date on the current site, not the date it was migrated.
Need to change the committed intent? Begin a revision — the current brief stays in force until you commit the new one.
Revision history (2)
  • r1 · superseded · material · Initiative Brief: Instantiate the business website on the Application Platform — created from an Initiative Brief
  • r2 · committed · material · Initiative Brief: Instantiate the business website on the Application Platform — Records the operator's answer on Articles scope: all nine on the current www.xyence.io are in scope and each publish date is preserved. The count is now asserted as a criterion so the migration is verifiable rather than judged, and preserving the date is stated separately because a migration that resets dates rewrites the site's history and cannot be undone from the target.

brief revision 2 — all 12 unmet criteria cleared

assessed with 44% confidence

Most delivered work adds the orchestration CLIs, runbooks, and scaffold needed to execute the initiative safely (sandbox creation demo tooling with cleanup, post‑create verification, E2E conformance/readiness, preview/publish gating at rendered routes, migration verification, and the Wave 3 top‑level execution CLI). However, the record shows no evidence that these tools were actually run to complete the end‑to‑end execution for this initiative. Specifically missing are proofs that the real application was created via the flow, deployed with preview live at www.staging.xyence.io, Doorway secret issued and stored, DB provisioned, Content Workspace authoring exercised against the app, and the nine‑article migration performed and verified (count and publish‑date preservation). Where a criterion asks for the assembled system’s behavior, the evidence today is only that the tools and tests exist; that is partial until an operator run captures real artifacts from the target environments.

Attested — performed by an operator

  • Create Application flow demo (dry‑run, then sandbox execution under Xyence‑sandbox) with repo/scaffold/Hub PR inspection before any real creation — Performed 2026-08-21. All three modes of create-application-sandbox run against Xyence-sandbox. dry-run: status=planned, no writes, 22 scaffold files planned. sandbox_demo: created Xyence-sandbox/create-app-demo-20260821t131943z and opened Hub PR #5, both inspected in the run log and JSON artifact before teardown. sandbox_durable: created create-app-durable-sandbox with Hub PR #2, retained as the durable fixture. All of this preceded any real creation. Reaching a passing demo required fixing orchestrator#576, #583, #586 and #589. (human:joshua)
  • Sandbox artifacts are deleted after each demo run (exercise creation, not adoption) — Verified 2026-08-21. The sandbox_demo run closed Hub PR #5, deleted the throwaway repository, reported status=cleaned exit 0, and the org listed afterwards showed only hub plus the intentional durable fixture. This exercises creation rather than adoption: the flow only scaffolds when the target is absent, so a surviving repo would silently take the adoption path next run. Cleanup correctness was itself a defect found here — orchestrator#584, where a failed run leaked a repository while reporting none was created. (human:joshua)
  • Create Xyence/www-xyence-io via the flow (not by hand), with scaffold and Hub manifest PR — Performed 2026-08-21 via create-application-prod --target prod --execute --i-understand --confirm-execute. Created Xyence/www-xyence-io (private, main) and pushed the 22-file scaffold as commit 0d8352b; opened Hub manifest PR #85 at applications/www-xyence-io.json, merged 15:02:33. Nothing was created by hand. (human:joshua)
  • Provision an application-owned PostgreSQL database and explicitly expose an Articles content capability — Verified 2026-08-21. The merged Hub manifest declares resources.database = {id: www-xyence-io-db, ownership: application-owned, engine: postgres} and content.collections = [articles]; the Application declares the capability in content/capability.jsonc and serves it at one provider endpoint. The running deployment has its own PostgreSQL instance (container www-xyence-io-postgres, named volume, shared with nothing else) holding the articles schema with 9 rows, and the provider contract passed 10/10 conformance. The database was provisioned by the operator because no provisioning controller exists to act on the manifest — hub/docs/topology-manifest-provisioning.md is explicit that it introduces none. (human:joshua)
  • Issue Doorway registration and store credential in AWS Secrets Manager under platform prefix — Performed 2026-08-21 by the flow. Doorway c963b160-2691-4071-ae7a-f890b4cf43d1 registered with content-management scopes only and exposes_outshine_data=false; credentials written to AWS Secrets Manager under xyence/apps/www-xyence-io/ and injected as encrypted repo secrets. Confirmed independently by verify-post-create --target prod: '[PASS] Doorway secret: credential present in AWS Secrets Manager'. Required a dedicated least-privilege IAM user (xyence-orchestrator-appsecrets), verified unable to read other secrets or list the account, and fixing orchestrator#592. (human:joshua)
  • Content Workspace discovers/manages Articles; Composer creates/edits drafts — Verified 2026-08-24 after orchestrator v0.4.32 and workspaces v0.4.25. Discovery: GET /orchestrator/content/applications returns Xyence Website (application:www-xyence-io) with collections [articles] and its preview/production routes, read from the merged Hub manifest — the controller previously served no such route at all (#599). Management: the Content Workspace now performs content operations through the controller, which resolves the Application's provider address and Doorway credential per request from Hub and Secrets Manager. Executed from inside the workspaces container using its own controller token: POST /orchestrator/content/applications/application%3Awww-xyence-io/operations with {operation: list} returned all nine Articles with titles, authors and preserved publish dates. The pane no longer reports 'Demo mode (no live provider)'. Draft authoring was exercised end to end through the same provider contract on 2026-08-21: a draft was created, rendered on the preview surface, confirmed absent from the production surface ('Article not found'), published, confirmed present, then archived and deleted. Reaching this required fixing #599 (missing discovery route) and #605 (per-Application environment variables in the workspace, plus a transport mismatch that would have defeated the direct binding anyway). (human:joshua)
  • Preview/publish gating: draft renders on preview, not public; publish makes it appear on production — Verified 2026-08-21 in both directions from one image, with only APP_DEPLOY_ENVIRONMENT distinguishing the surfaces. A draft created through the Doorway endpoint appeared on https://www.staging.xyence.io/articles with its detail page returning 200. Run as production against the same database it did not appear in the list and its detail page rendered 'Article not found'. Published through the provider, the production surface then listed it and returned 200. The probe was archived and deleted, leaving the nine migrated Articles. The preview half was also exercised by applicationE2eCli --gating. (human:joshua)
  • V1 readiness checklist and provider conformance smokes pass against the created application — Performed 2026-08-21 via applicationE2eCli --target prod against the live Application through its Doorway boundary. Provider conformance: PASSED, 10 passed / 0 skipped. V1 readiness checklist: all five checks passed — preview route responded HTTP 200 in 17 ms; the last conformance run passed; the published read returned 9 published Articles; the Doorway credential is present and current; and the Hub manifest is present at Xyence/hub@main:applications/www-xyence-io.json. Recorded in conformance.json and readiness.json of the run's evidence bundle. (human:joshua)
  • Migrate all nine Articles with author and publish date preserved; assert nine exist afterwards — Performed 2026-08-21. All nine Articles migrated from the www.xyence.io sources through the Doorway content-provider boundary — no direct database write — reporting created=9, published=9, errors=0. The database holds exactly 9 rows, 9 with an author and 9 with a publish date. Asserted independently by applicationE2eCli --verify-migration: 'All 9 Article(s) present with publish dates preserved', count 9/9, no unexpected or duplicate slugs. Author support had to be added first (orchestrator#595); the profile itself shipped as nine empty placeholders and was populated from the live site's own MDX sources (outshine#541). (human:joshua)
  • Each migrated Article’s publish date equals the source date (not migration date) — Verified 2026-08-21 by applicationE2eCli --verify-migration --target prod: PASS, zero failures. Stored dates span 2025-09-15T21:05:21Z to 2026-02-14T16:00:48Z — the source instants, not the migration clock. This did not hold on the first run: nothing in the contract could express a historical publish instant (orchestrator#593), so every Article carried migration time. Fixed on both sides and the nine repaired in place. Caveat for accuracy: two source timestamps carry microseconds (…19.296036Z) and store at millisecond precision (…19.296000Z), a JavaScript Date limit. The platform's own verifier treats these as preserved; a byte-equality checker would not. (human:joshua)

Waived

  • Deploy through lifecycle and have www.staging.xyence.io serve the preview site — Waived 2026-08-22 against orchestrator#603. The preview site genuinely serves — https://www.staging.xyence.io returns 200 for /, /articles and /articles/{slug} behind a Let's Encrypt certificate, with the nine migrated Articles. What is NOT true is 'through the lifecycle': merging Hub manifest PR #85 records the Application's topology and stands nothing up, because no provisioning controller exists. hub/docs/topology-manifest-provisioning.md states outright that the manifest layer introduces none. Verified after the merge: no container, HTTP 000 on the host, no database, and the template ships no Dockerfile or Compose file. The deployment was hand-built by the operator (Xyence/www-xyence-io#1). This initiative was scoped to instantiate the business website on the platform, not to build the platform's provisioning controller; that work is specified in orchestrator#603 and belongs to a platform initiative. Accepted as a deliberate gap so this initiative is not held open by a capability it was never meant to deliver. (human:joshua)
  • Routes managed through lifecycle, not hand configured — Waived 2026-08-22 against orchestrator#603, for the same reason and the same missing capability. The routes serving www.staging.xyence.io are hand-written Traefik labels in the Application's own Compose stack — correct per the platform's per-repo convention (Xyence/hub#58), and exactly what this criterion says should not be necessary. The merged Hub manifest declares the preview and production routes, and nothing reads that declaration: there is no reconciler to derive a router rule from environments[].routes[]. Three route runbooks already exist (#81, #83, and one in a discarded wave); documentation does not make routes lifecycle-managed. The reconciler is specified in orchestrator#603, with the running www-xyence-io stack as its reference implementation. www.xyence.io remains untouched; cutover is out of scope for this initiative. (human:joshua)

Plan waves — 3 approved waves

planning open
  1. Wave 1completeAPPROVED6 work items

    Prepare and execute the creation, verification, and population of the business website Application via the existing Application Platform by adding minimal tooling and runbooks in platform repos. The plan delivers: an orchestrator CLI and runbooks to demo dry-run and sandbox creation (with cleanup and a durable sandbox), post-create verification checks (Hub PR, Doorway secret, provider health), a migration profile and runbook for the nine Articles, an E2E runner to invoke provider smokes and the V1 readiness checklist, and documentation for authoring and route verification. No new platform capability is built; all work uses existing flows and tools.

  2. Wave 2foundation-firstAPPROVED2 work items

    Wave 2 focuses on making a newly created Public Web Application immediately capable of rendering and previewing Articles using existing platform facilities, and on adding automated verification of preview/publish gating. We avoid targeting the not-yet-existing www-xyence-io repo (not in the catalog) by updating the Application Template in orchestrator so every created app has the needed Articles surfaces by default. We also extend the E2E runner to programmatically validate preview vs. production behavior. Operational prerequisites (GitHub App administration permission) remain an operator decision.

    Deferred scope

    • Execute sandbox creation with the updated template and complete migration, then real creation of Xyence/www-xyence-io — Pending operator provisioning of a GitHub App with repository administration permission and merge of this wave’s PRs; execution is operational, not code. (unblocks: Both work items in this wave merged; GitHub App with admin permission installed on Xyence-sandbox and Xyence; sandbox creation run passes updated E2E gating checks.) · retracted
    • Per-repo customization of www-xyence-io (styling/branding/SEO) — Present initiative too large. (unblocks: Wave 3 completes with the real application running; business provides branding/SEO requirements.) · filed → RM-0002
    Continuation checkpoint: Eligible for Wave 3 when: (1) both orchestrator PRs in this wave are merged; (2) operator has installed a GitHub App with repository administration permission for creation on Xyence-sandbox (and later Xyence); (3) sandbox creation using the updated template completes and the new E2E preview/publish gating checks pass. · decided: Xyence Application Creator is installed on Xyence sandbox and has proper permission. You may proceed to real creation under Xyence after sandbox passes.
  3. Wave 3foundation-firstAPPROVED3 work items

    Wave 3 will EXECUTE the sandbox creation with the updated Public Web Application template, validate preview/publish behavior and provider health, run the Articles migration, then proceed to the real creation of Xyence/www-xyence-io and re-run end-to-end verification — using only existing platform capabilities. We add minimal orchestration/verification tooling and runbooks to make execution reproducible and auditable; no new platform features are introduced.

    Deferred scope

    • Per-repo customization of www-xyence-io (styling/branding/SEO) — Present initiative too large. (unblocks: Wave 3 completes with the real application running; business provides branding/SEO requirements.) · filed → RM-0002
    • Production cutover of www.xyence.io — Explicitly rejected by the brief for this initiative. (unblocks: Separate authorized operator decision outside this initiative.) · retracted
    • Images/media for Articles (storage, URLs, migration) — Will handle under another initiative. (unblocks: Operator decision on image scope and storage strategy with approved design.) · filed → RM-0003
    Continuation checkpoint: Eligible for Wave 4 when: (1) Sequence 0–2 merged; (2) Sandbox creation executed using the new orchestration CLI, with E2E preview/publish gating and provider health passing, migration completed, and migration verification (count=9, publish dates preserved) passing; (3) The Xyence Application Creator App is installed on the Xyence org; (4) Real creation executed with the same E2E and migration verification passing; (5) www.staging.xyence.io serves the preview site via lifecycle-managed routes; (6) Evidence bundle archived per runbooks. No additional operator decision is required beyond installing the App on Xyence.

Continuation wave 4 — review & approve

Proposed plan v6

Wave 4 will package evidence and operational guidance proving the business website Application runs on the platform as-created (no new platform features). We will: 1) extend the orchestrator E2E runner to emit a machine-readable evidence bundle and Markdown summary; 2) add a Hub docs evidence intake/sign-off template for www-xyence-io; 3) publish a Composer/Content Workspace editor guide tailored to the business website; and 4) add a README to www-xyence-io describing how the Application is operated and edited. Per-repo styling/branding/SEO and media/images remain deferred. This wave assumes the sandbox and real creation runs from Wave 3 have produced the live Application/repository; if not, the operator will run the Wave 3 execution flow before implementing the www-xyence-io README change.

Planner assumptions

  • Wave 3’s execution flow has run or will run prior to www-xyence-io–targeting work here, resulting in a real Application and the Xyence/www-xyence-io repository being present and reachable. If it has not run yet, the operator will execute the Wave 3 CLI per the existing runbook before work item 3 is attempted.
  • The Public Web Application template (updated in Wave 2) already provides Articles surfaces with preview/publish gating; we are not adding runtime features in this wave.
  • The E2E runner, migration profile, provider conformance smokes, and V1 readiness checklist from Waves 1–3 are available and functional; this wave only adds reporting around them.
  • The "Xyence Application Creator" GitHub App is installed on Xyence-sandbox (and, when authorized, on Xyence) with required permissions; no further changes to App permissions are needed for this wave.
  • No images/media migration is in scope (per brief). Articles are text-only and already migrated via the existing tool (or will be per runbooks).
  • We will not modify Hub manifests or lifecycle routes beyond existing flows; Hub docs-only changes are acceptable in this wave.
  • Adding documentation to Workspaces and www-xyence-io does not require new platform capabilities or credentials in CI.
  1. This story's text asks for database migrations, which its execution contract forbids. Reassign the repository or amend the contract now — otherwise the run will do the work and be blocked at the push. Grants are never inferred from the text.
    #0
  2. This story's text asks for database migrations, which its execution contract forbids. Reassign the repository or amend the contract now — otherwise the run will do the work and be blocked at the push. Grants are never inferred from the text.
    #1
  3. #2
  4. #3

Work items

#TitleRepositoryStateIssuePR / CIReview
w1·0Create Application flow demo CLI and runbooks (dry-run, sandbox demo with cleanup, durable sandbox)orchestratorCOMPLETED#555#560merged · CI passedc1: approve
w2·0Public Web Application template: add Articles surfaces with preview/publish gatingorchestratorCOMPLETED#565#567merged · CI passedc1: approve
w3·0E2E runner: add migration verification (Article count and publish-date preservation)orchestratorCOMPLETED#574#580merged · CI passedc1: request_changes, c2: approve
w3·1 ⛓Wave 3 execution CLI: orchestrate sandbox creation → gating checks → migration → verification → cleanup/retainorchestratorCOMPLETED#575#581merged · CI passedc1: request_changes, c2: approve
w1·1 ⛓Post-create verification CLI: Hub PR presence, Doorway secret in AWS, provider health statusorchestratorCOMPLETED#556#561merged · CI passedc1: approve
w2·1 ⛓E2E runner: add automated preview/publish gating checks for ArticlesorchestratorCOMPLETED#566#568merged · CI passedc1: approve
w1·2 ⛓Business website Articles migration profile (9 items) and migration runbookoutshineCOMPLETED#539#540merged · CI passedc1: approve
w3·2 ⛓Route verification runbook: make preview/production checks explicit for www.staging.xyence.iohubCOMPLETED#83#84merged · no CI in this repoc1: approve
w1·3 ⛓E2E runner to invoke provider conformance smokes and V1 readiness checklist for a target ApplicationorchestratorCOMPLETED#557#562merged · CI passedc1: approve
w1·4 ⛓Composer + Content Workspace authoring verification playbookworkspacesCOMPLETED#232#233merged · CI passedc1: approve
w1·5 ⛓Route and preview verification runbook for lifecycle-managed Application routeshubCOMPLETED#81#82merged · no CI in this repoc1: approve

Release candidate

  • initiative planning is still open

Questions

agent:openai · 8/20/2026, 11:25:24 PM

Which GitHub App should receive the repository administration permission for creation (separate creation-specific App vs. expanding the platform App)? This must be decided and installed by the operator before executing sandbox or real creation runs.

ANSWERED

Repository administration permission on a GitHub App is an operator-controlled, security-sensitive decision. Execution (sandbox or real) is blocked until this is resolved; development cannot decide it.

Answer: A separate, creation-specific GitHub App — already created and installed. "Xyence Application Creator" (app id 4664136) is installed on the Xyence-sandbox organisation (installation 155279819, repository selection: all) and holds exactly organization_administration, contents, pull_requests, workflows and metadata. Verified against the App's own credential. Not the platform App: GitHub App permissions are declared on the App rather than per installation, so granting the platform App the organization-administration that creating a repository needs would give it repository-administration across every org it is installed on, including Xyence — as a side effect of enabling a sandbox demo. The platform App is the identity behind issue creation, PR merging and release publishing everywhere. The controller is wired to it: APPLICATION_CREATE_GITHUB_APP_ID / _INSTALLATION_ID / _PRIVATE_KEY_PATH are set on the box, the key is mounted read-only, and the Create Application flow is enabled with dry-run OFF against owner Xyence-sandbox and Hub repository Xyence-sandbox/hub. Installation on Xyence is deliberately deferred until the sandbox run passes. The operator's decision, verbatim: "Xyence Application Creator is installed on Xyence sandbox and has proper permission. You may proceed to real creation under Xyence after sandbox passes." Note: this repeats the wave 2 continuation decision, which the operator had already answered. The same subject was asked through two mechanisms and answering one did not resolve the other.

agent:openai · 8/20/2026, 11:17:57 PM

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

ANSWERED

What shipped is strong operator tooling, profiles, and verification runbooks (sandbox creation CLI; post‑create verification; E2E runner; migration input/loader and runbook; authoring and routing verification runbooks). However, the brief judges the assembled system end‑to‑end. There is no evidence that the real business website application (Xyence/www-xyence-io) was actually created through the flow, deployed via the lifecycle to serve www.staging.xyence.io, issued a Doorway credential, passed the post‑create and E2E checks, or that the nine Articles were migrated with authors and publish dates preserved and the count asserted. Where capabilities plausibly exist, the repo shows only story‑level tooling or docs, not end‑to‑end execution against the target app; those criteria are partial and need completion evidence. One intent in the brief (“edited through Composer”) is superseded by the Content Workspace Article editor per delivered docs. Unmet criteria: - Real creation of Xyence/www-xyence-io via the flow (not by hand), with scaffold and Hub manifest PR — Docs reference create-application-prod.md (#556), but no artifact or report shows the real repo was created via the flow or that its Hub PR exists/was inspected - Application receives application-owned PostgreSQL database and explicitly exposes an Articles content capability — Scaffold includes content/capability.jsonc in dry-run output (#555), and provider usage implies a DB, but no end‑to‑end evidence that the real app’s DB was provisioned and the capability is active for Xyence/www-xyence-io - Doorway registration issued and credential stored in AWS Secrets Manager under platform prefix — Post-create verification CLI checks the secret (#556) and the durable sandbox is described as holding a real credential, but there’s no evidence for the real app’s credential in Secrets Manager - Application deployed through lifecycle; www.staging.xyence.io serves preview site — Route/preview verification runbook in Xyence/hub #81 and readiness ‘Preview route responds’ check in the E2E runner (#557) exist, but no proof the preview host is live for the created app - Routes are managed through the Application lifecycle (not hand-configured) — Runbook #81 documents verification and forbids hand edits; Hub manifest PR presence is checked by #556; no concrete evidence that the real app’s routing is in place exclusively via lifecycle - Content authoring: Content Workspace discovers/manages Articles for this Application; drafts can be created/edited — Xyence/workspaces #232 provides a step‑by‑step authoring verification playbook; conformance harnesses exist, but no evidence the workspace discovers/manages content for the created app end‑to‑end - Draft renders on preview and is not public; publishing makes it appear on the production surface — E2E conformance includes draftIsolation and productionVisibility checks (#557), but no run/evidence against the created app - V1 readiness checklist and provider conformance smokes pass against the created application — E2E runner wraps both checks and produces evidence bundles (#557), but no recorded PASS against durable sandbox or prod targets for this app - Migrate all nine Articles from www.xyence.io; assert count=9 in new app; preserve author and publish date (not migration date) — Xyence/outshine #539 ships the migration profile (placeholders), pure loader, preview CLI, and runbook, but the one‑time executor run and resulting content in the new app (count=9, dates/authors preserved) are not shown The initiative stays in EXECUTING until each unmet criterion is either delivered by further work or waived deliberately.

Answer: Plan more work. Do not waive. The unmet criteria are the initiative's entire purpose, not incidental gaps: the real creation of Xyence/www-xyence-io through the flow, its application-owned database and Articles capability, Doorway registration into AWS Secrets Manager, deployment with www.staging.xyence.io serving the preview, lifecycle-managed routes, Content Workspace authoring, draft/publish separation, readiness and conformance passing, and the migration of all nine Articles with author and publish date preserved. Waiving would record that the operator accepted the absence of the outcome the brief was written to obtain — a false record, and the same mistake the predecessor initiative (1c9c864c) came close to making after six waves of foundation work that never executed. Every work item completing is not the same as the outcome existing; that distinction is exactly what the brief assessment is for, and here it is reporting correctly.

Timeline

No events yet.

    ← All initiatives