ID-127 amendment — prod-only → staging+prod, two-server split (S408, ratified)

ID-127 amendment — staging+prod platform topology + two-server split

Ratified by Liam in S408 (24/06/2026). Supersedes the OQ-127-HOST resolution in TECH.md (same-host / separate-project / single-app) on BOTH axes: a dedicated Platform VPS (not the client box) AND two Platform environments (staging + prod).

1. Scope delta

ID-127 as ratified stood up ONE Platform cocoindex environment (prod-only, DB zjqbrdctesqvouboziae) as a separate Coolify project on the shared client IONOS host. It now mirrors the client topology: a Platform staging environment AND a Platform prod environment, each isolated (ca-suffixed per environment — own app, router, LMDB/corpus volume), running on a dedicated Platform VPS physically separate from the client pipeline (two-server split). The Platform-staging DB is the existing persistent Supabase branch rbwqewalexrzgxtvcqrh — previously fenced off as “CI/dev only”, now a first-class ID-127 surface that must inherit both squash-fidelity fixes shipped in S408 (the 6 application_types rows + the api-schema anon-REVOKE migration 20260624120000_id115_api_schema_anon_revoke.sql).

2. Decisions locked (S408)

#	Decision
Topology	Two-server split. Server A = Client pipeline (kh-onprem-pipeline-*, the Phew stack); Server B = Platform pipeline (ca-pipeline-platform-*). Greenfield rebuild — cancel the oversized 8-16-480 box (30-day IONOS notice), stand up two right-sized VPS. Config is known-good from the current version; data is rebuildable (LMDB is a memo cache; Supabase is canonical).
Coolify	One control-plane managing both servers, hosted on the Platform box; the Client box is added as a managed server. Distinguish client vs platform — and platform staging vs prod — by server + app UUID + deploy input, NOT by separate credentials. Reuse the Coolify creds already in the Production/Staging GH environments. No new GH environment (OQ-2). A dedicated control-plane box is a future HA option, not now.
OQ-1	Platform-staging deploy is workflow_dispatch-only by input (deploy_platform_staging), matching BI-9’s intermittent posture — NOT branch-triggered.
OQ-3	Platform-staging pipeline-run webhook = https://canonical-platform-git-staging-tw-group.vercel.app/api/internal/pipeline-runs/record (the Platform-staging Vercel app). [Corrected S415: the value originally recorded here — canonical-git-staging-tw-group (missing -platform) — returned Vercel DEPLOYMENT_NOT_FOUND on the live walk; the deployed Platform-staging app is canonical-platform-git-staging-tw-group. The Coolify staging app env + the GH Staging PIPELINE_RUN_WEBHOOK_URL were both repointed.]
OQ-4	Hybrid subtask shape: widen 127.5/6/7 briefs with a per-environment matrix (keep count down); explicit siblings for the live-walk standup (127.11 prod + new 127.13 staging). 4 net-new subtasks (127.12–15).
OQ-5	”Two-server split” = client box + one Platform box hosting both Platform environments (not a 3rd box for staging).

3. Corrected architecture facts (S408 investigation — supersede any spec text that conflicts)

• No separate kh-cocoindex-pipeline repo. The pipeline source lives in canonical (scripts/cocoindex_pipeline/); ghcr.io/ai-solution-hub/kh-cocoindex-pipeline:vX.Y.Z is the GHA-built image (the per-client update artefact), not a separate codebase.
• The “two mock file servers” are local folders, not repos/servers: ~/Documents/development/local-fs-client/corpus (real Phew content — the ID-45 set) and ~/Documents/development/local-fs-platform/corpus (empty — the synthetic platform corpus does not exist yet). They are the dev simulation of a client’s content source; the real content connector is out of scope (WS-6). The platform corpus (127.4) is still to be built.
• deploy/onprem/sync/ does not exist — the rsync corpus-sync (corpus-sync-platform.sh) is spec-only. The only implemented ingress today is the bearer-gated POST /stage.
• Current live setup is a Cloud-Run→on-prem migration artefact (ID-66): prod + staging are two apps for the same client (Phew) co-tenanted on one box; the prod deploy job hardcodes the client app UUID; no resource limits; kh→ca rename mid-flight. ID-127 is spec-only / not built; only the client pipeline is live. This amendment is the chance to rebuild it correctly.

