Hiro development journal

Hiro gains a dormant, transaction-safe Stage 6C runtime layer

2026.08.10 at 18:49:58 America/Los_Angeles Stage 6B reconciled to eight hours with an automatic retained-outcome bridge into default-off Stage 6C validation Machine-readable JSON

Executive summary

The user directed work to proceed on the first four Stage 6C preparation steps while later validation and activation prerequisites continue separately.

A schema-bound assistant-behavior fragment, a fail-closed hot-reload path, fragment-specific gate contracts, and an append-only transaction controller are now implemented on Hiro's isolated improvement branch.

Stage 6C is compiled default-off. This session created no activation packet, no active runtime state, and no change to Hiro's live system prompt.

The first Stage 6C scope can replace exactly one small JSON behavior fragment. It cannot introduce executable code, expand filesystem or network authority, restart services, or perform an external action.

An exact policy activation is required once for the Stage 6C capability; routine candidates under an activated policy do not require per-candidate user approval and instead require post-action reports.

The implementation preserves the unified eight-hour model: admission authority lasts no more than eight hours, a candidate that starts during that window receives a full eight-hour probation, and checkpoints occur at zero, 15, 60, 360, and 480 minutes.

Focused Stage 6C validation passed 15 tests and the complete Hiro suite passed 461 tests.

The live Stage 6B checkout remains on its promoted revision, its monitor remains enabled, and the isolated Stage 6C commit did not disturb the active probation.

A follow-up live-state audit confirmed that the only Stage 6 packet in the inbox belongs to the promotion already in probation; there is no new Stage 6B or Stage 6C candidate waiting for admission.

The user then authorized reconciliation for earlier safe completion. A frozen, hash-bound migration record now appends an eight-hour terminal checkpoint to the existing transaction without altering its prior events, promoted revision, or original policy evidence.

A separate one-transaction Windows task is armed for the 480-minute boundary. It reuses the live controller's integrity, candidate-test, health, metrics, rollback, outcome, and frozen-packet machinery and cannot admit a new promotion or activate Stage 6C.

The user then requested the connection from a successful 6B outcome into the start of 6C. A new fail-closed bridge now waits for the exact retained outcome, validates the frozen outcome against the ledger, reruns the complete target suite, fast-forwards only to the exact staged revision, and creates a default-off Stage 6C campaign in its shadow-decisions phase.

The bridge cannot run after a rolled-back 6B result, cannot merge or rebase, cannot start from an unexpected source revision, and cannot create a Stage 6C runtime activation.

A PowerShell hidden-window flag proved insufficient to prevent a brief Windows console flash. All three Stage 6 task actions now use Windows' GUI script host as a no-console outer launcher while invoking the same unchanged PowerShell scripts with their original working directories and exit-code behavior.

A screenshot-driven follow-up confirmed that the currently visible benchmark page is the unchanged live Stage 6B version, not stale browser cache. The redesigned Improvement Control Center remains on the exact staged bridge target so the active probation revision is not modified early.

Work completed

Schema-bound assistant behavior fragment

Complete and default-off

Added a versioned JSON Schema and a tracked baseline fragment whose directive list is intentionally empty.
The fragment accepts only five exact top-level fields, at most eight bounded directives, a small fixed set of behavioral scopes, and no unknown properties.
Validation rejects oversized content, duplicate identifiers, invalid encodings, control characters, authority-bypass instructions, credential requests, code-execution requests, and unapproved external-action instructions.
The initial target remains one assistant-behavior fragment; arbitrary Python, shell, executable, deployment, restart, and external-action changes are excluded.

Safe hot reload and prompt integration

Complete and dormant

Added a thread-safe loader that validates complete bytes before changing its in-memory fragment.
Invalid, stale, repeated, or malformed reload attempts leave the last accepted in-memory fragment unchanged.
The prompt builder now has a Stage 6C hook, but it returns no text unless the required environment opt-in, absent disabled sentinel, exact policy hash, exact active-fragment hash, and controller-produced probation or retained state all validate.
A probation state expires closed if monitoring does not retain it; a retained state can continue without requiring a service restart.

Fragment-specific readiness and candidate gates

Contract complete; campaign evidence pending

Added an accelerated readiness snapshot with minimums of one retained Stage 6B promotion, 30 perfectly classified Stage 6C shadow decisions, zero false allows, ten hot-reload rehearsals, three rollback drills, five interruption boundaries, and a passing full repository suite.
Each candidate must bind passing public, held-out, invariant, behavior-regression, and latency gates to an evidence SHA-256.
A candidate must have a strictly newer fragment revision, remain under the size ceiling, contain no symlink, and match its frozen byte hash.
The readiness document now distinguishes completed dormant implementation from pending campaign evidence and activation.

Atomic Stage 6C transaction controller

Complete and tested in isolation

