Forge Platform Product Roadmap

Inputs used: docs/platform-charter.md, docs/product-boundaries.md, docs/intersection-map.md, docs/roadmap.md (milestone labels), docs/milestone-plan.md, docs/sprint-structure.md, existing schemas under schemas/, sprints/M*.

---

1. Product vision

Forge Platform is the governed delivery control plane for agentic software delivery: humans see intent move to evidence through a shared ForgeRun spine, with Blueprints shaping policy and discipline, LCDL governing reasoning, Fleet executing bounded work, Lenses as system of record for runs/approvals/evidence, and agents (Hermes, Factory, OpenClaw) as optional workcells or channels—never the center of truth.

---

2. Product thesis

We are not building generic “agent orchestration.” We are building an evidence-producing, human-governed path from intent to decision: Blueprints define what must be judged, Versonas structure discipline reviews, LCDL verifies and traces reasoning, Fleet runs approved templates, workcells return reviewable results, and Lenses holds approvals and visibility.

---

3. Primary users

---

4. Strategic objectives

1. S1 — Credible spine: Normative contracts and samples so every product can attach without inventing parallel run models.
2. S2 — Visible control plane: Lenses renders the spine end-to-end (static first, live later).
3. S3 — Governed reasoning in the loop: LCDL trace and verification are first-class evidence, not chat.
4. S4 — Approved execution: Fleet jobs are template-bound, correlated to ForgeRun/approval, reviewable in Lenses.
5. S5 — Optional automation: Hermes/Factory/OpenClaw augment; they do not own governance or final approval.
6. S6 — Dogfood quality: Platform improves platform with assays, docs-health, and release evidence.

---

5. Releases overview

---

6. Release roadmap

Release 0 — Foundation and Roadmap Readiness

Phase P0.1 — Charter & boundaries · P0.2 — Readiness & planning

Outcomes

• Platform charter, boundaries, and intersection map are treated as normative for roadmap rows.
• Roadmap rows and milestones pass Definition of Ready or are explicitly flagged.
• Contract gap register links each gap to owner product and evidence (no silent schema drift).
• Sprint 1 (M1) charge can be drafted without Hermes/Factory/OpenClaw as hard dependencies.

Milestones

Epics

Evidence required

• Updated docs/product-roadmap.md, docs/roadmap-rows.md, Versona §5 output, roadmap gate playbook, Ember Log.
• Gap register section in playbook or linked artifact under forge-logs/ or sprints/.

Non-goals

• No production Lenses/UI implementation in R0.
• No new agent runtime requirements for M1.

---

Release 1 — Forge Run Spine MVP

Phase P1.1 — Contract hardening · P1.2 — Static validation chain

Outcomes

• A static chain can represent: intent linkage, ApprovalRequest, AgentRun / WorkcellRequest / WorkcellResult, LCDLTraceSummary placeholder, FleetJobSummary placeholder, EvidencePacket, decision state — without requiring live services.
• Lenses can later consume the model without forking a parallel schema.

Milestones

Epics

Candidate stories (R1 only)

Candidate Sparks (R1 immediate execution only)

Evidence required

• Passing scripts/check_foundation.py (or successor check), schema/sample parity notes, M1 charter evidence.

Non-goals

• Hermes, Factory, OpenClaw not required for R1 closure.
• Live Fleet or LCDL execution not required.

---

Release 2 — Lenses Control Plane MVP

Phase P2.1 — IA & views · P2.2 — Boundary-validated UX copy

Outcomes

• Lenses renders static ForgeRun + EvidencePacket (fixtures from R1.M6).
• Approval, agent/workcell activity, LCDL trace placeholder, Fleet job placeholder, and decision state are visible in one coherent narrative.
• UI copy passes product boundary review (Lenses ≠ reasoning runtime).

Milestones

Epics

Candidate stories (R2 only)

Evidence required

• Screenshots or recorded demo from Lenses using forge-platform fixtures; platform assay answers “Lenses still control plane?”

