Handbook
M1 Forge Run Spine — Roadmap handoff
Translates docs/product-roadmap.md Release R1 into the first execution slice for sprint M1-forge-run-spine. Hermes, Factory, and OpenClaw are not in the critical path for M1 closure.
Product outcome
A static, reviewable chain proves the platform can represent intent lineage, approval, agent/workcell placeholders, LCDL trace placeholder, Fleet job placeholder, EvidencePacket, and decision-facing evidence — so Lenses (and other consumers) can attach without a parallel run model.
Why M1 now
R0 establishes credibility of boundaries and contract gaps; R1 is the lingua franca gate for every later release (Lenses visibility, LCDL traces, Fleet jobs, agents). Without R1, product teams will fork schemas.
Release alignment
- Release: R1 — Forge Run Spine MVP
- Milestones in scope for this handoff: R1.M1–R1.M6 (hardening + sample chain + Lenses handoff package)
- Strategic objectives: S1 (credible spine), partial S2 (handoff to Lenses only)
Milestones included
| ID | Focus |
|---|---|
| R1.M1 | ForgeRun v1 hardened |
| R1.M2 | EvidencePacket v1 hardened |
| R1.M3 | ApprovalRequest v1 hardened |
| R1.M4 | AgentRun / WorkcellRequest / WorkcellResult hardened |
| R1.M5 | Static sample chain validates |
| R1.M6 | M2 Lenses handoff sample complete |
Epics included
- R1.E1 —
EPIC-CORE-FORGE-RUN-SPINE - R1.E2 —
EPIC-CORE-EVIDENCE-PACKET - R1.E3 —
EPIC-LENSES-BLUEPRINTS-CONTEXT-PANEL(contract alignment / stub only in M1) - R1.E4 —
EPIC-BLUEPRINTS-VERSONA-DEFINITIONS(references / stub)
Stories to draft next
| Story | Note |
|---|---|
| R1.S1 | End-to-end static JSON bundle under samples/ |
| R1.S2 | EvidencePacket references all intersection-map artifact types (placeholders OK) |
| R1.S3 | ApprovalRequest sample encodes human boundary per docs/approval-model.md |
| R1.S4 | AgentRun + Workcell correlation IDs consistent with ForgeRun |
| R1.S5 | M2 handoff doc: fixtures, glossary, panel mapping for Lenses |
Sparks to draft next (immediate)
| Spark | Intent |
|---|---|
| R1.SP1 | Audit schemas/*.json vs docs/intersection-map.md → gap list for R0.M3 |
| R1.SP2 | Normalize sample filenames / schema fields; keep scripts/check_foundation.py green |
| R1.SP3 | Refresh docs/agent-workcell-model.md narrative for correlation |
| R1.SP4 | Write evidence notes under sprints/M1-forge-run-spine/evidence/ |
Contracts to harden
schemas/forge_run.v1.schema.jsonschemas/evidence_packet.v1.schema.jsonschemas/approval_request.v1.schema.jsonschemas/agent_run.v1.schema.jsonschemas/workcell_request.v1.schema.jsonschemas/workcell_result.v1.schema.json- (Placeholders in samples)
schemas/lcdl_trace_summary.v1.schema.json,schemas/fleet_job_summary.v1.schema.jsonas referenced by EvidencePacket / intersection map
Do not change schemas on speculation — record inconsistencies as evidence requests for Architecture unless blocking.
Human gates
- Schema breaking-change review if identifiers or required fields shift
- Approval model alignment with
docs/approval-model.mdfor ApprovalRequest samples - Platform assay per
docs/milestone-plan.mdbefore claiming M1 “close”
Evidence required to close M1
- Green foundation check (
python3 scripts/check_foundation.py) - Sample chain checklist or CI step (documented even if manual first)
sprints/M1-forge-run-spine/evidence/updated with assay + sample pointers- R1.M6 handoff package consumable by Lenses team (path + README)
Risks
- LCDL/Fleet naming drift in samples vs shipping repos — mitigate with explicit “placeholder” labels until R3/R4
- Over-scoping M1 into Lenses UI — keep UI work in M2/R2
Suggested next prompts
- Architecture Versona: “Draft correlation-ID conventions for ForgeRun, ApprovalRequest, FleetJobSummary, WorkcellResult; flag schema impacts.”
- Forge Product Manager (authoring): “Decompose R1.S1–S5 into Ingots and Sparks with DoR per
docs/sprint-structure.md.” - Roadmap gate (PM): After M1 evidence is posted, run review template to produce
roadmap-gate-review.md.