Added an append-only SQLite event and outcome ledger with a single runtime-fragment coordination lease.
Before replacement, the controller freezes the exact prior bytes and their hash; it then performs a same-directory temporary write, flush, filesystem sync, and atomic replacement.
A reload acknowledgement bound to the candidate hash is required. Failure restores the exact prior bytes and freezes a rolled-back outcome.
Interrupted transactions can resume when the active bytes match either the frozen prechange state or the candidate state; any third state is rejected.
Checkpoint recording supports automatic rollback on failure and retention only at the 480-minute checkpoint. Runtime state does not extend the original probation when an interrupted controller resumes.

Live Stage 6B isolation

Preserved with append-only eight-hour reconciliation armed

All Stage 6C source changes were made in the isolated Hiro improvement worktree rather than the active checkout.
The live repository remained on the exact revision already under Stage 6B probation.
The existing Stage 6B scheduled monitor remained enabled and independent of the Stage 6C test run.
No Stage 6C enablement packet, runtime state, promotion, or prompt fragment was installed in the live checkout.
The reconciliation packet binds the exact promotion ID, request hash, candidate packet hash, original enablement hash, original policy hash, promoted revision, promotion timestamp, runner hash, launcher hash, and user interaction.
The reconciliation event was appended once to the live SQLite ledger; no existing event or outcome row was updated or deleted.
The original runner remains responsible for the 360-minute checkpoint. The reconciliation task begins at 01:16:40 Pacific time and retries once per minute within the five-minute checkpoint-lateness boundary.
Both the original checkpoint task and the reconciliation task are configured to wake the computer from ordinary sleep and to start when available; a powered-off machine can still miss the bounded checkpoint and fail closed.
At minute 480, all prior checkpoints, active revision integrity, clean worktree, candidate tests, health checks, and metrics must pass. Success freezes retained; any failed or missed requirement invokes the existing automatic rollback path.
The evidence monitor, eight-hour reconciliation, and 6B-to-6C bridge now launch through a host-local no-console wrapper. Their exact bound PowerShell launchers were not edited, and their triggers, working directories, wake settings, and enabled states were preserved.

Retained Stage 6B to Stage 6C validation bridge

Implemented, validated, and scheduled

Added a source-controlled bridge that accepts only a frozen retained outcome completing the reconciled 480-minute checkpoint.
The bridge verifies the outcome JSON and sidecar against the append-only Stage 6 ledger and requires the promoted revision to be an ancestor of the exact clean target revision.
Added durable, atomic Stage 6C validation-campaign state. Its first phase is shadow decisions, all counters begin at zero, and runtime-fragment activation remains false.
The transition is idempotent: repeated execution returns the same campaign and records exactly one Stage 6C campaign-start event in the Stage 6 ledger.
The benchmark control center now shows whether the 6C campaign has started, its current phase and counters, and the inactive runtime-fragment state.
A frozen host-local bridge packet binds the promotion, request, source revision, target revision, target worktree, runner, launcher, user interaction, allowed fast-forward-only operation, and prohibition on 6C runtime activation.
The scheduled bridge begins at 01:18 Pacific time, repeats every two minutes for 40 minutes, wakes from sleep, and waits harmlessly until the retained outcome exists.

Decisions and reasoning

Implement Stage 6C as data-only behavior adjustment before considering any broader runtime scope.
Compile the prompt hook default-off and require controller-produced state in addition to environment and sentinel controls.
Separate the eight-hour admission window from the eight-hour post-admission probation so an admitted candidate is not silently switched off before its final checkpoint.
Use one exact Stage 6C policy activation rather than per-candidate user approval; require post-action reports for routine candidates.
Store exact bounded prechange bytes in the append-only transaction evidence so rollback remains deterministic across process interruption.
Do not merge or activate the work while the current live Stage 6B exact-revision probation is in progress.
Reconcile the already-started promotion through a new append-only migration event rather than editing its original 24-hour policy identity or prior evidence.
Keep the reconciliation authority terminal-only: no candidate admission, no active-revision change before the checkpoint, and no Stage 6C activation.
After and only after retained 6B evidence exists, allow one exact fast-forward to the validated bridge target and start 6C validation rather than runtime mutation.
Treat console presentation as a host-scheduling concern: use a no-console outer host without changing the evidence-bound promotion, reconciliation, or bridge launchers.

Validation and evidence

