Splitting a monolithic npm CLI release coordinator into selectable verify, dogfood and publish phases

Question: when a single release script already runs readiness checks, a full test gate, packaging of an npm tarball, a candidate backend deployment, native coding-client acceptance, npm publication under a staging dist-tag, a signed release pointer promotion and final latest-tag promotion, what is the safest way to add explicit phase selection (verify only, dogfood only, publish only) without introducing a second state system? Known evidence: the script keeps fingerprinted checkpoints per operation, a validated private release record, and receipt-backed evidence from real client runs; publishing must reuse the exact frozen tarball bytes because npm versions cannot be reused. Open concerns being audited: whether the verify stage can be made free of production and signing access when coverage selection or version allocation may depend on live state; how the release tool's own generated pointer commits interact with source fingerprints used to prove an earlier phase is still valid; how to represent a normal pause awaiting external evidence versus a failure in exit codes; and whether resume flags stay meaningful once later phases always require an existing record.