# Deployment prompt — replace the Sibyla Legacy apps with GOTT.Apollo > *Naming note (2026-09-02, see `naming-glossary.md`): "Sibyla" written here before 2026-09-02 means the FDR skill build or the module Apollo built from it, which is now **Argus**; the retired applications and database are **Sibyla Legacy**; "Apollo" means this platform, which became **Sibyla** in Phase 3; "Hermes" before 2026-09-02 means the Hermes Agent runtime or GOTT's instance of it, which is now the agent **Apollo** (Phase 4).* > **Superseded by the naming shift (2026-09-02, rulings N2–N5; see `apollo-naming-shift-prompt-260902.md`).** Read this prompt with these substitutions: > - The platform deploys as **`sibyla.gottsolutions.net`**, not `apollo.gottsolutions.net`. That name is the legacy `Sibyla.Web` site's today, so **Phase L runs first** (checklist in the naming document): the legacy sites move to `legacy.gottsolutions.net` / `api.legacy.gottsolutions.net`, the Hermes plugin is repointed to `api.legacy…`, and only then are the `sibyla.*` names free. Rule 1 below ("do not touch `Sibyla.Api`") still holds during Phase L; after it, the live consumer is on `api.legacy.gottsolutions.net`. > - Project and publish paths are `src\Sibyla.Web` and `src\Sibyla.Worker.Documents`; the solution is `Sibyla.slnx`; the worker's service name is `Sibyla.Worker.Documents`. > - The connection-string setting is `ConnectionStrings__SibylaDb` (was `ApolloDb`); the auth cookie is `sibyla.auth`; the path-base setting is `Sibyla__PathBase`. > - Databases, roles, the secrets files, the IdP clients `apollo-web` / `apollo-worker` and the scope `apollo-api` keep their names until Phase D. > - **Reframed 2026-09-02: the deployment is two hosts and one service, not one host and one service.** The channel-intake API (`src\Sibyla.Api`, built the same day; spec `apollo-channel-intake-api-spec.md`) is a second IIS site on **`api.sibyla.gottsolutions.net`**: its own app pool (No Managed Code), its own certificate binding, `maxAllowedContentLength` of at least 52 500 000 bytes (the 50 MiB ingestion limit plus headroom) and a 120 s request timeout on the PUT, environment `ConnectionStrings__SibylaDb` on the **`apollo_api`** role (not `apollo_app`), `SIBYLA_SECRETS_FILE`, `Identity__Authority` = `https://login.gottsolutions.net`, `Identity__Audience` = `apollo-channel-intake`; no Data Protection ring and no client secret on the server. It shares `Ingestion:StagingRoot` with the web host, so the API app-pool identity needs the same write ACL on `D:\ApolloData\staging`. Health: `GET /health` (200) and `GET /health/ready` (database `SELECT 1`), both unauthenticated. Prerequisites in order: `local\setup-db.ps1 -Target Main` as a database superuser (creates `apollo_api` and applies its policies), `local\migrate.ps1` (both databases), then the deployment. After it: `RegisterIdpClients --channel-intake`, `seed-channel-bindings.ps1`, the plugin install; the intake spec's section 10 is the cutover order. The worker is unchanged. Sibyla.Deployment's Slice 2 must plan this site as a second `Iis.Apply`/`Tls.Apply` pair with its own readbacks, rollback and health check (Slice 1 models one site; see the tooling spec's section 12). > - **Added 2026-09-03: a third host, the documentation site.** `docs.sibyla.gottsolutions.net` is a static IIS site over this repository's `docs\` folder (`D:\fileStorage\repos\GOTT.Apollo\docs`), the platform's counterpart of Sibyla Legacy's `docs.legacy.gottsolutions.net`: anonymous, directory browsing on, MIME maps for `.md` (`text/markdown; charset=utf-8`), `.svg` and `.json`, app pool No Managed Code on `ApplicationPoolIdentity`, its own certificate binding (win-acme renewal as in Phase L), no service, database or environment. Health: `GET /` → 200. It is the third `Iis.Apply` / `Tls.Apply` pair in Slice 2; by hand until then, with the Phase L steps. The owner has been told the folder holds the plan and the specs and that the legacy site's shape publishes them anonymously. > - **Run 2026-09-03: Phases 0–4 done, Phase 5 not run.** Record in `apollo-deployment-run-260903.md`: baseline `D:\Backups\SibylaDeployment\20260903-001541`, release `20260903-002407-3fa3159` under `C:\Apps\Sibyla\`, the three sites and the service `Sibyla.Worker.Documents` (account `.\SibylaWorker`) up and verified as far as an agent can (sign-in and screens are the owner's check), the legacy sites renamed `Sibyla.Legacy.*` in IIS and still running. The scripts of Phase 2 are `local\publish-release.ps1`, `deploy-release.ps1`, `rollback-release.ps1`, `provision-production.ps1`. Phase 5 ran the same day after the owner verified the sign-in and the screens: `Sibyla.Legacy.Web` stopped, `GottSibylaWorker` stopped and Disabled, nothing deleted (record, section 6). All five phases are complete. *Written 2026-09-01. Hand the fenced block below to the agent. Everything above and below it is context for you, not for the agent.* ## Why this is staged rather than a straight swap Three facts, verified on the POC server 2026-09-01, decide the shape of this work: 1. **`api.sibyla.gottsolutions.net` is live-consumed right now.** The Hermes plugin `sibyla-channel-intake` posts to `https://api.sibyla.gottsolutions.net`, driven by the cron job `sibyla-email-graph-gateway` every 2 minutes (22,069 completed runs). Removing `Sibyla.Api` stops NP Group's email document intake, and Apollo has no replacement endpoint — repointing it is deferred to the FDR cutover (AI-harness plan §13.4). 2. **Apollo has no deployment tooling.** `local/` contains `build`, `migrate`, `run-web`, `run-worker`, `run-sync`, `seed-tenant1`, `setup-db`, `test` — all development scripts. There is no publish profile, no IIS site, no Windows Service installer. Creating them is part of the job, not a step that already exists. 3. **Apollo is not yet at functional parity.** It is the Phase 1 walking skeleton: Argus screens are read-only over the synced corpus, and D-AI-6 holds it read-only against `gott_apollo` until the FDR cutover. The legacy `Sibyla.Web` is still the operational application. So the prompt below installs Apollo **alongside** the legacy apps, proves it, and only then retires them — stopping short of anything that breaks intake. A single "uninstall then install" instruction would produce an outage on the first step and have nothing to fall back to. ## Current state on the box | What | Where | Binding / state | |---|---|---| | `Sibyla.Web` (IIS) | `C:\SibylaApps\Sibyla` | sibyla.gottsolutions.net — Started | | `Sibyla.Api` (IIS) | `C:\SibylaApps\Sibyla.Api` | api.sibyla.gottsolutions.net — Started, **live consumer** | | `Sibyla.Docs` (IIS) | `D:\fileStorage\repos\GOTT.Sibyla\docs` | docs.sibyla.gottsolutions.net — Started | | `GottSibylaWorker` (service) | — | Running, Automatic | | Apollo target | `sibyla.gottsolutions.net` | DNS resolves (35.180.180.52); **no site yet** | | Runtime | — | ASP.NET Core 10.0.9 present; ANCM/hosting bundle to be verified | --- ## The prompt ```text You are working on the GOTT POC server (Windows Server 2025, IIS + local PostgreSQL 18). GOAL Deploy the current GOTT.Apollo to production as sibyla.gottsolutions.net, then retire the Sibyla Legacy applications — but in that order, additively, and without breaking anything that is still in use. Apollo lives at D:\fileStorage\repos\GOTT.Apollo. HARD CONSTRAINTS — read these before planning anything 1. DO NOT touch the IIS site "Sibyla.Api" (api.sibyla.gottsolutions.net) in this task. It is live: the Hermes cron job "sibyla-email-graph-gateway" posts to https://api.sibyla.gottsolutions.net every 2 minutes to register inbound email documents. Apollo has no replacement endpoint yet. Retiring it is a separate, later task that happens with the FDR cutover. 2. Nothing is deleted in this task. Retiring a legacy app means: stop it, set it to disabled or manual start, and take a restorable backup of its folder. Deletion is a later, separate decision. 3. Do not stop or modify: login.gottsolutions.net (IdentityServer), nextcloud.gottsolutions.net, buzz.gottsolutions.net, dashboard.gottsolutions.net, postiz.gottsolutions.net, GOTT.MCPServer, or anything under C:\Users\Administrator\AppData\Local\hermes. 4. Never write secrets into the repository or into any file under version control. Apollo's secrets live in local\secrets\ (gitignored) and in IIS/service configuration. 5. If any verification step below fails, STOP and report. Do not proceed to a later phase to "fix it later", and do not retire any legacy app while Apollo is unverified. PHASE 0 — Record the rollback baseline (do this first, always) - Capture and save to a dated file: all IIS sites with bindings, physical paths, app pool names and identities; the state and start type of the GottSibylaWorker service; the installed ASP.NET Core runtimes; and the current git commit of GOTT.Apollo. - Confirm the ASP.NET Core Module (hosting bundle) is present for IIS, not just the runtime. If it is missing, report it — installing it restarts IIS and affects every site on the box, so it needs an explicit go-ahead. - Back up the legacy folders C:\SibylaApps\Sibyla and C:\SibylaApps\Sibyla.Api to a dated archive outside C:\SibylaApps. PHASE 1 — Build and verify Apollo locally before deploying anything - Run local\build.ps1 and local\test.ps1. The tenant isolation suite is release-blocking: if it is not green, stop and report. - Confirm the database gott_apollo is migrated (local\migrate.ps1) and that the FDR sync is current (local\run-sync.ps1 is idempotent — a re-run should report no changes). PHASE 2 — Create the deployment tooling that does not exist yet Apollo has no publish or deploy scripts. Create them in the repo, following the style of the existing local\*.ps1 scripts (PowerShell, $ErrorActionPreference = "Stop", paths derived from $PSScriptRoot, secrets read from local\secrets\): - A publish step: dotnet publish for src\Sibyla.Web (framework-dependent, net10.0, Release) and for src\Sibyla.Worker.Documents. - A deploy step that copies the published output to a versioned folder under C:\Apps\Apollo\ (do not deploy from the repo working tree — a git operation must never be able to change what is serving traffic). - Keep the previous published version on disk so a rollback is a folder swap plus an app pool recycle. PHASE 3 — Stand Apollo up ALONGSIDE the legacy apps - Create an IIS app pool (No Managed Code, and note its identity) and the site sibyla.gottsolutions.net bound to the deployed folder, with HTTPS. DNS already resolves. - Configure Apollo's production settings: the ApolloDb connection string using the apollo_app role (NOBYPASSRLS — never the migrator), the OIDC client secret for apollo-web, and a DataProtection key path outside the site folder with restricted ACLs. - Register apollo-web's production redirect URI at the IdP if it is not already present: https://sibyla.gottsolutions.net/signin-oidc and the matching signout callback. Check first — local\tools\RegisterIdpClients already registered both dev and prod URIs, so this may be done. - Install Sibyla.Worker.Documents as a Windows service (it already calls AddWindowsService with the name Sibyla.Worker.Documents). It uses the apollo_worker role and needs the same DataProtection key ring as the web host. - At this point BOTH the legacy apps and Apollo are running. Nothing has been retired. PHASE 4 — Verify Apollo in production before retiring anything Report the result of each of these explicitly. Do not summarise them as "working". - https://sibyla.gottsolutions.net loads and redirects to login.gottsolutions.net for sign-in. - Sign-in completes and the tenant resolves: the topbar shows the licence and company selectors. - The Argus screens render real synced data under RLS (documents, entities, bank, reviews). - The worker service is Running and its log shows it claiming or polling the queue. - Confirm the site is reading the intended database and role: it must be apollo_app, not apollo_migrator. PHASE 5 — Retire the legacy apps, reversibly, one at a time Only after Phase 4 is fully green, and only these two: - Sibyla.Web (sibyla.gottsolutions.net): stop the site and its app pool. Leave the folder and the backup in place. - GottSibylaWorker service: stop it and set its start type to Disabled. After each one, wait and check that nothing else broke — in particular that the Hermes cron job sibyla-email-graph-gateway still reports ok (hermes cron runs sibyla-email-graph-gateway) and that buzz, dashboard and the IdP are still serving. DO NOT retire in this task: Sibyla.Api (constraint 1), Sibyla.Docs (harmless static docs; ask before touching), or the gott_sibyla database. REPORT Produce a short written record covering: the rollback baseline location, what was deployed and to which folder and commit, each Phase 4 check with its actual result, what was stopped in Phase 5 and how to restart it in one command, and anything you found that contradicts this prompt. If you were blocked, say exactly where and why rather than working around it. ``` --- ## What to do about the two things this prompt deliberately leaves alone - **`Sibyla.Api`** — retire it in the same change that repoints Apollo's intake plugin at Sibyla's own DOCINT ingestion. The AI-harness plan (§13.4) recommends doing that at the FDR cutover so intake and system-of-record move together, rather than as two separate migrations. - **Functional parity** — Apollo's Argus screens are read-only until the cutover (D-AI-6). Stopping `Sibyla.Web` removes the operational write surface, so confirm that nobody is still using it for daily work before Phase 5 runs. That is a business check, not a technical one. ## One consequence worth knowing before Apollo runs under IIS The AI Projects / Development Harness (planned in `ai-projects-harness-plan-260831.md`) shells out to the `codex`, `claude` and `hermes` CLIs, which read the credentials of the **process identity** (`~/.codex`, `~/.claude`, `%LOCALAPPDATA%\hermes`). Under IIS that identity is the app pool, which has none of them. The AI area therefore will not work on the IIS deployment without a dedicated run-as identity — which is already recorded as hardening roadmap item 3 in that plan. It does not block this deployment, because the AI feature is not built yet.