target-revenue/workplans/TREV-WP-0016-wave2-resource-right-sizing.md

id	type	title	domain	repo	status	flavor	owner	topic_slug	created	updated	related	state_hub_workstream_id
TREV-WP-0016	workplan	Wave-2 resource right-sizing from the 2026-10-21 allocation review	infotech	target-revenue	ready	implementation	claude	infotech	2026-10-21	2026-10-21	CUST-WP-0071 RESOURCE-WP-0008	8cf5b88a-10e4-5d13-9f80-7e5d42b5b7a3

TREV-WP-0016 — Wave-2 resource right-sizing from the 2026-10-21 allocation review

Receiving workplan in target-revenue for the wave-2 request changes below.

Origin: the 2026-10-21 node allocation review (RESOURCE-WP-0008-T03, feeding CUST-WP-0071-T03). Per the founder's 2026-10-21 delivery interview (the-custodian/docs/decisions/2026-10-21-cust-wp-0071-delivery-interview.md) the small adjustments form wave 2: one receiving task per owner repo, applied later in a batch. Applying wave 2 needs a separate founder approval, so every cluster-write task here is a human-gated wait. This file changes no manifest.

Apply the reviewed request changes

id: TREV-WP-0016-T01
status: wait
priority: medium
needs_human: true
blocking_reason: "Wave-2 cluster write; founder approval for wave 2 not yet given (2026-10-21 interview)"
state_hub_task_id: "385c3c88-d5b1-55e3-88b7-ada3547985f6"

Values are pod-aggregate figures from the budget file (7-day window ending 2026-10-21T06:08Z). Limits stay unchanged unless stated.

Workload (ns/name)	Pods	CPU request	CPU limit	CPU p95/peak 7d (m)	Memory request	Memory limit	Mem p95/peak (Mi)	Throttle	Action
target-revenue/target-revenue	1	50m → 5m	1000m	2.5/2.6	256Mi → 64Mi	512Mi	52.0/70.9	0	decrease + memory down
target-revenue/target-revenue-pg	1	0m → 50m	0m (1 container(s) without CPU limit)	7.6/9.2	0Mi → 80Mi	0Mi	56.2/63.4	None	increase + memory up

Source and container detail:

• target-revenue/target-revenue: Deployment target-revenue, container target-revenue, k8s/railiance/deployment.yaml (50m/256Mi, limits 1000m/512Mi).
• target-revenue/target-revenue-pg: CNPG Cluster in k8s/railiance/cnpg-cluster.yaml — no spec.resources today; add requests 50m/80Mi (limits stay unset unless the owner decides otherwise). Single-instance Cluster: the change restarts PostgreSQL; announce a short window.

Evidence: resource-control docs/evidence/2026-10-21-node-allocation-review/2026-10-21-node-budget.md (+ .json, commit 3d9b1bd). Rule: CPU = max(floor, p95x1.5, peakx0.5) rounded up to 5m; memory request = 7d p95 working set x1.15 (only when the change is at least 64Mi).

Steps:

1. Map the pod-aggregate proposal onto the named container(s) in the source file; where a workload has several containers or pods, split by the per-pod figures in 2026-10-21-workload-usage.json and keep the sum at the proposed value.
2. Prepare the source change as a reviewed commit (no push, no sync) and record the before values here.
3. Apply only inside the batched wave-2 rollout, after founder approval, through the owner's normal deploy path (ArgoCD sync or documented helm/kubectl apply).

Verification: kubectl -n <ns> get pod -o jsonpath='{..resources}' shows the new requests; pods Ready with no new restarts or OOMKilled over 24h; for CPU decreases the throttle ratio and request latency stay at or below the 7d baseline; node request total drops by the expected delta.

Rollback: revert the source commit and re-sync/re-apply; the before values in the table above are the rollback target. Keep before/after kubectl get -o yaml captures as the receipt.

Prepared 2026-10-22 (wave-2 worker W1b)

Status stays wait / needs_human. Local commit only: not pushed, not applied. Diff = full owner render vs live (kubectl diff, object names and changed key paths only, Secret objects skipped).

• Live source: ArgoCD Application target-revenue, path k8s/railiance, targetRevision pinned to a3a8a27 in railiance-platform, manual sync.
• Change: target-revenue 322dab4: app requests 50m/256Mi -> 5m/64Mi; Cluster target-revenue-pg gains requests 50m/80Mi with no limits.
• Diff: resource fields only on the Deployment and Cluster. A sync also runs the Sync-hook Jobs target-revenue-migrate and target-revenue-bootstrap-binky again, which is the normal behaviour of this path. Tests pass.
• Restart: yes. The single-instance CNPG cluster restarts PostgreSQL.
• Apply: push, bump the targetRevision pin in railiance-platform/argocd/railiance01/applications/target-revenue.application.yaml (another worker's repo), then argocd app sync target-revenue.