mail-address-semantics/workplans/MAS-WP-0015-wave2-resource-right-sizing.md

id	type	title	domain	repo	status	flavor	owner	topic_slug	created	updated	related	state_hub_workstream_id
MAS-WP-0015	workplan	Wave-2 resource right-sizing from the 2026-10-21 allocation review	communication	mail-address-semantics	ready	implementation	claude	coulomb-social	2026-10-21	2026-10-21	CUST-WP-0071 RESOURCE-WP-0008	6406ee14-d860-583f-b49a-1d05a9714c30

MAS-WP-0015 — Wave-2 resource right-sizing from the 2026-10-21 allocation review

Receiving workplan in mail-address-semantics 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: MAS-WP-0015-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: "3b894a50-2cfc-5685-8774-1dd108001977"

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
mas/mas-mx	1	20m → 5m	0m (1 container(s) without CPU limit)	0.6/3.6	64Mi → 64Mi	256Mi	43.3/47.9	None	decrease

Source and container detail:

• mas/mas-mx: Deployment mas-mx, container mx, deploy/railiance/manifests.yaml (requests: {cpu: 20m, memory: 64Mi}, memory limit 256Mi). The container has no CPU limit; leave that as is unless the owner wants one.

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.