Autonomous Cron Infra/Deploy RUNBOOK Implementation Plan¶

For agentic workers: REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development to drive this runbook, BUT this is an operations runbook (operator/CRD bump + NetworkPolicy apply + Project CR re-apply + helm), NOT TDD code. There is no test-first cycle. Steps use checkbox (- [ ]) syntax; each step is a concrete operator action with the exact command. Steps marked [USER-GATED] MUST be performed by the human (prod mutation, cluster-side policy apply, helmfile apply, rollout restart, or interactive secret-setting from a tty); the agent prepares and verifies around them but does not run them. No sops ... set or account creation is needed in this runbook - the bot account + PAT + webhook secret were already gated in the prior SCM-projects runbook (2026-06-09-scm-projects-infra.md); this runbook only bumps the operator, adds one cluster-side egress NetworkPolicy, and patches the live Project CR with the new spec.scm.cron + spec.scm.priorityLabel block.

Goal: Roll the autonomous-cron operator (new appVersion, carries ScmCron/BrainstormActivity/priorityLabel/Last*Scan CRD additions, the issue_outcome REST endpoint, the scan loop, and the tatara.io/egress: internet pod-label stamp) into prod from main; add the cluster-side egress NetworkPolicy that allows internet egress only from pods labelled tatara.io/egress=internet and default-denies egress otherwise; and patch the live tatara Project CR with spec.scm.cron (mrScan/issueScan/brainstorm) plus spec.scm.priorityLabel, with brainstorm.enabled: false by default.

Architecture: Order is operator-first (CRD + controller + egress-label code must serve the new spec.scm.cron schema before the Project CR carrying it is applied, else the field is pruned/rejected), NetworkPolicy second (cluster-side, label-gated, independent of the operator roll), Project CR last (declarative re-apply of deploy-samples/tatara-project.yaml, never kubectl patch). The operator chart version: + image.tag pins bump to the new operator appVersion in the infra helmfile; helmfile diff then helmfile apply from main; rollout-restart because the manager reads image-pin envs only at startup (internal/config/config.go). The egress NetworkPolicy is a standalone cluster manifest (NOT chart-templated and NOT helmfile-rendered - it is a sibling of the standalone Project CR manifest, applied with kubectl apply -f), keyed on tatara.io/egress: internet; a companion default-deny-egress policy in the tatara namespace forces every pod without that label onto the deny path while leaving DNS open. The Project CR gains spec.scm.cron.{mrScan,issueScan,brainstorm} + spec.scm.priorityLabel, byte-for-byte from contract lock section 5, edited into the single declarative manifest and kubectl apply -f-ed.

Tech Stack: kubectl (server-side CRD apply + NetworkPolicy + Project CR), helmfile + mise, Harbor OCI charts/images, sops-secret-helper (verify-only here; no set), robfig/cron/v3 5-field schedules (validated server-side by the bumped operator).

