Hiro development journal

Capability lanes turn unsupported ideas into governed autonomous work

2026.08.11 at 14:41:10 America/Los_Angeles Implemented, validated, activated, and exercised against the live workflow Machine-readable JSON

Executive summary

Hiro now routes every approved external discovery theme into a defined capability lane instead of rejecting four themes as unsupported.

Behavior-fragment themes continue through the existing Stage 6C controller. Evaluation, memory and retrieval, routing, and observability themes now construct code candidates only in isolated engineering worktrees with exact path scopes and the established public, held-out, regression, invariant, latency, and Stage 5 gates.

Passing engineering candidates stop at a new explicit awaiting-engineering-Stage-6 state. This work did not grant active-branch code-promotion authority; a separate exact policy is still required before such a candidate can change Hiro.

The five prior unsupported-theme outcomes were reopened: three routing ideas are waiting for independent local evidence, and two observability ideas reached engineering specification. The first completed live observability candidate failed its generated tests and was safely rejected without deployment.

The benchmark page now separates actionable ideas from completed history. At live verification it reported four actionable and five terminal user-visible ideas.

Work completed

Governed capability-lane registry

Completed

Added a versioned machine-readable registry covering all seven safe discovery themes.
Provenance and replay, latency and freshness, and authority and rollback remain in the Stage 6C behavior-fragment lane.
Evaluation reliability, memory and retrieval, tool and routing quality, and observability received separate sandboxed engineering lanes.
Each engineering lane has a compiled exact source-file allowlist. Policy edits cannot silently widen these scopes.
External text retains no authority, independent local corroboration remains mandatory, and only one lane run may execute at a time.

Engineering candidate bridge

Completed

A corroborated engineering idea now freezes a complete improvement specification with hypothesis, evidence receipt, bounded components, success and regression metrics, a generated target-test path, latency budget, rollback plan, and immutable lineage identity.
The specification enters the existing isolated candidate builder and evaluator rather than gaining a parallel untested implementation mechanism.
The bridge requires isolated worktree construction, public and held-out evaluation, targeted and stable regressions, invariant and latency gates, and three Stage 5 monitoring repetitions.
A Stage 5 pass records the candidate revision and affected files in an awaiting-engineering-Stage-6 state. It does not merge, fast-forward, deploy, restart a service, or modify a schedule.
Infrastructure failures remain retryable; actual candidate or gate failures close as explicit rejections.

Local corroboration expansion

Completed

Public evaluation failures can corroborate evaluation-reliability ideas.
Routed response errors and timeouts can corroborate tool-and-routing ideas.
Missing bounded diagnostic classification can corroborate observability ideas without exposing private response content.
Validation or execution failures on responses that used memory can corroborate memory-and-retrieval ideas.
The earlier provenance, latency, and authority signal rules remain in place for Stage 6C behavior candidates.

Legacy record migration

Completed

The workflow detects only prior terminal rejections whose exact reason was the absence of a bounded implementation mapping.
Those records receive an append-only capability-lane-reopened event, preserving their original terminal event in history while restoring a governed next action.
Three prior tool-and-routing ideas reopened into the routing lane and are waiting because no independent local routing failure currently corroborates them.
Two prior observability ideas reopened, found local telemetry-gap evidence, and froze bounded engineering specifications.
A backward-compatibility defect found during the first live migration was fixed by preserving the original immutable idea-discovery payload and recording lane identity only in later events.

Benchmark realignment

Completed

The lineage API now returns actionable, terminal-history, and engineering-policy-wait counts.
The benchmark page shows actionable records first and defaults completed terminal records to a collapsed history section.
Workflow cards identify the capability lane and continue to show the full safe lineage from idea through candidate, affected files, gates, and decision.
Legacy candidate records without workflow events are classified from their actual decision state so rejected history is not mislabeled as actionable.
Live verification confirmed the updated page labels and an API count of four actionable and five terminal user-visible ideas.

Exact-revision Stage 6C continuation

Completed

