Product roadmaps
Doc type: Explanation · Applies to: POSE 1.4.x
Planning baseline: 2026-07-18 · Delivery status (2026-08-17): all 10 roadmaps done
Canonical execution artifacts: .pose/roadmaps/*.md and .pose/specs/*/spec.md
This portfolio converted the capability assessment
into an original 7 governed roadmaps and 35 implementation specs. A later
delivery-integrity roadmap added 4 roadmap-bound specs, bringing the governed
portfolio to 8 roadmaps and 39 member specs. Two further roadmaps —
adaptive-instance-provisioning and agentic-onboarding, both closing gaps
raised in issue #21 —
brought the portfolio to 10 roadmaps and 48 member specs; the repository
contains 115 completed specs in total. All 10 roadmaps carry status: done
as of this baseline — every roadmap outcome crossed its documented
validation and closeout gates with executed evidence, not a planning
intention. The target windows and wave structure are kept below as the
historical execution record and as the template for the next portfolio, not
as an open plan. See the capability assessment
for the current, post-delivery state of each mechanism.
Four further specs sit outside roadmap membership, opened directly against
delivered roadmap 10 outcomes after a real upgrade-path field audit against
seven independently-owned external repositories:
pose-upgrade-path-audit-fixes, pose-derived-index-self-referential-leak,
pose-update-instance-directory-completeness and
pose-discovery-gitignore-and-root-alias-fix, shipped across releases
v1.4.1-v1.4.3 — among the specs outside the 48 governed-portfolio
memberships that make up the remainder of the 115 total.
Historical portfolio, current product
The wave dates below are retained as execution history. POSE 1.0.0 added
automatic usage analytics, the revised five-metric DORA contract and an
exercised immutable release lifecycle. The v1.1.0 and v1.2.0 releases add
component-aware review plans, convergent sealed review bundles with
separate attestations, and automated evidence attestation (pose review auto-attest). Current capability truth lives in the assessment,
not in these historical target windows.
Prioritization model
Order work using four filters, in this order:
- Critical absence: address security, incorrect public contracts and release trust before convenience features.
- Dependency leverage: prefer work that unlocks multiple later specs.
- User value: reduce adoption friction and strengthen POSE's closed-loop governance differentiators.
- Execution risk: prove contracts and fixtures before optimizing or scaling.
The integer priority in each spec is a global preference: lower means earlier.
depends_on remains the hard eligibility rule. Teams may parallelize eligible
specs but must not bypass dependencies to satisfy a target date.
Portfolio sequence
| Order | Roadmap | Primary gap | Target window | Release-level outcome |
|---|---|---|---|---|
| 1 | Product integrity | Contract drift and empty dogfood evidence | 2026-07-20 → 2026-08-28 | Public CLI, MCP, install and version claims agree |
| 2 | Supply-chain trust | Unsigned, unattested releases | 2026-08-03 → 2026-09-18 | Verifiable identity, SBOM, provenance and hardened CI |
| 3 | Governance traceability | Weak requirement-to-evidence links | 2026-08-24 → 2026-11-06 | Auditable intent-to-closure chain |
| 4 | Validation platform | Narrow output and runtime controls | 2026-08-24 → 2026-11-20 | Structured, bounded, polyglot validation |
| 5 | Agent interoperability | MCP drift and manual extension lifecycle | 2026-09-21 → 2026-12-18 | Conformant project-safe protocol and ecosystem |
| 6 | Adoption and DX | Distribution and onboarding friction | 2026-09-21 → 2027-01-29 | Trusted install, guided remediation and adoption kits |
| 7 | Insights and scale | No outcome integrations or portfolio layer | 2026-11-02 → 2027-03-31 | OTel/DORA signals and Harne8 composition |
| 8 | Delivery integrity | Completion claims that lacked immutable review, provenance and reachability witnesses | Delivered | Reviewed closure, artifact identity, composed surfaces and evidence-backed release states |
| 9 | Adaptive instance provisioning | Brownfield pose init shipped hardcoded domain rules and empty module metadata regardless of the target's real stack |
Delivered (v1.3.0) | Rule extensions installed adaptively per detected stack; module metadata auto-discovered from real modules |
| 10 | Agentic onboarding | Brownfield onboarding ignored the target's own README/CLAUDE.md, extensions were local-directory-only and English-only, and two scanners duplicated stack detection | Delivered (v1.4.0) | README/CLAUDE.md excerpted into AGENTS.md; extensions resolve by ID against a published release and carry pt-BR variants; one consolidated stack detector recognizes Cloudflare Workers, Python and .NET |
Coverage of the assessed mechanisms
| Assessed mechanism | Owning roadmap | Principal specs |
|---|---|---|
| Install, upgrade and local runtime | Adoption and DX | pose-public-install-contract, pose-package-manager-distribution, pose-upgrade-compatibility-lab |
| Spec lifecycle and closeout | Governance traceability | pose-requirement-evidence-traceability, pose-spec-amendment-history |
| Task routing, workflows, rules and skills | Agent interoperability | pose-agent-skills-conformance, pose-extension-catalog-lifecycle |
| Dependencies, readiness and roadmaps | Insights and scale | pose-cross-repo-portfolio |
| Validation and structural integrity | Validation platform | all five validation-platform specs |
| Evidence, history and insights | Governance traceability / Delivery integrity | pose-requirement-evidence-traceability, pose-review-bundle-convergence, pose-recurrence-effectiveness |
| Follow-ups and recurrence | Governance traceability | pose-followup-ownership-sla, pose-recurrence-effectiveness |
| Operational knowledge | Governance traceability | pose-knowledge-consumption-traceability |
| MCP and agent interoperability | Product integrity / Agent interoperability | pose-mcp-catalog-conformance, pose-mcp-project-scope-contract, pose-mcp-protocol-completeness |
| Policy, identity and audit | Agent interoperability / Insights and scale | pose-safe-validate-orchestration, pose-harne8-control-plane-integration |
| CI, release and supply-chain trust | Supply-chain trust | all five supply-chain specs |
| Import and adoption interoperability | Adoption and DX | pose-brownfield-reference-kits, pose-extension-catalog-lifecycle |
| Metrics and observability | Insights and scale | pose-otel-observability, pose-dora-adoption-metrics |
| Documentation, localization and diagnostics | Adoption and DX | pose-doctor-guided-remediation, pose-localization-docs-contract |
| Extensibility and ecosystem | Agent interoperability | pose-agent-skills-conformance, pose-extension-catalog-lifecycle |
| Multi-repository and enterprise operation | Insights and scale | pose-cross-repo-portfolio, pose-harne8-control-plane-integration |
Wave 0 — restore product truth
Ship product-integrity work before announcing broader release or ecosystem maturity. The highest-risk gaps are inconsistent version sources, MCP catalog drift, placeholder install paths and lack of standalone dogfooding.
Promotion gate: pose check --strict, MCP golden catalog tests, clean-host
install verification and a generated compatibility report pass for the same
release candidate.
Wave 1 — establish trust and hard evidence
Run supply-chain work alongside the foundations of traceability and structured validation. This makes the binary verifiable and turns results into reusable contracts for CI, MCP and later analytics.
Promotion gate: consumers verify signatures and provenance; every result has a stable schema; security workflows run with minimum permissions.
Wave 2 — multiply governance value
Add requirement evidence, amendment history, owned follow-ups, recurrence effectiveness, changed-scope validation and bounded execution. These features reinforce POSE's core promise rather than merely matching an SDD authoring tool.
Promotion gate: at least two reference repositories demonstrate complete intent → validation → evidence → follow-up → recurrence/knowledge traversal.
Wave 3 — expand interoperability and adoption
Complete project-scoped MCP behavior, Agent Skills conformance, signed extensions, package channels and brownfield kits.
Promotion gate: independent clients and clean environments pass published compatibility suites without privileged manual setup.
Wave 4 — measure outcomes and scale through Harne8
Add OpenTelemetry signals, DORA-compatible integrations, semantic assist with human confirmation, cross-repository projections and control-plane composition.
Promotion gate: multi-repository pilots prove tenant isolation, policy, retention and offline degradation while showing team-level delivery outcomes.
Benchmark references
- Use the MCP 2025-06-18 specification for protocol contracts.
- Use the Agent Skills specification for portable skills.
- Use SLSA 1.2, CycloneDX, Sigstore and OpenSSF Scorecard for release trust.
- Use OpenTelemetry and the DORA metrics guide for outcomes.
- Use Backstage's catalog model as a composition reference, not a replacement for repository governance.
Portfolio governance
- Reassess priority after each minor release using verified evidence.
- Update target dates when assumptions change; never edit dates to imply actuals.
- Create an ADR before changing a structural or public contract.
- Keep one active roadmap membership per spec.
- Close every implemented spec with validation and follow-up disposition.
- Mark obsolete work
supersededorabandoned; do not delete history silently.