Non-goals

• Full live LCDL/Fleet integration (deferred to R3/R4).

---

Self-Host Alpha — Local platform improvement loop (SELFHOST-ALPHA)

Placement: after M2-lite (Lenses static/control slice) and before Release 3 — Governed Reasoning MVP. Hermes, Factory, OpenClaw, and full Fleet execution are not prerequisites.

Outcomes

• A maintainer can open a ForgeRun backed by files under .forge/runs/, see approval + evidence, and (where enabled) transition decision state from Lenses with local JSON writes only.
• scripts/selfhost_runner.py executes allowlisted actions after an ApprovalRequest in approved state; results merge into EvidencePacket via scripts/selfhost_import_evidence.py.
• Static sample chain under sprints/selfhost-alpha/samples/ validates in CI/manual checks (scripts/validate_selfhost_chain.py).

Stories

Sparks

Product principle

Lenses + ForgeRun + EvidencePacket before adaptive agents: Hermes accelerates later; it does not gate the first self-improvement loop.

Evidence required

• sprints/selfhost-alpha/evidence/selfhost-gap-assay.md
• Passing scripts/check_foundation.py and manual runner/importer smoke on a seeded .forge/runs/ directory

Non-goals

• Raw shell from JSON payloads, chat-only approval, cross-host evidence merge, autonomous code write from the runner.

---

Release 3 — Governed Reasoning MVP

Phase P3.1 — Trace emission · P3.2 — Run spine mapping · P3.3 — Lenses truthy rendering

Outcomes

• LCDL emits LCDLTraceSummary tied to ForgeRun.
• Key flows (decompose, plan DecisionPack-style structure, contradiction scan, evidence-class answer) produce reviewable artifacts in EvidencePacket path.
• Lenses shows real trace payloads (not only placeholders).

Milestones

Epics (intersection-first)

Evidence required

• Trace JSON + rerun script; EvidencePacket containing trace; assay “LCDL still governed reasoning, not orchestrator?”

Non-goals

• Full recipe coverage of all Blueprints discipline surfaces.

---

Release 4 — Controlled Execution MVP

Phase P4.1 — Template & correlation · P4.2 — Visibility & classification

Outcomes

• Fleet runs one approved template path (e.g. docs-health) with ForgeRun / approval correlation IDs.
• Lenses shows job state, logs summary, exit code, artifact links via FleetJobSummary.
• LCDL classifies Fleet output into pass / warning / fail / needs_decision for evidence closure.

Milestones

Epics

Evidence required

• Runnable job demo + captured FleetJobSummary + human approval audit trail.

Non-goals

• Arbitrary Docker argv for agents by default (template-first guardrail stands).

---

Release 5 — Agent Workcell MVP

Phase P5.1 — Hermes surfaces · P5.2 — Factory lane · P5.3 — Verification

Outcomes

• Hermes operates via MCP with Lenses as system of record; readonly perception + governed actions only.
• Factory runs as WorkcellRequest → WorkcellResult through Fleet template; output independently reviewable.
• LCDL can verify Factory output where stakes require it.

Milestones

Epics (families)

Evidence requests (R5 — milestone level only)

• Security review of MCP tools (Security Versona) before widening tool surface.
• UX review for agent activity semantics in Lenses.

Non-goals

• Hermes as autonomous approver or canonical policy author.

---

Release 6 — Channel Ingress MVP

Phase R6.1 — ChatIntent · R6.2 — Safe relay

Outcomes

• OpenClaw creates ChatIntent; Lenses creates/updates ForgeRun.
• Status and evidence summaries relay to channel; approval policy remains Lenses.

Milestones

Epics

Non-goals

• Chat-native implicit approval for destructive execution.

---

Release 7 — Dogfood, Assay, and Hardening

Phase R7.1 — Loops · R7.2 — Release readiness

Outcomes

• Cross-product smoke, docs-health dogfood, roadmap gate, release readiness produce EvidencePackets.
• Drift and boundary violations are visible and tracked.