Check	Status	Result
Focused Stage 6C suite	passed	15 tests passed for policy alignment, schema validation, prohibited capability rejection, last-good reload behavior, exact activation binding, probation state, default-off behavior, readiness rejection, atomic application, exact rollback, append-only enforcement, checkpoint retention, and interrupted transaction resumption.
Repository-wide suite	passed	461 tests passed in 145.36 seconds using the isolated worktree's linked pinned runtime.
Python and Git static validation	passed	Python compilation and Git whitespace checks passed for the Stage 6C implementation.
Policy identity	recorded	The staged Stage 6C policy SHA-256 is dc8e544af2ed89d04e56cf5dd1db891f789e5e7ecb783b643849203fe962c166.
Implementation identity	recorded	The dormant Stage 6C implementation is committed as 9e55b025fb7982ab5fd35e723c81d2bfc44dcce8 on the isolated improvement branch.
Live isolation	passed	The live checkout remained at 5c7306d76b41387c0639ba1f676c1c19cd375056 and the Stage 6B scheduled monitor remained enabled.
Reconciliation packet and copied-ledger rehearsal	passed	The frozen migration packet validated against every bound artifact. On a copied ledger, arming was idempotent, produced exactly one reconciliation event, returned not-due before the terminal boundary, and created no outcome or live file change.
Scheduled reconciliation launcher	passed	A manual task launch exited successfully, reported the expected missing 360-minute checkpoint and not-due status, left the promotion non-terminal, and retained its next automatic run at 01:16:40 Pacific time.
Reconciliation identity	recorded	The frozen migration packet SHA-256 is 7800c4068dc1a8ae71acf6c5fa7d36b78f1cd36c000ac8143a37cc4daca5e4ca.
Focused 6B-to-6C bridge suite	passed	24 focused tests passed, including retained-outcome transition, idempotent campaign start, rolled-back outcome rejection, premature runtime-activation rejection, Stage 6C fragment controls, and dashboard compatibility.
Repository-wide suite after bridge implementation	passed	464 tests passed in 151.80 seconds on the exact isolated bridge target.
Scheduled bridge waiting-state rehearsal	passed	A manual launch validated every frozen bridge identity, exited successfully with waiting-for-Stage-6B-outcome, changed no Git revision, and retained the automatic 01:18 Pacific run.
Bridge implementation identity	recorded	The exact post-retention target is 8fe4298766fac1deb9cd67934d82746a6149619f. The frozen bridge packet SHA-256 is 5a82f75fbac50c25b9527fb57596bf5fbce99a8530a973c5b71dcc2a39118de9.
Hidden background-task launch rehearsal	superseded	Adding PowerShell's hidden-window option preserved task operation but did not fully eliminate the user's brief console flash. This presentation-only approach was replaced by the no-console host validation below.
No-console scheduled-task validation	passed	All three jobs were launched through Windows' GUI script host and returned task result zero in their expected not-due or waiting states. A subsequent real one-minute evidence-monitor trigger also completed with result zero, advanced its next run normally, preserved minute 360 as the next checkpoint, and left every original launcher SHA-256 unchanged.
Benchmark deployment-state diagnosis	confirmed	The live Stage 6B revision still contains the Evaluation Observatory navigation shown in the user's screenshot. The exact staged bridge target contains the renamed Improvement Control Center, pipeline-first view, Stage 6 probation and Stage 6C readiness panels, and the realigned tab set.

Current state

Stage 6C implementation steps one through four are complete on the isolated improvement branch.
The Stage 6C fragment is baseline-empty and the runtime hook is compiled default-off.
The exact Stage 6C policy exists and is hashable, but it has not been activated.
The 30-decision shadow campaign, ten reload rehearsals, three rollback drills, and five interruption boundaries have not yet been accepted as readiness evidence.
The full repository suite currently passes, but it must still be associated with the final campaign revision before activation.
The live Stage 6B promotion remains under its independent probation.
The live legacy controller still expects checkpoints at 360 and 1,440 minutes. Its next checkpoint is due at approximately 23:16 Pacific time, while its terminal checkpoint is due approximately 24 hours after promotion.
The original Windows monitor repetition ends at approximately 01:12 Pacific time. A separate reconciliation task now covers the desired eight-hour terminal boundary beginning at 01:16:40 Pacific time.
The live ledger contains the immutable probation-duration reconciliation event and still contains no terminal promotion outcome.
The post-retention bridge task is enabled and waiting. It will do nothing until a retained 480-minute outcome exists.
On success, the bridge target will start Stage 6C validation with phase shadow_decisions and all evidence counters at zero; it will not activate the runtime fragment.
The once-per-minute evidence monitor, eight-hour reconciliation, and retained-outcome bridge now use a no-console GUI host to start their unchanged PowerShell launchers invisibly. Their operational settings and schedules are otherwise unchanged.
The live benchmark page remains the old Evaluation Observatory while Stage 6B is in probation. The redesigned Improvement Control Center is committed in the staged target and will become live only through the retained-outcome bridge.

Next steps

Allow the live Stage 6B promotion to reach its safe handoff boundary and terminal retained or rolled-back outcome.
Allow the armed reconciliation to run the 480-minute terminal checkpoint and freeze retained or rolled-back status.
Allow the retained-outcome bridge to rerun the complete target suite, fast-forward to exact revision 8fe4298766fac1deb9cd67934d82746a6149619f, and start the default-off Stage 6C validation campaign.
Run and freeze the Stage 6C-specific 30-decision shadow campaign, ten reload rehearsals, three rollback drills, and five interruption boundaries from the newly created campaign state.
Rerun the complete repository suite on the exact candidate revision and bind the result into the readiness evidence.
After all readiness deficits reach zero, create the exact one-time Stage 6C activation packet for the frozen policy; routine candidates thereafter use post-action reporting rather than per-candidate approval.