docs: remove stale references to ActorTemplate as a Kubernetes CRD

[Youssuf Elshall (yelshall)]

What

Now that the ActorTemplate CRD has been deleted and its resources moved to the substrate gRPC API and the control-plane store (created/managed with kubectl-ate, persisted in PostgreSQL), several documents still describe ActorTemplate as a Kubernetes CRD, or describe namespace/RBAC relationships that no longer exist. This sweeps the docs for those stale references.

Fixes #368 (docs side).

Stale references found and fixed

docs/architecture.md

• "API Resource Models → System Configuration (Declarative/CRD-based)" claimed these resources "are managed via Kubernetes CRD APIs" and listed ActorTemplate under that heading. WorkerPool remains a CRD; ActorTemplate is now an ate API resource in the control-plane store.
• The personas section said agent developers "might have to be aware that they are using Kubernetes (some concepts are represented as CRDs, such as ActorTemplates)" — the CRD example is now WorkerPool, and ActorTemplates are explicitly noted as managed through the substrate API.
• The governance rationale said Kubernetes objects for "WorkerPools and Templates" get familiar RBAC/auditing/policy — only infrastructure resources remain Kubernetes objects; ActorTemplates go through the substrate API's own authn/authz.
• The UML class diagram placed ActorTemplate in kube-apiserver with a <<CRD>> stereotype, and drew a ActorTemplate "1" --> "1" WorkerPool : workerPoolRef relation that does not exist in the API. ActorTemplate is now a <<record>> in ate-api-server; pool selection is a label-based workerSelector match, and an Actor references its template via the actor_template ref (verified against pkg/proto/ateapipb/ateapi.proto).

docs/glossary.md

• ActorTemplate was the first entry under "## Resources (declarative, Kubernetes CRDs)". The section is now "Resources (declarative)" with each entry labeled (Kubernetes CRD) or (ate API resource), and the ActorTemplate entry notes it is managed via kubectl ate create actor-template and stored in the control-plane database.
• The Atespace entry contrasted atespaces with "the namespace an ActorTemplate lives in" — ActorTemplates now live in atespaces; it is WorkerPools that live in Kubernetes namespaces.
• The records intro said "These are not Kubernetes objects" — dropped, since the declarative ActorTemplate record is also not a Kubernetes object and the distinction is now drawn per-entry.

docs/api-guide.md

• Best Practices "Symmetry" bullet: "Ensure your ActorTemplate and WorkerPool are in the same namespace or have appropriate RBAC permissions to reference each other" — no longer meaningful. Replaced with a "Placement" bullet reflecting the actual model: sandboxClass match plus workerSelector label matching, not namespace/RBAC.
• The ActorTemplate section kept CRD-era spec.-prefixed field paths: the heading "Specification (ActorTemplateSpec)" (no such type exists — the protojson manifest has top-level fields, see demos/counter/counter-template.yaml.tmpl), "Sandbox Right-Sizing (spec.resources)" plus its inbound anchor links, and spec.volumes / spec.resources.limits.* references in the SystemInfo and per-container limits sections. All de-prefixed; anchors updated. workerSelector was also typed *LabelSelector where the proto type is Selector, and "via kubectl-ate create actor" used the tool name as a command (now kubectl ate create actor).

docs/api-style-guide.md

• The Update RPC rules cited actor_template_name as an example immutable field; the Actor message's actual field is the actor_template ref, and it is mutable (+k8s:mutable in pkg/proto/ateapipb/ateapi.proto — actors may be re-pointed to a new template). The immutable example is source_snapshot_tag (+k8s:immutable).
• docs/csi-volumes.md
  • Same stale spec.-prefixed field paths ("spec.volumes", "spec.containers[].volumeMounts[]") in the ActorTemplate volume-configuration steps — which contradicted the top-level volumes: / volumeMounts: fields shown in the YAML examples directly below them.

docs/dev/code-layout.md

• cmd/atecontroller was described as the "Kubernetes controller for WorkerPool/ActorTemplate"; its controllers are now WorkerPool, NetworkPolicy, and egress MITM trust (verified against cmd/atecontroller/internal/controllers/).

README.md

• Multi-Template demo blurb said templates share a pool "across three namespaces"; the demo (already updated) places them in different atespaces.
• Counter Demo blurb mentioned "dynamic CRD routing" (a phrase from the initial commit); routing is done by the Substrate router to suspended/resumed actors, nothing CRD-based remains.

Stale references in code comments (also fixed)

• cmd/ateapi/internal/controlapi/template_reconciler.go:354 — goldenSnapshotWarmupFor's comment said it "Mirrors the CRD controller's function of the same name; keep both in sync." The CRD controller was deleted in the cutover, so the "keep both in sync" instruction referenced nonexistent code; dropped the sentence.
• demos/claude-code-multiplex/ui/server.go:400 — comment labeled "ActorTemplates / WorkerPools (k8s CRDs)"; only WorkerPool is a CRD. Now "ActorTemplate / WorkerPool resources".
• benchmarking/workloads/deploy.sh:47 — comment used the CRD-era spec.resources.limits.memory path; the protojson manifest is top-level. (The script's actual commands already use kubectl ate create/get actor-template — only the comment was stale.)

Known leftover not addressed here (code change, not docs): the atelet metrics code names its OTel template-atespace field templateNamespace (cmd/atelet/metrics.go:77 et al., fed from req.GetActorTemplateAtespace() into ateattr.TemplateAtespaceKey) — a CRD-era name holding an atespace. A mechanical rename (templateNamespace → templateAtespace, ~21 occurrences across 6 files) would fix it; happy to do that as a follow-up PR if wanted.

What was checked and found current (no change needed)

• docs/api-guide.md ActorTemplate example (protojson-shaped, kubectl ate create actor-template), WorkerPool/SandboxConfig CRD examples, and the gRPC API section — all already reflect the cutover.
• docs/observability.md — ate.template.atespace labels and ate.workerpool.namespace (WorkerPool is still namespaced) are correct.
• docs/threat-model.md T-07/T-08 — "attacker who can create ActorTemplates" threats apply equally at the API layer.
• docs/authentication.md, docs/roadmap.md, AGENTS.md, CLAUDE.md — no ActorTemplate-CRD references.

Notes for reviewers

• Diagram relation labels use the proto field names (worker_selector, actor_template); the surrounding prose uses the spec-style names (workerSelector) as the rest of the docs do.
• The governance rationale now notes that the substrate API authenticates callers but does not yet implement authorization, matching docs/authentication.md.
• I did not regenerate docs/assets/threat-model-diagram.svg — it predates the cutover but only depicts threat flows, not the resource model.

This change was prepared with AI assistance; I have reviewed and tested it.

• Docs and comment-only change; no functional code changed, no tests affected

[Zoe Zhao (zoez7)]

I see this PR is still in draft state, is this ready for review?