v1.x Version on processkit

Issue #135 Implementation Review

Mon, 01 Jan 0001 00:00:00 +0000

This final review compares GitHub issue #135 with the v1.0.0-alpha.5 implementation and its published release evidence.

Summary

The corrected product boundary and trustworthy local lifecycle are implemented. The Rust executable verifies and transactionally applies an explicit release; Python remains the MCP runtime; release content stays visible; and interruption recovery is exercised with real processes.

Issue #135 is complete as the v1.x implementation umbrella. Three extracted engineering tracks are implemented in alpha.5. The four-platform publication track remains open until locally produced artifacts from every supported host have been collected and verified.

Acceptance Gate

Mon, 01 Jan 0001 00:00:00 +0000

Purpose

The acceptance gate keeps the v1.0 rebuild measurable. The RFC’s 81-criterion gate is authoritative for final cutover; the staged lists below are working summaries for alpha-first execution.

Alpha Release Testing

Mon, 01 Jan 0001 00:00:00 +0000

Release Policy

The current test release is the explicit prerelease v1.0.0-alpha.5. It is merged from v1.x-dev into v1.x-pre-release, validated there, and tagged there.

Prereleases never become the implicit latest version. latest remains the highest stable release, currently from the supported v0 line. Downstream installers must opt in to an exact prerelease.

Alpha Scope

Mon, 01 Jan 0001 00:00:00 +0000

Purpose

The alpha proves that the v1.0 model improves real agentic project work before the project implements the full 89-concept ontology.

The alpha is a vertical slice, not a miniature final release.

Scope

The alpha product slice is frozen to these 14 high-value concepts:

WorkItem
DecisionRecord
Artifact
LogEntry
Binding
Gate
Role
TeamMember
Skill
Capability
Proposition
Risk
Scope
Migration

Four prerequisite parent concepts are required to model that slice honestly: Actor for TeamMember, Container for Scope, and Command plus Event for Migration. The generated alpha contract therefore covers 18 of the ontology’s 89 concepts while preserving the 14-concept product scope.

Alpha.3 Closure Plan

Mon, 01 Jan 0001 00:00:00 +0000

v1.0.0-alpha.3 was the feature-complete pre-cutover target. This historical plan did not authorize a merge to main; v0.x remains the stable line until the owner accepts the final ontology, migration, CLI, and aibox evidence.

The machine-readable gate ledger is docs-site/data/v1_alpha3_gates.yaml. It tracks all 81 original v1 criteria and all 15 installer criteria from issue #118. A criterion may be met, partial, missing, owner-review, or deferred-post-cutover.

Architecture Specification

Mon, 01 Jan 0001 00:00:00 +0000

System Role

processkit v1.0 is a provider-neutral process and memory substrate. It stores canonical project entities in git-backed files and exposes safe read/write behavior through MCP servers.

Agent runtimes are consumers. processkit provides context, process state, governance, and memory; it does not own the agent loop.

Beta Ontology Plan

Mon, 01 Jan 0001 00:00:00 +0000

Target

The beta target is 62 of the ontology’s 89 concepts, or 69.7%. This keeps the accepted goal inside the 60–70% range while leaving room to validate the model through real workflows before completing the long tail.

Coverage is counted by ontology category:

Category	Beta target
Terminology	19
Primitives	22
Discriminators	8
Compositions	13
Total	62

The alpha’s 18 generated contracts are the first dependency-complete slice of this target.

Branch Start Work Plan

Mon, 01 Jan 0001 00:00:00 +0000

This plan turns the v1.0 documentation set into branch-start execution work. Phase 0 and Phase 1 are intentionally concrete; later phases are rougher and should be refined as evidence arrives.

Phase 0 - Branch Foundation

Goal: make the v1.0 branch buildable, testable, and clearly separated from v0.x maintenance.

Backlog:

Landscape Note

Mon, 01 Jan 0001 00:00:00 +0000

Positioning

processkit v1.0 is not trying to replace agent runtimes, memory databases, coding agents, or data catalogs. It should be the process substrate those systems can use.

Its strongest position is:

Adjacent Areas

OKF

OKF validates markdown plus YAML frontmatter as an agent-readable exchange format. processkit should support OKF import/export, generated indexes, and permissive boundary consumption.

Ontology Reference

Mon, 01 Jan 0001 00:00:00 +0000

processkit-v1.0-rfc-draft.md is the leading document for the v1.0 ontology. When older analysis conflicts with this page, the RFC and this page win.

T/P/D/C Classes

The RFC names four implementation classes. If a note says TCDP, read it as the same four classes, with the RFC’s canonical order written as T/P/D/C.

Product Specification

Mon, 01 Jan 0001 00:00:00 +0000

Purpose

processkit v1.0 provides a durable process substrate for agentic software projects. It gives humans and AI agents a shared project memory with typed work, decisions, discussions, artifacts, roles, skills, gates, bindings, and event history.

The product is not an agent runtime. It is the process and memory layer that agent runtimes, coding agents, and human maintainers can use to coordinate work safely.

Test Strategy

Mon, 01 Jan 0001 00:00:00 +0000

The current exploratory strategy is to install processkit into a new aibox project and try workflows manually. That remains useful as a human dogfood check, but it is not enough for v1.0. It is not automated, it makes aibox a hard dependency, and it cannot prove release-gate criteria repeatably.

Tooling Architecture

Mon, 01 Jan 0001 00:00:00 +0000

The v1.0 tooling architecture follows the RFC: schemas are generated from Jinja + YAML sources, writes flow through MCP tools, and indexes are extended rather than replaced.

MCP Server Shape

MCP is the stable runtime contract for agents and harnesses. Files remain human-inspectable, but canonical mutations happen through tools.

v0 Reconciliation

Mon, 01 Jan 0001 00:00:00 +0000

Baseline

The v1 line forked from v0.27.1. Reconciliation therefore compares the current v1 work against the latest supported v0 release, currently v0.28.3, rather than copying the v0 tree wholesale.

The rule is:

carry fixes that remain valid under the v1 ontology
adapt lifecycle and storage behavior to generated v1 contracts
regenerate catalogs, schemas, and manifests from v1 sources
defer unrelated v0 features with an explicit disposition
never overwrite v1 schema sources with flat v0 schemas

Current Matrix

v0 surface	v1 disposition	Alpha status
Refreshable GitHub token-file authentication	Carry unchanged security semantics	Implemented and tested
Migration drafting	Adapt to v1 Migration schema and automatic apply mode	Implemented and tested
Historical migration filename repair	Carry with append-only audit bridge	Implemented and tested
Scope lifecycle	Adapt storage to `Container(kind=scope)`	Implemented and tested
TeamMember role assignment	Adapt through the Actor interface	Implemented and tested
Immutable release-manifest preflight	Carry `--check`; builds must not mutate tags	Implemented
`git-branching` skill	Carry after v1 metadata review	Deferred after alpha
`project-reconciliation` skill	Carry after v1 entity-name review	Deferred after alpha
`repository-portfolio-review` skill	Carry after v1 entity-name review	Deferred after alpha
v0 doctor fixes	Re-evaluate per finding against v1 storage	Ongoing
v0 flat schemas and generated catalogs	Never copy; regenerate from v1 sources	Enforced

Verification

The server smoke suite exercises the v1-native replacements. The package smoke suite then extracts only the release tree and repeats the workflow so repository imports cannot conceal a missing carry-over.