Milestones

---

7. Product-intersection epic map

---

8. Roadmap row Definition of Ready

Each row (milestone, epic, or story) must state:

1. Outcome — observable user/operator/business result.
2. Evidence — why now; known vs assumed.
3. Horizon — Release / Phase / NOW–NEXT–LATER / target milestone ID.
4. OKR / strategy fit — link to S1–S6.
5. Dependencies — product, technical, external.
6. Non-goals — explicit exclusions.
7. Next gate — what unlocks the next lifecycle step (e.g. Architecture review, BA flow, PM gate).
8. Owner product — DRI product for the outcome.
9. Consumer product — primary consumer of the artifact/API.
10. Contract touched — schema, API, prompt, skill, template, ADR.
11. Human approval boundary — what requires human decision.
12. Evidence expected — artifacts proving done.

If incomplete: mark Hold for evidence, Needs discovery, Needs Versona routing, or Too broad; split before WBS.

---

9. Sequencing rationale

1. R0 prevents role collapse and silent contract debt before spend on Lenses/LCDL/Fleet.
2. R1 establishes the lingua franca; all later releases attach, not redefine.
3. R2 validates human understanding before automating reasoning or jobs.
4. R3 adds LCDL only when the spine can carry trace evidence.
5. R4 adds Fleet only after approval model is expressible in artifacts.
6. R5 constrains agents to template-first execution and evidence return.
7. R6 keeps channels downstream of Lenses authority.
8. R7 institutionalizes quality and narrative honesty.

Rejected patterns: OpenClaw before Lenses spine; Hermes before readonly Lenses + template Fleet; Factory verification before LCDL classifier patterns exist; generic agent orchestration as “platform center.”

---

10. Risks and assumptions

Assumption: M1 scope excludes mandatory Hermes/Factory/OpenClaw per charter MVP.

---

11. Evidence requests

1. Architecture Versona: validate correlation-ID scheme across ForgeRun, ApprovalRequest, FleetJobSummary for R1–R4.
2. Security Versona: threat model for MCP tool surfaces (R5) and OpenClaw relay (R6).
3. Testing Versona: cross-product smoke criteria and schema validation strategy (R7.M1, R7.M4).
4. UX Versona: Lenses IA for R2 panels — single narrative vs tab hell.
5. BA Versona: detailed flows for approval edge cases when M1 stories split for implementation.

---

12. Suggested next Versonas

---

13. Immediate next gates

1. Roadmap gate (PM): run playbook in forge-logs/versona/product-management/roadmap-initiation/outputs/roadmap-gate-playbook.md.
2. R0.M3: publish contract gap register (can live in docs/ or sprint evidence).
3. M1: execute sprints/M1-forge-run-spine/roadmap-handoff.md — Sparks R1.SP1–SP4.
4. Ember Log: capture prioritization trade-offs for any deferred milestone.

---

Product Management Versona validation

Definition of Ready coverage

R0–R2 rows in docs/roadmap-rows.md include full readiness fields; R3–R7 milestones include outcomes and evidence at milestone/epic depth with explicit evidence requests where detail is intentionally deferred.

Product-boundary risks

No deliberate boundary violations in sequence. Watch: Lenses feature creep into reasoning; Fleet storing policy; chat as approval.

Overplanned areas

Release 5–7 intentionally avoid Spark-level detail until R4 evidence exists.

Under-evidenced assumptions

LCDL task names (decompose_problem, etc.) treated as placeholders for contract-mapped flows — actual LCDL catalog names must be reconciled (Hold for evidence on exact task IDs until LCDL owners confirm).

Must-run next Versonas

Architecture (correlation scheme) and BA (approval flows) before expanding R1 beyond the four Sparks listed.

Recommendation

Proceed with conditions — roadmap is executable for M1 and R2 planning, provided the contract gap register (R0.M3) and correlation-ID architecture note are closed or explicitly waived with recorded rationale.