Hiro development journal

The governor still exists, but it governs only promotion

2026.08.22 at 21:22:27 America/Los_Angeles Architecture clarification complete; no Hiro source change in this session Machine-readable JSON

Executive summary

Hiro's continuous governor was not removed or disabled. It remains installed as hiro/improvement/continuous_governor.py with its protected policy in docs/hiro_continuous_governor.v1.json.

The governor was intentionally designed as a narrow, revision-independent promotion authority. Its module-level contract states that it does not discover ideas or write candidates. It receives control only after a candidate has passed construction, targeted validation, evaluation, and all required canary checkpoints.

The current queue is failing before that boundary. No post-repair candidate has reached candidate_tests_passed, so no candidate can enter canary and no promotion request is delivered to the governor. The governor is therefore idle by design, not malfunctioning.

The architectural and naming mistake was treating a final approval governor as though it were also a process supervisor. Hiro has a strong downstream promotion gate, but it lacks an upstream controller that persists on a candidate, diagnoses repeated construction failures, repairs the builder, and resumes the originating task.

Work completed

Verify the governor implementation

Completed

ContinuousGovernor still validates risk class, completed risk-based canary checkpoints, exact baseline revision, clean repository state, single-parent candidate ancestry, frozen changed-file declarations, permitted worker paths, deletion prohibition, and symlink prohibition.
Before promotion it reruns the entire repository test suite in the frozen candidate worktree, creates a pre-promotion Git reference, and permits only a fast-forward to the candidate revision.
It retains additive rollback support and its policy remains protected from autonomous worker edits.
The policy continues to authorize a single active build and canary, low- and moderate-risk autonomous actions, automatic rollback, local restart, and post-action reporting.

Trace when the governor is called

Completed

The continuous engine constructs a PromotionRequest only inside _advance_canary after every required checkpoint has passed.
Low-risk candidates require checkpoints at 0, 5, and 15 minutes; moderate-risk candidates require 0, 5, 15, and 60 minutes.
Only then does governor.promote validate the frozen revision, run the full suite, and fast-forward or reject.
The last live governor rejection occurred at event 3283 and the last governor-mediated promotion at event 3285. No later candidate has advanced far enough to invoke it.

Identify the missing control function

Completed

Candidate selection, failure interpretation, reflective retry, cross-candidate failure clustering, and builder repair are outside the governor's current contract.
The queue provides ranking and bounded state transitions, while the candidate builder provides one patch attempt. Neither component owns an end-to-end improvement episode across systemic failures.
During the two successful promotions, direct supervision supplied that missing ownership. The governor then correctly performed its narrow approval function once the supervised trajectory reached canary completion.
Calling both concepts governance obscured the gap: approval authority exists, but upstream supervisory control does not.

Decisions and reasoning

Preserve the current ContinuousGovernor as the independent final promotion and rollback authority; expanding it into a code-writing component would weaken its separation of duties.
Introduce any future persistent supervisor as a distinct upstream component with no authority to bypass the governor.
Report governor reachability as a funnel metric. A healthy governor that receives zero eligible candidates is not evidence of a healthy improvement system.
Use precise terminology going forward: supervisor owns iterative problem-solving; evaluator measures the candidate; canary checks behavior over time; governor authorizes promotion.

Validation and evidence

Check	Status	Result
Governor source and policy presence	passed	The governor module and protected version-one policy are present on the active qualified revision.
Governor call-path inspection	passed	The live engine invokes governor.promote only after complete canary evidence; no construction-stage route calls the governor.
Live event reachability	diagnostic finding	No event after the last promotion shows a candidate completing isolated validation and canary, so the governor has received no subsequent promotion request.
Repository tests	not run	This session was a read-only source, policy, and event-log inspection and made no Hiro source change.

Current state

The governor is operational but unreachable from the current failing funnel because candidate construction is not producing eligible revisions.
It continues to protect the repository from unauthorized paths, incomplete canaries, failing full suites, stale baselines, and non-fast-forward promotions.
It does not select tasks, guide Qwen, analyze construction failures, modify the builder, or keep one improvement thread active.
The missing supervisory layer must sit before evaluation and canary while the existing governor remains after them.

Next steps

Add a separate persistent ImprovementSupervisor before candidate evaluation, with explicit episode state, accumulated failure evidence, progress thresholds, and bounded reflection rounds.
Have the supervisor escalate repeated cross-candidate construction patterns into a builder-repair candidate, qualify that repair independently, and then resume the original improvement episode.
Keep ContinuousGovernor unchanged as the final independent authority over canary-complete promotion and rollback.
Expose four separate benchmark stages: supervisor progress, construction pass, evaluation result, and governor decision.