Roadmap¶
The high-level architecture remains frozen. Future work is evidence-driven and follows the canonical versioned product roadmap:
- Maintain the certified
v1.3state, vault, CLI, recovery, coverage, mutation, fuzz, and performance foundations. - Complete
v1.4provider contracts, privacy classifications, retries, compatibility evidence, and credential-gated smoke tests before expanding higher-level ecosystem claims. - Mature plugins, MCP, templates, catalogs, governance, observability, skills, workflows, engineering intelligence, and the governed Enterprise Update Management System in dependency order.
- Add account-backed compatibility testing only in secure, opt-in CI environments.
- Preserve local-first operation, additive-only project safety, explicit consent, package-manager ownership, signed artifacts, precise rollback, and backward compatibility.
- Implement an optional remote organization control plane only after local enterprise acceptance passes.
- After
v2.0, establish ForgeRegistry protocol and federation before ForgeHub discovery, publishing, organization, intelligence, and trust-network experiences. - Target
v3.0as the evidence-gated AI Engineering Operating System integration point while preserving the complete local client, human authority, registry portability, and optional hosted services.
No roadmap item introduces a new platform layer without demonstrated need and an approved ADR.
The roadmap is binding by default: complete the approved current version in dependency order. Do not skip, reorder, replace, or silently expand a release. A sequence or scope change requires demonstrated evidence, RFC and impact review, an ADR when architecture changes, migration and rollback planning, updated readiness evidence, and explicit maintainer approval. Emergency security or data-loss patches use the incident track and remain narrowly scoped.
Ideas that are not approved release scope live in the Innovation Opportunity Portfolio and advance only through the Engineering Governance Evidence Funnel. The Platform Constitution governs all roadmap decisions.
The ecosystem direction separates ForgeRegistry, the portable package and resolution foundation, from ForgeHub, the user-facing discovery and publisher experience. The AI Engineering OS evolution connects them only after their independent trust and compatibility gates pass.
The future Enterprise Capability System defines vendor-neutral capabilities, packages, host adapters, rules, agents, teams, knowledge, interfaces, and delivery assets. The Orchestration Strategy requires deterministic bounded workflows before dynamic agent systems. The Host Adapter Strategy requires explicit compatibility evidence and translation loss reports.
All roadmap documentation follows the Documentation Governance Standard, its authority map, and the Research and Standards Radar. Generated health, coverage, drift, debt, and historical evidence must pass before roadmap documentation is merge-ready.
AgentSpace is the agents-and-teams area inside ForgeHub, while Capability Studio is the shared schema-driven builder. The External Ecosystem Import and Conversion Strategy separates source acquisition, semantic conversion, and host projection so external packages are never treated as automatically compatible capabilities.