v1.x Version

The v1 line is an active prerelease, not only a design proposal. v1.0.0-alpha.5 supplies a native Rust lifecycle CLI, a signed release contract, generated schemas, and the Python MCP runtime as visible project content.

The RFC and planning pages in this section remain useful design history. Statements written as future requirements are not evidence that a feature is implemented. Use the implementation review for the current truth.

Current Status

• Issue #135 Implementation Review
• Alpha.5 Release Facts
• Install and Use the v1 Alpha

The fixed architecture is:

• Rust owns release trust and project-content lifecycle.
• Python remains the authoritative MCP implementation.
• skills, schemas, processes, state machines, and entities remain files.
• context/ is dogfood consumer state; src/context/ is the release producer payload.
• the supported v0 line remains the default while v1 is exact-pin alpha.

Design and Evidence Documents

• Product Specification
• Architecture Specification
• Ontology Reference
• Tooling Architecture
• Test Strategy
• Alpha Scope
• Alpha Release Testing
• v0 Reconciliation
• Beta Ontology Plan
• Branch Start Work Plan
• Landscape Note
• Acceptance Gate
• Issue #135 Implementation Review

Supporting Analysis

• Base Context
• Concept Mapping Briefing Analysis
• processkit v1.0 RFC Analysis
• OKF Compatibility Analysis
• Start Assessment

Branch Contract

The v1 development line is isolated from v0 maintenance:

• schema source and generated schema machinery
• v1.0 ontology and migration adapters
• MCP gateway, helper, and index changes required by the RFC
• automated fixture suites and first-ART validation evidence
• docs and acceptance-gate updates for the v1 line

v1.x-dev merges to v1.x-pre-release for each prerelease. At general availability, create v1.x-release from the selected prerelease state, validate and tag there, then merge it into main. v0 follows the same development-to-release-to-main pattern. Security fixes and dependency bumps may flow between lines when needed; feature work does not automatically backport.

Historical-page convention

Every page below this section is reviewed against alpha.5, but several pages describe a target gate or the reasoning that preceded implementation. Treat the labels as follows:

• Implemented means executable code and release evidence exist.
• Partial means a safe subset exists and the remaining behavior is named.
• Planned means the page is a design contract, not a supported command.
• Historical means the page records an earlier alpha planning stage.