Implementation and release roadmap
Current implemented capabilities, remaining boundaries, and release acceptance.
Hikyo’s current codebase includes the core configuration and secrets service, controlled human onboarding, workload delivery and recovery operations. Features that earlier roadmaps placed after 1.0 have since been implemented. This page separates that implementation from release and deployment acceptance.
Implementation snapshot, 16 October 2026
These docs track the repository implementation. Local tests and implemented surfaces do not certify a release, a deployed installation or a real identity provider. The implementation status records owning obligations; release acceptance needs exact-candidate evidence. This roadmap sets no release date.
Implemented capabilities
| Area | Current boundary | Guide |
|---|---|---|
| Values and revisions | Explicit set/absent state, private drafts, validated publication, history, protected environments and change approvals | Values and secrets, Value workflows |
| Human identity | Local accounts, TOTP, passkeys, recovery codes, OIDC/SAML and OAuth2 providers, verified local email registration and policy-controlled federated sign-up | Identity and access, Account security, SAML |
| Provisioning and access | SCIM bindings and group mappings, scoped grants, human access rules and temporary access workflows | SCIM, Identity and access |
| Workload delivery | Service accounts, federation, Compose, Kubernetes and multiple deployment-adapter targets | Machine identities, Deployment adapters |
| Dynamic secrets | PostgreSQL credentials with explicit mint, renew, revoke and settle; browser provider and lease management | Dynamic secrets |
| Certificates | SSH user certificates and private X.509 service certificates under bounded profiles | SSH certificates, Private PKI |
| Cryptography | Software-custody transit encryption, signing and MACs; CLI/API operations | Transit |
| Repository scanning | Local files, staged/unstaged changes, Git history/ranges, JSON/SARIF and reviewed suppressions | Repository scanning |
| Operations | SQLite/PostgreSQL, multi-node HA, backup/restore, signed upgrade gates, runtime configuration and enrolled singleton Kubernetes bootstrap rollouts | High availability, Backup and restore, Configuration rollouts |
Registration remains closed unless an administrator creates an applicable policy. Local email sign-up also needs configured mail delivery; provider sign-up needs an enabled provider and its verified identity claims. A sign-up implementation is not permission for uncontrolled registration. See Identity and access.
Remaining implementation boundaries
- Transit browser forms remain tracked by #820. Use the CLI or API today.
- External transit custody has a tested provider seam but no production HSM, KMIP or cloud-KMS provider. Software custody is the shipped implementation.
- Dynamic credential providers are a closed set containing PostgreSQL; they do not terminate already connected database sessions at lease expiry.
- Private PKI provides no ACME or OCSP service and no public trust.
- Bootstrap configuration rollouts support an enrolled singleton Kubernetes deployment. Multi-member HA bootstrap rollout, host/GitOps executors and cross-database migration are separate boundaries.
The narrower guides document additional limits. The browser parity manifest
(api/parity.yaml) tracks outstanding browser surfaces; it is not a promise
that every API operation already has a form.
Execution and scope closeout
The execution tracker sequences correctness repairs, browser completion, amendment closeout and final candidate evidence. Release-plan and historical-acceptance reconciliation belongs to #79. Backup retention/erasure (#930), dynamic lease ceilings and TTL overflow (#934/#935), and PostgreSQL schema rendering (#941) need their own correction and acceptance evidence before freezing the affected contracts.
Social sign-in and CLI browser/device login are implemented. Their accepted post-1.0 scope disposition remains separate from implementation; #589 owns its narrow text reconciliation. Kubernetes condition reporting is implemented and #791 records real-cluster/browser acceptance at its tested source. Neither lane should be presented as an unbuilt prerequisite solely because an older roadmap placed it after 1.0.
Generic file destinations retain their accepted v1.1 boundary, with five browser administration operations tracked by #819. Four developer-credential project and policy administration operations remain under #807; own credential management stays CLI-only. Transit browser completion remains under #820. Implementation before a release does not automatically change an accepted release boundary.
Release and deployment evidence
A final candidate must pass its required non-skipped SQLite/PostgreSQL, compatibility, recovery, operator and browser evidence, together with the real release-signing and trust-material checks. Earlier successful local runs do not establish a different candidate’s acceptance. A tag or published artifact alone does not establish deployment or runtime health.
Machine MCP defaults to five read-only tools, configuration plaintext and no secret material. Explicit write opt-in adds staging and validation tools; publication stays outside MCP. Named-client public-HTTPS and deployed multi-process proof remain distinct from conformance fixtures. Human MCP identity and consent are a separate product decision. See MCP operations.
Use the implementation status for the current criterion-to-evidence inventory and the execution tracker for owning work. Issue labels and closed dependencies do not certify a release.