/deployment-activity

Provision, level or tear down a deployment from INSIDE the mesh — as node types and activities, never as an out-of-band script or a CI workflow. Use when someone asks to stand up a deployment, bring deployments to the same level, change what one runs, or decommission one.

• Instructions: # /deployment-activity Provision, level or tear down a deployment **from inside the mesh** — as node types and activities, not as an out-of-band script or a CI workflow. Use this when someone asks to stand up a deployment, bring deployments to the same level, change what one runs, or decommission one. ## The principle **A deployment is a node; changing one is an activity.** Everything else follows: - The **node** is the intended state — the record, git-backed, reviewable as a diff. - The **activity** is a single run that moves the world toward it: node-backed, with progress, cancellation, a log, and an identity it ran as. - The **overview** shows records; a **drift read** shows records against live. The gap between them is the work list. There is no separate CI system holding a second set of credentials, and no "run this script on your laptop" step that leaves no trace. If an operation cannot be explained as *"this activity, run as this identity, moved the cluster toward this node"*, it does not belong here. ## Do not skip: identity is the design, not a detail An activity runs as *something*. Get this wrong and a prompt injection into an in-portal agent becomes a cloud compromise — this portal runs AI CLIs in-pod, so that is not hypothetical. | Activity | Reads/writes | Identity | |---|---|---| | **Observe** — read live state, compare to records | `get`/`list` on the deployment's own namespace | the portal's ServiceAccount, extended with read verbs | | **Level** — reconcile an existing deployment to its record | `patch`/`apply` on named objects | a distinct ServiceAccount, admin-gated | | **Provision / tear down** — create or destroy a namespace, database, DNS, secrets | cluster-wide create/delete + cloud control plane | a distinct identity used by nothing else, admin-gated, destructive steps behind an explicit confirmation | **How that third row is actually realised** (`HostingOperator`): the portal's own ServiceAccount is NOT widened. A second, separ…
• Auto mount: yes
• Launches sub thread: no