Hiro development journal

Stage 6B promotion enters probation under an eight-hour activation window

2026.08.10 at 17:21:18 America/Los_Angeles Promotion active; checkpoint zero passed; probation incomplete Machine-readable JSON

Executive summary

The user approved the fixed Stage 6B revision and replacement candidate while narrowing the activation window from 72 hours to eight hours.

The prior enablement packet was archived, a new immutable packet was bound to the fixed revision's review interaction with a one-promotion maximum and eight-hour validity, and the packet hash was verified before activation.

The persistent kill switch was archived, the separate Stage 6B scheduler was enabled, and exactly one replacement candidate was admitted.

The candidate passed exact-hash preflight, external staging, 73 policy tests, 442 full-repository tests, and premerge validation before the active branch fast-forwarded to one additive documentation-evidence commit.

Immediate validation then passed 73 policy tests, 442 full tests, 11 candidate canaries, local health, and bounded metrics. The zero-minute probation checkpoint also passed.

Stage 6B is now genuinely in its 24-hour probation. No runtime code, service configuration, restart behavior, or external system was changed by the promoted artifact.

The v1 controller uses the same enablement expiry both for admitting a promotion and for authorizing probation checkpoints. Consequently, the user-requested eight-hour expiry covers the six-hour checkpoint but not the mandatory 24-hour retention checkpoint; this requires an explicit follow-up decision rather than silently extending authority.

Work completed

Eight-hour enablement

Complete

Archived the previous read-only enablement packet and sidecar.
Created a new packet valid for eight hours with a maximum of one promotion and the unchanged active-policy hash.
Verified the new sidecar hash and restored both packet files to read-only state.
Archived the persistent disabled sentinel only after packet verification.

Replacement promotion transaction

Complete

The ledger bound preflight to the exact replacement candidate hash, enablement hash, and policy hash.
The candidate was staged in an external worktree and all premerge tests passed.
The active branch fast-forwarded from the fixed base to the single additive evidence commit.
An immutable prepromotion reference and promoted-file hash were recorded before canaries.

Immediate canary and checkpoint zero

Complete

Immediate policy validation passed all 73 tests.
Immediate full-repository validation passed all 442 tests.
The focused candidate canary passed all 11 tests.
Local health remained HTTP 200, and the bounded error-rate and latency sample remained better than baseline.
The zero-minute probation checkpoint repeated focused canary, health, and metrics checks successfully.

Scheduler correction

Complete

The first attempt to update the existing task description used an unsupported command parameter; this did not affect the controller or packet enforcement.
After the initial transaction completed, the task definition was safely re-registered with the correct description and a one-minute cadence ending at the exact eight-hour expiration.
The corrected task is enabled and ready for due probation checkpoints.

Probation-expiry compatibility

Needs user decision

The policy requires checkpoints at 15 minutes, 60 minutes, six hours, and 24 hours after promotion.
Post-promotion authorization currently rejects an expired enablement packet at every checkpoint.
The eight-hour window therefore cannot, by itself, authorize the 24-hour retention checkpoint.
No silent extension was made.

Decisions and reasoning

Honor the user's eight-hour activation limit exactly rather than retaining the earlier 72-hour interval.
Allow only the already approved replacement candidate; the maximum-promotion count is one.
Begin the 24-hour probation only after active fast-forward and immediate canary success.
Do not reinterpret an eight-hour packet as 24-hour authority without explicit user direction.
Leave Daylab stopped and keep Stage 6C unavailable.

Validation and evidence

Check	Status	Result
Enablement integrity	passed	The eight-hour packet hash matched its sidecar and both files were restored to read-only state.
Premerge validation	passed	The controller completed required policy and full-repository validation before fast-forward.
Immediate canary	passed	73 policy tests, 442 full-repository tests, 11 focused candidate tests, local health, and metrics passed.
Probation checkpoint zero	passed	Focused tests, health, and metrics passed with no error-rate or latency regression.
Scheduler boundary	passed	The task now repeats every minute and ends at the exact eight-hour packet expiration.
Journal tests and production build	passed	npm run test:hiro passed, generated-output validation passed for 95 entries, and npm run build completed successfully.

Current state

The active branch contains one newly promoted additive evidence note and no runtime behavior change.
Stage 6B probation is active; checkpoint zero has passed.
The next required checkpoints are 15 minutes, 60 minutes, six hours, and 24 hours after promotion.
The activation packet and task are limited to eight hours and one promotion.
The eight-hour packet does not reach the mandatory 24-hour retention checkpoint under the current v1 authorization model.
Daylab remains stopped and Stage 6C remains undesigned and unauthorized.

Next steps

Allow the scheduler to execute the 15-minute, 60-minute, and six-hour checkpoints within the current window.
Obtain explicit user direction on whether the eight-hour limit applies only to starting a promotion or also ends probation-monitoring authority.
If monitoring may continue, create a separately bounded probation-only authorization path without reopening candidate admission.
If all checkpoints pass, record the first retained Stage 6B promotion; otherwise execute the policy-defined rollback.