sparkengine-change-control-and-release-readiness

Read the capability entry in docs/site/readiness.json and report all four dimensions: implementation, verification, support, and release. The weakest dimension controls public framing, and blocking work item IDs must be cited alongside the verdict.

Execute the item's commands array verbatim and attach exact-SHA CI evidence from its requiredCiJobs. Comments or screenshots never close items; then regenerate the handoff with render_handoff.py and validate with tools/site-data/validate.py in the same commit.

Annotation-marker counts measure comment habits, not completeness. SparkEngine shows only 6 markers while 49 blocking readiness items remain open, so the readiness contract, not grep counts, owns the release verdict.

Only if the tests execute production source or packaged binaries. Mirror-only, mock-only, or tautological tests cannot promote readiness under promotion rule 3, and production-ready wording is forbidden until the global release state is ready.

Use other skills for build or CMake failures, running packaged binaries, debugging runtime crashes, or EngineContext DLL injection work. This Skill governs public claims, gates, and work items only.

requiredCiJobs must name jobs that already exist in .github/workflows, while plannedCiJobs records jobs the item still has to create. Moving an entry from planned to required is itself a promotion requiring evidence.