Roadmap to 1.0

Hikyo’s first stable release targets a bounded, self-hosted configuration and secrets service with controlled human onboarding, workload delivery, and recoverable operations. New product surfaces follow after that boundary is verified.

Already merged

The implementation status links the owning evidence for the core API, CLI and embedded browser, validation, revisions, audit, backup/restore, SAML/SCIM, service accounts and workload federation, Compose, Kubernetes, and deployment adapters. These capabilities remain subject to the final candidate’s acceptance checks.

Several capabilities originally planned after 1.0 have already merged: recovery hardening, multi-node HA, PostgreSQL dynamic credentials, change approvals, and multi-target adapters. They no longer belong behind a future-version clock.

Recent merged repairs include production verification gaps, stale-leader approval fencing, and the docs dependency security fix. Machine MCP’s transport, five bounded read tools and deployment checker are also merged through #637, #639, and the conformance CI repair. That implementation does not establish every advertised client’s live result.

Required before the 1.0 gate closes

The release is not reduced to a signing ceremony or tag push. Supported workflows, compatibility safety and candidate evidence still need closure. The following changes were open pull requests at this snapshot; their links show the current review and merge state.

After reviewed changes merge, #79 and umbrella #41 still require exact-candidate, non-skipped SQLite/PostgreSQL checks, desktop/mobile browser and locked-prototype validation, recovery/operator resource evidence, live provider evidence, API/CLI freeze and bidirectional skew checks, self-hoster and disclosure-channel checks, and the real release-signing ceremony. Published trust material and a stable tag cannot stand in for those results. Signed compatibility metadata and release binding, the applied-release ledger, exact legacy genesis, and mandatory migration gates on both engines remain required implementation before 1.0. PR #645 records governance and disables unsafe apply; it does not complete those foundations.

MCP: deployment proof and human delegation are separate

#651 tracks the exact-image public HTTPS, authenticated named-client and deployed multi-process evidence required for the advertised machine-MCP support matrix. Conformance fixtures, configuration examples and a raw Go request do not prove execution by Codex, Claude Code or OpenAI Responses. Missing credentials or an unsupported wire profile remain visible evidence limits.

#631 is a post-1.0 decision about a concrete unmet human-delegation workflow and whether it needs embedded OAuth. The current machine boundary uses managed service-account bearers and five read-only tools, with configuration plaintext but no secret material or writes. Enterprise self-hosting alone does not require a new authorization server. Evidence collection can proceed now; human identity/consent integration must respect its owning dependencies. See MCP operations.

First after 1.0

Social sign-in and open registration are post-1.0 by the owner’s recorded scope decision. The #615 umbrella sequences #605 data foundations, #606 registration policy, #607 federated sign-up, #608 local email sign-up, #609 OAuth2 identity providers, #612 CLI login handoff, #610 invitation claim, #611 account establishment and unlinking, then #613 acceptance. The locked future design is not a current sign-up feature. Pre-freeze work in #617 does not implement that onboarding system. OAuth2 social login and MCP human delegation remain distinct product decisions.

Other additive lanes remain after the release, without a promised minor version:

The execution tracker coordinates these lanes. Refresh this dated snapshot when scope or merge state changes. Issue labels, milestones and a closed dependency graph do not certify a release.