The prior Stage 6C enablement was archived instead of being reused after the implementation changed the repository revision.
A fresh validation campaign was bound to revision 681f8f9ef6331bfdda6a95e107b1c55d0e0efa0a.
The campaign completed 30 correct shadow decisions with zero false allows, five interruption-boundary checks, three rollback drills, ten hot-reload rehearsals, and the complete repository suite.
The unchanged authorized Stage 6C policy was reactivated for an eight-hour window ending at 2026-08-11T22:31:58-07:00.
This Stage 6C authorization continues to govern behavior fragments only; it does not authorize engineering code promotion.

Live isolated candidate exercise

Completed with safe rejection

The first live observability specification entered a separate candidate worktree and produced a bounded source-and-test patch.
Its initial targeted tests failed, and its attempted repair did not produce a syntactically valid test file within the allowed attempts.
The candidate closed as candidate-gates-failed before public evaluation, held-out evaluation, Stage 5 integration, or any active-branch action.
No deployment, service restart, schedule change, or promotion was performed by the candidate sandbox.
The remaining observability specification stays actionable for the scheduler; the three routing ideas continue to wait for real local corroboration rather than manufacturing evidence.

Decisions and reasoning

Route ideas by the capability they would change instead of forcing every theme through the behavior-fragment Stage 6C schema.
Reuse Hiro's existing isolated builder, evaluator, and Stage 5 machinery for engineering lanes so safety gates are not duplicated or bypassed.
Keep active-branch engineering promotion unauthorized until a separately reviewed exact Stage 6 policy names the candidate revision and authority boundary.
Reopen only the five precisely identified unsupported-theme terminal records and preserve all prior events append-only.
Require local corroboration even when an external idea is safe and relevant; external content remains a source of questions, never an instruction source.
Show active work and completed history separately so the benchmark count reflects executable supply rather than mixing it with past outcomes.

Validation and evidence

Check	Status	Result
Focused capability-lane and workflow tests	passed	23 focused tests passed after the initial implementation.
Initial full repository regression	passed	503 tests passed in 166.71 seconds.
Immutable-event compatibility repair	passed	14 focused tests passed, including a new repeated-ingestion idempotency regression.
Final exact-revision Stage 6C campaign	passed	504 repository tests passed in 153.46 seconds; 30 of 30 shadow decisions were correct with zero false allows, plus five interruption checks, three rollback drills, and ten hot-reload rehearsals.
Live service startup	passed	Hiro restarted with the checked-in hidden launcher and listened successfully on its three expected local service ports.
Live Stage 6C authorization	passed	Runtime authorization validated for the exact final revision and its fresh validation campaign.
Live lineage migration and dashboard	passed	Five legacy records reopened into governed lanes; the live API reported four actionable and five terminal ideas, and the served benchmark page contained the new actionable/history labels.
Live engineering candidate fail-closed behavior	passed	The first observability candidate failed targeted construction tests and was rejected with zero promotion or deployment action.

Current state

Hiro is running and its health endpoint responds successfully.
Stage 6C behavior-fragment authority is active on the exact final revision for the current bounded eight-hour window.
Four user-visible ideas are actionable: one observability specification is ready for another isolated sandbox run and three routing ideas await local corroboration.
Five user-visible ideas are terminal history, including the newly rejected observability candidate and the earlier behavior-fragment outcomes.
No engineering candidate currently has authority to change the active branch.

Next steps

Allow the scheduler to run the remaining observability specification through the isolated sandbox.
Observe whether real routing failures corroborate any of the three waiting routing ideas; do not synthesize evidence solely to move them forward.
Design a separate engineering Stage 6 policy that binds an exact passing revision, preserves fast-forward-only and rollback controls, and requires post-action reporting before any code candidate can reach the active branch.
Improve candidate-builder diagnostics so a failed construction result surfaces a concise reason directly in the benchmark card while retaining the full evidence packet.
Monitor actionable and completed-history counts on the realigned benchmark page and verify that successful future candidates show affected files, gates, and policy-wait status end to end.