state-hub/workplans/STATE-WP-0091-release-headroom.md
tegwick 23f2038c5b
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 2s
Point STATE-WP-0091 residual at RAIL-BS-WP-0014.
Assistant: grok
Assistant-Session: 01a09dc1-b21e-77e1-919e-fcad2f82b267
2026-09-14 10:17:40 +02:00

3.2 KiB

id type title domain repo status owner topic_slug created updated related state_hub_workstream_id
STATE-WP-0091 workplan Check release headroom and retain a capacity allocation handoff infotech state-hub finished codex infotech 2026-09-10 2026-09-14
STATE-WP-0090
RCLUSTER-WP-0014
RESOURCE-WP-0003
HFACT-WP-0001
4c64d6a6-554d-5b16-a533-9be407fa6515

Residual from STATE-WP-0090: revision 61 failed with Insufficient CPU even though runtime usage was modest. Revision 63 succeeded after a measured same-service MCP request adjustment. The single 4,000m node still reserves 3,895m (97.4%), leaving 105m against a 100m API surge. Existing cluster collection and portfolio contracts are finished inputs, not workplans to reopen. No factory capacity admission follows from this release.

Check scheduling headroom before State Hub promotion

id: STATE-WP-0091-T01
status: done
priority: high
state_hub_task_id: "f84c0f1b-3354-5466-a239-ef9ef85daa07"

Add a read-only preflight to the existing promotion path. Reuse Kubernetes and railiance-cluster capacity evidence; check effective pod requests, init/overhead, placement constraints, rollout surge and migration-hook ordering. Report observed freshness, remaining CPU/memory and precise insufficient-capacity reasons before starting Helm. Do not claim a scheduling guarantee from an aggregate sum or lower requests automatically. Prove the observed 65m refusal and 105m narrowly sufficient case, including unrelated concurrent demand. Keep atomic rollback.

Review sustained service demand and hand off shared capacity

id: STATE-WP-0091-T02
status: done
priority: high
state_hub_task_id: "a433e2d3-6fd4-5313-9273-e3769c2cefeb"

State Hub owns its workload demand and release requirement. Check MCP latency, errors, CPU contention and coverage after the 50m-to-10m request change; its 500m limit, memory and replicas remain unchanged. The initial 1,078 five-minute samples are partial coverage, not a full week. Propose a durable release margin and hand any shared allocation or provisioning change to live records with railiance-cluster, railiance-platform and resource-control using their existing authority contracts. Include HFACT T01/T04 factory demand, other zero-request workloads and host usage; current aggregate reservation alone is not capacity admission. No unrelated allocation, procurement or scaling is authorized by this workplan. Close only after the repeatable preflight and explicit receiving work records are verified.

Evidence: docs/evidence/2026-09-10-projection-convergence.json.

T01 done 2026-09-14. scripts/release_headroom_preflight.py plus make railiance-state-hub-headroom. Fixtures prove 65m refuse, 105m narrow pass, and 105m+50m pending refuse. Helm is not started; requests are not lowered; --atomic remains required.

T02 done 2026-09-14. Existing 1,078 samples remain partial coverage. Durable margin: remaining must cover 100m API surge and must refuse when unrelated pending demand consumes the 5m sliver. Not factory admission. Receiving records: RAIL-BS-WP-0014, RESOURCE-WP-0007, RPF-WP-0041. CUST-WP-0071 keeps weekly fleet review. Details: docs/evidence/2026-09-14-release-headroom.md.