4. Per-subtask impact (existing 127.1–127.11)

Widen, do not duplicate (OQ-4 hybrid):

• 127.1 / 127.2 / 127.3 (FK-ordered seed: application_types → workspaces → feed) — run against both Platform DBs. The staging branch’s 6 application_types are already seeded (S408); workspaces + feed extend to staging. Target-parameterised, not a code fork.
• 127.4 (synthetic corpus + manifest) — one corpus; the sync fans out to both volumes.
• 127.5 / 127.6 / 127.7 (compose / deploy job / backup+monitor) — per-environment matrix in details: docker-compose.platform.yaml + docker-compose.platform-staging.yaml; deploy-cocoindex-platform + deploy-cocoindex-platform-staging jobs (two inputs; extend ALL existing prod+staging guards with && deploy_platform* != 'true'); two backup labels (platform / platform-staging) + two monitor configs.
• 127.8 (compose-parity guard) — watch both docker-compose.platform*.yaml.
• 127.9 (promote + topology runbook) — document the dedicated-server placement, the two-environment ca-suffix tiers, and the staging→prod→client promote rung.
• 127.10 (Python behaviour test) — unchanged (environment-agnostic).
• 127.11 (operator standup + live E2E) — the Platform prod standup on Server B; its staging twin is the new 127.13.

5. Net-new subtasks (added to the ledger this session — 127.12–15)

• 127.12 — Two-server provision + one Coolify control-plane (supersedes OQ-127-HOST).
• 127.13 — Platform-staging Coolify app + live E2E on the dedicated Platform VPS.
• 127.14 — PullMD decommission (bl-359) → capture on-box metrics → fix the VPS tier.
• 127.15 — Runbook + spec reconciliation (the doc-drift sweep below + OQ-127-HOST supersession).

6. Runbook + spec reconciliation (127.15 scope)

S408 surfaced documentation drift that must be corrected so future operators don’t repeat the DB-config confusion:

• github-environments.md — §2/§3.1 still show Production/Staging pointing at the client (rovry/turay/phew); they were repointed to the platform (zjqbr/rbwqew, CLIENT_ID=default) — verified live S408. §8 describes a superseded per-client-REPO-fork model; the ratified ID-95 model is a single public repo + per-client Vercel/Supabase projects (config in the client’s own Vercel env + tenant_config), no per-client GH environment. Flag the app-DB-vs-Coolify credential conflation in Production/Staging.
• onprem-b1-deploy.md (ID-66) — the Phew client standup; kh- naming, pre-split, temporary aisolutionhub domain. Reconcile to the two-server / ca-naming model.
• per-client-release-pins.md — add the per-client staging → prod promotion lane (today upgrade-a-client repoints straight to client prod with a snapshot; Liam’s intended model proves on client staging first).
• client-app-deploy.md + staging-refresh.md (the latter’s §4.3 parity checks were added in S408) — confirm cross-references are consistent.
• ID-127 PRODUCT.md / TECH.md — record the OQ-127-HOST supersession (two-server split).

7. Sequencing + ID-45

1. 127.14 — decommission PullMD on the Client pipeline (bl-359) → measure on-box → fix tier.
2. 127.12 — provision the two VPS (placeholder tier OK; final tier set by step 1’s metrics).
3. DB-side seeds (127.1/2/3) + behaviour test (127.10) + composes (127.5) run in parallel, independent of VPS sizing.
4. 127.11 (platform-prod standup) + 127.13 (platform-staging standup) once Server B exists.
5. ID-45 (Phew re-ingest + handover) runs on Server A (the client box) AFTER the split is clean — it finalises the client’s pinned COCOINDEX_IMAGE_TAG and flips the domain to kh.phew.org.uk. Keep ID-45 and the platform standup on their respective servers; do not conflate the client re-ingest with the platform pipeline build.