Spec: docs/superpowers/specs/2026-06-11-autonomous-cron-design.md (section 15 item 4 is this runbook's scope). Contract lock: docs/superpowers/specs/2026-06-11-autonomous-cron-contract-lock.md (sections 3 and 5 govern the egress label and the spec.scm.cron shape this infra feeds). Prior runbook this mirrors: docs/superpowers/plans/2026-06-09-scm-projects-infra.md. All cluster config lives in ~/Documents/infra/helmfile/helmfiles/tatara (CLAUDE.md rule 14). Build/deploy from main only (rule 10).

Assumptions stated up front: new operator chart/appVersion = 0.4.0 (minor bump: new CRD fields + controller activity, backward-compatible defaults). Wrapper image tag (<WRAP_TAG>) is whatever the wrapper runbook publishes carrying issue_outcome registration; the cluster pins it via the Project CR spec.agent.image, so this runbook folds the wrapper tag bump into the single Project-CR apply. If those exact versions differ at execution time, substitute the real published tags - the steps are otherwise unchanged.

File Structure¶

File	Create/Modify	Responsibility
`~/Documents/infra/helmfile/helmfiles/tatara/helmfile.yaml.gotmpl`	Modify (line 47: `version: 0.3.0` -> `0.4.0`)	Bumps the `tatara-operator` release chart `version:` pin to the autonomous-cron chart version.
`~/Documents/infra/helmfile/helmfiles/tatara/values/tatara-operator/common.yaml`	Modify (line 6: `tag: "0.3.0"` -> `"0.4.0"`)	Bumps the operator `image.tag` pin in lockstep with the chart version.
`~/Documents/tatara/tatara-operator/deploy-samples/tatara-egress-networkpolicy.yaml`	Create	Standalone cluster-side egress NetworkPolicy: allow internet egress only from `tatara.io/egress=internet`; default-deny egress (DNS-open) for every other pod in ns `tatara`. NOT chart-templated, NOT helmfile-rendered; applied via `kubectl apply -f`.
`~/Documents/tatara/tatara-operator/deploy-samples/tatara-project.yaml`	Modify (Project `spec.scm`, after line 12; `spec.agent.image` line 9 if wrapper bumped)	Single declarative source of the `tatara` Project CR; gains `spec.scm.priorityLabel` + `spec.scm.cron.{mrScan,issueScan,brainstorm}`. Re-applied with `kubectl apply -f` (Project is not chart-templated; no `kubectl patch`).
`~/Documents/tatara/tatara-operator/MEMORY.md`	Modify	Records the dated operator 0.4.0 roll, the egress NetworkPolicy name, and that the Project carries `spec.scm.cron` with `brainstorm.enabled: false`.

No sops/secret edits in this runbook: scmToken + scmWebhookSecret already landed in the prior runbook (2026-06-09-scm-projects-infra.md Task 2), and the bot account + PAT (with the scopes the cron read/close paths reuse) were gated there. The cron feature adds no new SCM scope beyond Contents/Pull-requests/Issues/Projects already granted to tatara-bot.

Task 1: Bump operator chart + image pins to the autonomous-cron appVersion¶

Files: - Modify: ~/Documents/infra/helmfile/helmfiles/tatara/helmfile.yaml.gotmpl (line 47) - Modify: ~/Documents/infra/helmfile/helmfiles/tatara/values/tatara-operator/common.yaml (line 6)

The autonomous-cron operator image + chart must already be published to Harbor from tatara-operator main (image/chart publishing is out of this runbook's scope; this task pins the published artifacts). Confirm the published version, then bump both pins in lockstep (the chart's image.tag defaults to appVersion when empty, but the bucket pins it explicitly).

Step 1: Confirm the published operator chart/app version (agent-runnable, read-only). Determine the new operator chart version/appVersion carrying the cron CRD additions, the scan loop, and the issue_outcome endpoint (from the operator repo's Chart.yaml on main). Record it as OP_VER for the edits below.
```
grep -nE '^version:|^appVersion:' ~/Documents/tatara/tatara-operator/charts/tatara-operator/Chart.yaml
```
Expected: the operator chart version/appVersion including the autonomous-cron feature (0.4.0 per the assumption above). If it still reads 0.3.0, the operator build has not been published yet - block on the operator plan before continuing.
Step 2: Bump the operator chart version: pin in the helmfile (agent-runnable). Only the tatara-operator release version changes; tatara-chat stays at 0.1.0.
```
cd ~/Documents/infra/helmfile
sed -i '' 's/^$  version: $0\.3\.0$/\10.4.0/' helmfiles/tatara/helmfile.yaml.gotmpl
grep -n 'version:' helmfiles/tatara/helmfile.yaml.gotmpl
```
Expected: the tatara-operator release version: now reads 0.4.0; tatara-chat still 0.1.0. (Edit by hand if both releases ever share the same literal so only the operator release changes.)

Step 3: Bump the operator image.tag pin in lockstep (agent-runnable).

cd ~/Documents/infra/helmfile
sed -i '' 's/^\(  tag: "\)0\.3\.0"$/\10.4.0"/' helmfiles/tatara/values/tatara-operator/common.yaml
grep -n 'tag:' helmfiles/tatara/values/tatara-operator/common.yaml

Expected: tag: "0.4.0".

Task 2: Server-side apply the bumped CRD (manual, precedes the helm roll)¶

Files: none (applies the CRD shipped in the operator chart's crds/ dir from main).

The operator chart ships CRDs under charts/tatara-operator/crds/ (tatara.dev_projects.yaml, tatara.dev_tasks.yaml, ...). Helm installs CRDs from crds/ only on first install and never upgrades them on helm upgrade (standard helm CRD behavior). The autonomous-cron feature adds fields to BOTH the Project CRD (spec.scm.priorityLabel, spec.scm.cron.*, status.lastMRScan|lastIssueScan|lastBrainstorm) and the Task CRD (spec.kind enum gains triageIssue;brainstorm; status.issueOutcome). Those additions must be applied to the live CRDs manually with server-side apply BEFORE the helm roll, or the new spec.scm.cron field on the Project CR (Task 4) is pruned/rejected and the operator cannot persist status.issueOutcome.

Step 1: Diff the published CRDs against the live cluster CRDs (agent-runnable, read-only). Confirm the new fields are present in the chart CRDs from main and absent live (so the apply is the delta).

# Project CRD: new spec.scm.cron + priorityLabel + status.last*Scan must appear in the chart copy.
grep -nE 'cron|priorityLabel|lastMRScan|lastIssueScan|lastBrainstorm' \
  ~/Documents/tatara/tatara-operator/charts/tatara-operator/crds/tatara.dev_projects.yaml
# Task CRD: enum must include triageIssue + brainstorm; status.issueOutcome must exist.
grep -nE 'triageIssue|brainstorm|issueOutcome' \
  ~/Documents/tatara/tatara-operator/charts/tatara-operator/crds/tatara.dev_tasks.yaml
# Live cluster (expect these to be MISSING until Step 2 applies them):
kubectl get crd projects.tatara.dev -o jsonpath='{.spec.versions[0].schema.openAPIV3Schema.properties.spec.properties.scm.properties.cron}{"\n"}'
kubectl get crd tasks.tatara.dev -o jsonpath='{.spec.versions[0].schema.openAPIV3Schema.properties.spec.properties.kind.enum}{"\n"}'

Expected: chart grep hits all new field names; live projects scm.cron prints empty and live tasks kind.enum prints ["implement","review","selfImprove"] (no triageIssue/brainstorm) - confirming the delta to apply.

Step 2: [USER-GATED] Server-side apply the bumped Project + Task CRDs (prod CRD mutation). Prod-mutating cluster schema change; run as human or with explicit go-ahead. Server-side apply preserves fields managed by other controllers and is the correct verb for CRD field additions:
```
kubectl apply --server-side --force-conflicts \
  -f ~/Documents/tatara/tatara-operator/charts/tatara-operator/crds/tatara.dev_projects.yaml \
  -f ~/Documents/tatara/tatara-operator/charts/tatara-operator/crds/tatara.dev_tasks.yaml
```
Expected: customresourcedefinition.apiextensions.k8s.io/projects.tatara.dev serverside-applied and the same for tasks.tatara.dev. (--force-conflicts resolves field-manager conflicts from the prior helm-install of the CRD; the schema-only change is non-destructive to existing CRs.)

Step 3: Verify the live CRDs now serve the new fields (agent-runnable, read-only).

kubectl get crd projects.tatara.dev -o jsonpath='{.spec.versions[0].schema.openAPIV3Schema.properties.spec.properties.scm.properties.cron.properties}{"\n"}' \
  | tr ',' '\n' | grep -E 'mrScan|issueScan|brainstorm' && echo "project cron schema present"
kubectl get crd projects.tatara.dev -o jsonpath='{.spec.versions[0].schema.openAPIV3Schema.properties.spec.properties.scm.properties.priorityLabel}{"\n"}' \
  && echo "priorityLabel schema present"
kubectl get crd tasks.tatara.dev -o jsonpath='{.spec.versions[0].schema.openAPIV3Schema.properties.spec.properties.kind.enum}{"\n"}'

Expected: mrScan, issueScan, brainstorm listed and project cron schema present; a priorityLabel string schema and priorityLabel schema present; the Task kind.enum now reads ["implement","review","selfImprove","triageIssue","brainstorm"]. If any is missing, Step 2 did not apply - re-run before Task 4.

Task 3: Add the cluster-side egress NetworkPolicy (rule 14, label-gated internet egress)¶

Files: - Create: ~/Documents/tatara/tatara-operator/deploy-samples/tatara-egress-networkpolicy.yaml

Contract lock section 3 freezes the pod label tatara.io/egress: internet (exact key/value), stamped by the operator on brainstorm pods only when internet is in spec.scm.cron.brainstorm.sources. The chart bakes nothing cluster-specific (rule 14), so the allow-rule + the default-deny live in a cluster-side standalone manifest, a sibling of the declarative Project CR manifest (NOT chart-templated, NOT helmfile-rendered; applied with kubectl apply -f). Two policies in ns tatara:

tatara-egress-internet - allows TCP 443 (HTTPS) + UDP/TCP 53 (DNS) egress from pods carrying tatara.io/egress: internet. This is additive: it grants internet reach to the brainstorm pod.
tatara-default-deny-egress - selects every pod in the namespace, declares policyTypes: [Egress] with only a DNS allow rule. In Kubernetes a pod selected by any Egress policy is default-deny for all egress not explicitly allowed; this policy therefore denies all egress except DNS for pods that are NOT also selected by an allow policy. Pods labelled tatara.io/egress: internet are additionally selected by policy 1, so their 443 egress is restored; everything else is DNS-only.

The existing chart policy tatara-operator-managed-pods (selects tatara.dev/managed-by: tatara-operator, already allows broad 443) governs the spawned agent/ingest pods' SCM + in-cluster reach. The brainstorm pod carries BOTH tatara.dev/managed-by: tatara-operator (it is operator-spawned) AND, when internet sources, tatara.io/egress: internet. NetworkPolicies are additive (union of allows), so the brainstorm pod's egress is the union of the managed-pods policy and tatara-egress-internet - which is the intended internet reach. The new default-deny does not narrow the managed-pods policy (both are Egress policies; their allow rules union). This runbook's tatara-default-deny-egress exists to close egress for any pod in the namespace that is NOT covered by an allow policy (defense in depth, matching the spec's "default-deny otherwise").

Step 1: Create the standalone egress NetworkPolicy manifest (agent-runnable). Write ~/Documents/tatara/tatara-operator/deploy-samples/tatara-egress-networkpolicy.yaml with exactly:

# Cluster-side egress policy for the autonomous-cron brainstorm feature.
# NOT chart-templated and NOT helmfile-rendered (rule 14: the chart bakes nothing
# cluster-specific). Applied with `kubectl apply -f`, a sibling of the standalone
# Project CR manifest. Keys on the operator-stamped pod label
# `tatara.io/egress: internet` (contract lock section 3), which the operator adds
# to brainstorm pods only when `internet` is in spec.scm.cron.brainstorm.sources.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: tatara-egress-internet
  namespace: tatara
  labels:
    app.kubernetes.io/part-of: tatara
    app.kubernetes.io/managed-by: kubectl
spec:
  # Only pods the operator stamped with the egress label get internet reach.
  podSelector:
    matchLabels:
      tatara.io/egress: internet
  policyTypes:
    - Egress
  egress:
    # DNS resolution.
    - to:
        - namespaceSelector: {}
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - port: 53
          protocol: UDP
        - port: 53
          protocol: TCP
    # Outbound HTTPS to the internet (WebSearch/WebFetch). Broad 443, matching the
    # managed-pods policy's existing SCM egress rule; CIDR tightening deferred.
    - to:
        - namespaceSelector: {}
      ports:
        - port: 443
          protocol: TCP
---
# Default-deny egress for every pod in ns tatara that is NOT selected by an allow
# policy. Selected pods are default-deny for all egress except the DNS rule below;
# pods carrying `tatara.io/egress: internet` are additionally selected by
# tatara-egress-internet (above) and so regain 443 egress (policies are additive).
# The operator manager + spawned agent/ingest pods keep their reach via the chart's
# tatara-operator-managed-pods policy (also additive).
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: tatara-default-deny-egress
  namespace: tatara
  labels:
    app.kubernetes.io/part-of: tatara
    app.kubernetes.io/managed-by: kubectl
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    # DNS is always allowed so name resolution never breaks; all other egress for
    # an otherwise-unmatched pod is denied by virtue of being selected here.
    - to:
        - namespaceSelector: {}
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - port: 53
          protocol: UDP
        - port: 53
          protocol: TCP

Expected: file created. Validate it parses (dry-run, agent-runnable, read-only - does not mutate the cluster):

kubectl apply --dry-run=client -f ~/Documents/tatara/tatara-operator/deploy-samples/tatara-egress-networkpolicy.yaml

Expected: networkpolicy.networking.k8s.io/tatara-egress-internet created (dry run) and ... /tatara-default-deny-egress created (dry run), no schema error.

Step 2: Confirm the existing managed-pods egress allow still covers the operator + spawned pods (agent-runnable, read-only). Before adding a namespace-wide default-deny, verify the chart policy that keeps the manager and agent/ingest pods reachable is live, so the new default-deny does not strand them.
```
kubectl -n tatara get networkpolicy tatara-operator-managed-pods -o jsonpath='{.spec.podSelector.matchLabels}{"\n"}'
kubectl -n tatara get networkpolicy -o name
```
Expected: the managed-pods policy selects tatara.dev/managed-by: tatara-operator and is present. (If it is absent, the operator chart is below the version that ships it - resolve before applying the default-deny, or operator-spawned pods lose egress.)
Step 3: [USER-GATED] Apply the egress NetworkPolicy to the cluster (prod policy mutation). Cluster-side network mutation; run as human or with explicit go-ahead. This is independent of the helm roll and can be applied before or after Task 1's apply, but MUST be live before the first brainstorm cron fires.
```
kubectl apply -f ~/Documents/tatara/tatara-operator/deploy-samples/tatara-egress-networkpolicy.yaml
```
Expected: networkpolicy.networking.k8s.io/tatara-egress-internet created and ... /tatara-default-deny-egress created.
Step 4: Verify the policies are live and the label selector is correct (agent-runnable, read-only).
```
kubectl -n tatara get networkpolicy tatara-egress-internet \
  -o jsonpath='{.spec.podSelector.matchLabels}{"\n"}'
kubectl -n tatara get networkpolicy tatara-default-deny-egress \
  -o jsonpath='{.spec.podSelector}{" types="}{.spec.policyTypes}{"\n"}'
```
Expected: tatara-egress-internet selects {"tatara.io/egress":"internet"}; tatara-default-deny-egress has an empty podSelector {} and policyTypes ["Egress"]. Existing in-cluster traffic (operator -> agent, agent -> memory/chat) is unaffected because those flows are governed by the additive tatara-operator-managed-pods policy.

Step 5: Commit the manifest to the operator repo (no secrets; agent-runnable).

cd ~/Documents/tatara/tatara-operator
git add deploy-samples/tatara-egress-networkpolicy.yaml
git commit -m "feat: cluster-side egress NetworkPolicy for brainstorm internet pods (tatara.io/egress=internet)"

Task 4: Patch the Project CR with spec.scm.cron + priorityLabel (declarative re-apply, NOT kubectl patch)¶

Files: - Modify: ~/Documents/tatara/tatara-operator/deploy-samples/tatara-project.yaml (Project spec.scm block; spec.agent.image only if the wrapper tag bumped)

The Project CR is NOT templated by the operator chart; deploy-samples/tatara-project.yaml is its single declarative source. Edit the manifest (the source of truth) and kubectl apply -f it, so the live spec never drifts from git. Do NOT kubectl patch project .... The spec.scm.cron + spec.scm.priorityLabel field shapes are byte-for-byte from contract lock section 5: priorityLabel (string), cron.mrScan.{schedule,maxPerCycle}, cron.issueScan.{schedule,maxPerCycle}, cron.brainstorm.{enabled,schedule,maxPerCycle,sources}. sources enum values are exactly docs, memory, internet.

The prior SCM-projects runbook already added a spec.scm block with provider/owner/botLogin/board/mergePolicy/prReactionScope/approvalLabel. This runbook ASSUMES that block is live on deploy-samples/tatara-project.yaml. The current committed manifest (lines 4-12) carries only scmSecretRef/triggerLabel/maxConcurrentTasks/agent/memory and no spec.scm at all - so before adding cron, confirm whether the SCM-projects block landed; if it did not, add the full spec.scm block (from the prior runbook) AND the cron/priorityLabel additions together in one edit.

Step 1: Confirm the operator CRD serves spec.scm.cron + priorityLabel (agent-runnable, read-only). Guard: applying a Project with an unknown spec.scm.cron field is pruned/rejected. Task 2 must have applied the bumped CRD first.
```
kubectl get crd projects.tatara.dev \
  -o jsonpath='{.spec.versions[0].schema.openAPIV3Schema.properties.spec.properties.scm.properties.cron.properties.brainstorm.properties}{"\n"}' \
  | tr ',' '\n' | grep -E 'enabled|schedule|maxPerCycle|sources' && echo "brainstorm cron schema present"
```
Expected: enabled, schedule, maxPerCycle, sources listed and brainstorm cron schema present. If empty, run Task 2 (CRD apply) before continuing.
Step 2: Inspect the live Project spec.scm to determine the base block state (agent-runnable, read-only). Decides whether Step 3 adds only cron+priorityLabel or the full scm block.
```
kubectl -n tatara get project tatara -o jsonpath='{.spec.scm}{"\n"}'
grep -n 'scm:' ~/Documents/tatara/tatara-operator/deploy-samples/tatara-project.yaml || echo "no scm block in manifest yet"
```
Expected: either a JSON object with provider/owner/botLogin/... (SCM-projects block already live - Step 3 appends only cron+priorityLabel), OR empty/no scm block (the SCM-projects block never landed - Step 3 must add the full scm block plus the cron additions).
Step

Autonomous Cron Infra/Deploy RUNBOOK Implementation Plan¶

File Structure¶

Task 1: Bump operator chart + image pins to the autonomous-cron appVersion¶

Task 2: Server-side apply the bumped CRD (manual, precedes the helm roll)¶

Task 3: Add the cluster-side egress NetworkPolicy (rule 14, label-gated internet egress)¶

Task 4: Patch the Project CR with spec.scm.cron + priorityLabel (declarative re-apply, NOT kubectl patch)¶

Task 5: helmfile diff -> apply from main; rollout-restart the operator¶

Task 6: Verify the first cron cycle + record close-out¶

Notes¶

Self-Review (per superpowers:writing-plans)¶