user-engine/workplans/USER-WP-0040-wave2-resource-right-sizing.md

id	type	title	domain	repo	status	flavor	owner	topic_slug	created	updated	related	state_hub_workstream_id
USER-WP-0040	workplan	Wave-2 resource right-sizing from the 2026-10-21 allocation review	communication	user-engine	finished	implementation	claude	user-engine	2026-10-21	2026-10-21	CUST-WP-0071 RESOURCE-WP-0008	3ab3f8e5-f831-5067-aab6-ab2219b240c2

USER-WP-0040 — Wave-2 resource right-sizing from the 2026-10-21 allocation review

Receiving workplan in user-engine for the wave-2 request changes below. Deploy sources live in rapp-user-engine.

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: USER-WP-0040-T01
status: done
priority: medium
state_hub_task_id: "8422cab4-c969-5160-864e-c1cbb1944db4"

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
user-engine/user-engine	1	50m → 5m	500m	0.4/4.2	64Mi → 64Mi	256Mi	55.7/56.7	0.0	decrease
user-engine/user-engine-pg	1	100m → 50m	1000m	7.5/9.7	256Mi → 96Mi	1024Mi	78.3/102.7	0.0	decrease + memory down

Source and container detail:

• user-engine/user-engine: Deployment user-engine, container portal, rapp-user-engine/manifests/runtime.yaml (50m/64Mi); a parallel copy exists in net-kingdom/sso-mfa/k8s/user-engine/runtime.yaml — confirm which one is deployed.
• user-engine/user-engine-pg: CNPG Cluster user-engine-pg (deployed from rapp-user-engine; locate its spec.resources, today 100m/256Mi).

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.

Single-instance Cluster: the user-engine-pg change restarts PostgreSQL; schedule it with the portal change.

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: rapp-user-engine (SSA field manager rapp-user-engine, make deploy). The net-kingdom/sso-mfa/k8s/user-engine copy is not the deployed source.
• Change: rapp-user-engine 35fb38b (manifests/runtime.yaml): portal CPU request 50m -> 5m; Cluster user-engine-pg requests 100m/256Mi -> 50m/96Mi. Limits unchanged.
• Diff: resource fields only (Deployment portal requests.cpu; Cluster spec.resources.requests.cpu/memory).
• Restart: yes. The single-instance CNPG cluster restarts PostgreSQL.
• Apply: cd ~/rapp-user-engine && make deploy (or render + kubectl apply --server-side --force-conflicts --field-manager=rapp-user-engine from the workstation).
• Note: make test has one existing failure, which is a stale digest pin assertion and is not caused by this change.

Applied — 2026-10-22 (USER-WP-0040-T01)

Applied under the founder's wave-2 authorization (the-custodian docs/decisions/2026-10-21-cust-wp-0071-delivery-interview.md), after a full-render diff against live that showed resources only. The rapp-user-engine render set was applied server-side; user-engine-pg restarted at 22:33Z with 50m/96Mi and is healthy, and the portal is Ready. Evidence: the-custodian docs/evidence/2026-10-22-wave2-apply.md.