Cortex VPS Promotion Packet 2026-07-02
Executable promotion packet for moving CT124 Cortex vNext v1.10 project-ready package into a private VPS candidate, with separate migration-candidate and live-cutover approval gates.
Body
title: Cortex VPS Promotion Packet 2026-07-02 project: cortex kind: plan authority: ai-lane-direct-author author_user_id: 2 ai_visible: True human_visible: True created_at: 2026-07-02T00:33:55.061569+00:00 updated_at: 2026-07-02T00:35:12.252999+00:00
Cortex VPS Promotion Packet 2026-07-02
Executable promotion packet for moving CT124 Cortex vNext v1.10 project-ready package into a private VPS candidate, with separate migration-candidate and live-cutover approval gates.
Body
Cortex VPS Promotion Packet 2026-07-02
This is a promotion packet, not a cutover approval. It preserves the lane split accepted in the Cortex VPS Target Correction 2026-07-01 document.
Lane ownership: - Live lane: future VPS-hosted Cortex vNext target, private or loopback first, CPU-first by default, not cut over. - Sandbox lane: CT124 /opt/cortex-sandbox, Cortex vNext v1.10 project-ready. - Legacy/index-only lane: CT103 / Engineering / old Cortex v1.
Canonical package source: - Host: CT124 through pve250, container id 124. - Path: /opt/cortex-sandbox. - Verified state from read-only probe: git describe returned v1.10.0-project-ready; cortex-sandbox-api.service was active; /v1/migration/project-readiness returned Ready, project_ready_for_operator_approval true, migration_authorized false, blocker_count 0. - Stale terminology remains in the project-readiness JSON: live_protection still uses ct103_source_of_truth wording. Treat that as historical/source-protection wording, not as authority to host future Cortex on CT103.
VPS candidate target: - Host: root at the Beacon VPS public edge address. - Target path observed by read-only probe: /opt/cortex-vnext-candidate exists. - Service state observed by read-only probe: no active cortex-vnext unit was listed; postgresql@16-cortex_replica.service existed; Qdrant ports 6333 and 6334 listened on the VPS; Postgres loopback ports 5432 and 5433 listened. - Public route state observed by read-only probe: the engineer-cortex public page returned a static project-ready page; the cortex public route returned HTTP 404; no public API proxy is approved by this packet.
Promotion sequence for the next operator-approved worker: 1. Refresh Explorer source of truth: ready, bootstrap, capability-map, correction document, Cortex v1/v2 docs, CT103 doc, CT124 doc, this promotion packet. 2. Verify CT124 package integrity: read-only git status, tag, commit, and project-readiness endpoint from inside CT124. Do not authorize migration from readiness alone. 3. Build or package from CT124 according to the repo's existing release process. Preserve build logs, package hash, version tag, and exact source ref. 4. Stage to the VPS private candidate path only after operator approves a migration-candidate attempt. Keep service binding loopback/private; do not add public routes. 5. Run private proof on the VPS: process/service inventory, loopback health, ready endpoint, bounded-context memory contract endpoints, and admin/private route checks. 6. Run caller compatibility checks: endpoint names, request/response fields, auth expectations, timeout behavior, bounded context sizes, admin route segregation, and failure responses. 7. Run memory/embed contract checks without reading payloads: collection names or metadata only, dimensions/counts if allowed, no vectors, no raw memory, no secrets, no production rows. 8. Run shadow comparison only if approved and sanitized. Inputs must be bounded and non-sensitive. Outputs must be logged without raw memory spill. 9. Produce a rollback receipt before live cutover: prior package/version, service names, stop/start commands to restore, route table state, data write-disable or archive plan, and known good health checks. 10. Stop at two gates: first operator migration-candidate approval, later separate live cutover approval. Passing private proof is not live cutover.
Rollback path requirements: - Keep CT124 package intact as the project-ready source until the VPS candidate is proven and accepted. - Keep any VPS candidate deployment reversible by service unit disable/revert, package archive restoration, and route no-op state. - Do not change DNS, TLS, firewall, NetBird, Beacon routing, Skipper routing, public proxy, storage layout, or CT103 services without a separate approved runbook. - If any private proof fails, leave the VPS public state unchanged, preserve logs, and file feedback or a handoff blocker.
Approval gates: - Gate A: operator approves migration-candidate staging to private VPS candidate. - Gate B: operator approves live cutover after private proof, caller compatibility, memory contract, and rollback receipt are complete. - No agent may infer Gate A or Gate B from this packet.