docs: mark automatic staging deploy as disabled

architecture/repository-map.md

@@ -87,7 +87,7 @@ Reason:
 ## Current CI/CD automation map
 
 - Service repos on `main` dispatch image builds to `platform-infra` (`build-push.yaml`).
-- `platform-infra` deploy workflow runs after successful build and currently auto-deploys to `stg`.
+- `platform-infra` build workflow is dispatch-only and publishes images to GHCR; the deploy workflow is manual-only because the k3s host no longer exists (it used to auto-deploy to `stg` after a successful build).
 - Staging and production promotion remain controlled and non-automatic in current policy.
 - Dispatch now occurs only after the service repository validation jobs succeed.
 - Docs-only pushes should not dispatch central image builds from the covered service repositories.

operations/cicd-workflow-map.md

@@ -1,6 +1,8 @@
 # CI/CD Workflow Map
 
-Last updated: 2026-05-03.
+Last updated: 2026-11-12.
+
+> **Status (2026-11):** the k3s staging host no longer exists and `platform-infra/.github/workflows/deploy.yaml` is manual-only (`workflow_dispatch`). Nothing deploys automatically today; `Build & Push Docker Images` (dispatch-only) still publishes images to GHCR when a service repository dispatches it. The automatic flow below documents the thesis-era design.
 
 ## Purpose
 
@@ -51,7 +53,7 @@ flowchart LR
 	E --> F[Build image in platform-infra]
 	F --> G[Push immutable SHA tag to GHCR]
 	G --> H[Publish mutable env tags dev and stg]
-	H --> I[platform-infra deploy workflow_run]
+	H -. thesis-era, disabled .-> I[platform-infra deploy workflow_run]
 	I --> J[Render stg manifests with immutable SHA]
 	J --> K[Apply to axiomnode-stg in k3s VPS]
 	K --> L[Rollout checks and smoke tests]
@@ -103,12 +105,14 @@ The deployment workflow prefers immutable short-SHA references for automatic sta
 
 ## Automatic deployment policy
 
-`platform-infra/.github/workflows/deploy.yaml` is triggered in two modes:
+Current state: `platform-infra/.github/workflows/deploy.yaml` only runs on manual dispatch. The `workflow_run` trigger described below was removed when the k3s host was decommissioned and can be restored once a deploy target exists again.
+
+Thesis-era design (for reference), `deploy.yaml` was triggered in two modes:
 
-1. `workflow_run` after successful completion of `Build & Push Docker Images` on `main`
-2. manual dispatch for targeted environment deployment
+1. `workflow_run` after successful completion of `Build & Push Docker Images` on `main` (disabled)
+2. manual dispatch for targeted environment deployment (the only mode today)
 
-Current policy:
+Thesis-era policy:
 
 - automatic target environment is `stg`
 - automatic deploys render the staging overlay with immutable image overrides derived from the triggering build run

operations/deployment-strategy.md

@@ -15,7 +15,7 @@ This document defines how AxiomNode promotes runtime changes across environments
 ## Environment model
 
 - `dev`: developer-owned local runtime, primarily Docker Compose based, optimized for fast iteration and low coordination cost
-- `stg`: shared remote staging on the VPS k3s cluster, used as the automatic deployment target for covered services
+- `stg`: shared remote staging on the VPS k3s cluster, formerly the automatic deployment target for covered services (host decommissioned, deploys are manual-only today)
 - `prod`: controlled production target with manual promotion, stricter operational review, and higher runtime guarantees
 
 ## Deployment principles
@@ -55,15 +55,17 @@ It does not automatically cover:
 
 ## Automatic staging deployment
 
-Automatic deployment to staging is enabled for the covered runtime services.
+> **Status (2026-11):** disabled. The k3s staging host no longer exists and `deploy.yaml` is manual-only (`workflow_dispatch`). The text below describes the thesis-era design.
+
+Automatic deployment to staging was enabled for the covered runtime services.
 
 Conditions:
 
 1. a change is pushed to `main` in a covered service repository
 2. the service validation jobs succeed
 3. the service workflow dispatches `platform-infra` build-push
 4. the centralized image build succeeds
-5. `platform-infra` deploy runs via `workflow_run`
+5. `platform-infra` deploy ran via `workflow_run` (trigger removed)
 
 Staging deployment therefore acts as a continuation of CI, not as a manually curated release lane.