Previous phase: release hardening (v0.6.3) — complete (2026-07-04).
Current phase: Next horizon — platform hardening and adoption after the evaluation/beta release.
v0.6.3 shipped with CI-backed quality gates and honest stability labels. Work now prioritizes v1.0-bound capabilities, Experimental → Stable promotion, and organizational gate preparation — not greenfield platform invention.
Organizational gates (field soak, third-party audit): organizational-gates.md · #51
- Bug fixes that restore documented behavior
- Regression, golden-output, smoke, and security tests
- Documentation correctness and stability labeling
- CI hardening and quality gates
- Demo hardening (existing demos only)
- SDK / REST / CLI / gRPC consistency fixes
- Security regression fixes (trust, signatures, sandbox, tamper, privilege)
- Experimental → Stable promotion when tier rules in feature-status.md are met (tests, non-mock default where required)
- Next-horizon items listed in ROADMAP.md § Next horizon priorities
- Field soak and audit prep automation (scripts, docs, CI probes — not bypassing human sign-off)
- New platform services or major subsystems outside the Next horizon list
- New solution blueprints without roadmap approval
- New architecture layers or protocols unrelated to v1.0 exit criteria
- Labeling mock-default paths Stable for production marketing
- Claiming v1.0 production readiness before organizational-gates.md exit checklist is met
Before merging:
- Is the change on the Next horizon list or a justified fix/test/doc?
- Are stability labels honest (no Stable for mock/demo/docs-only)?
- Are release blockers updated in release-blockers.md if user-visible?
- Does public messaging stay evaluation / beta until v1.0 gates close?