Product Roadmap

Product goal and agile roadmap

Product goal #25 is the outcome index. The goal is an operable, installable RX software draft: a solo SI developer/operator configures, simulates, changes and recovers supported heat-treatment workflows with almost no manual code.

Twelve-window rolling sprint forecast: near-term task proposals and conditional later goals. This is not a completion-date promise.

Now / Next / Later

• Now: DRAFT-M0–M1. Sprint 1, October 7–9, has one user-visible goal and six leaf work items #13–#18. The overnight technical handoff remains the immediate request; the three-day window does not defer it.
• Next: refine DRAFT-M2 after the actual M1 demonstration and acceptance. Do not preassign a date or silently begin it.
• Later: DRAFT-M3–M7. These are directional outcomes, refined as evidence accumulates. One milestone may span several sprints; a completed sprint is not automatic authorization for the next milestone.

M2 demonstrates the full normal cycle, M4 demonstrates supported simulated operation/recovery, and M7 demonstrates an installable software draft. Official release, physical operation and functional-safety qualification are separate.

Milestone outcomes

Milestone	Outcome issue	User-visible result	Horizon
M0	#13	A verified development baseline makes the next UI/runtime change concrete and safe.	NOW — technical entry gate
M1	#26	The user configures and reopens one material alignment/regrasp Task, simulates it through RX and sees real results on the same graph.	NOW — Sprint 1 goal
M2	#19	The full normal dual-gripper heat-treatment cycle runs and is explainable from the graph.	NEXT — refinement after the M1 review
M3	#20	The user changes supported products and process settings without manual code and can still reopen prior published versions.	LATER — refine from actual M2 change requests
M4	#21	The operator understands failures and resumes supported operation while preserving original work and responsibility.	LATER — guarantees apply from M1; full recovery acceptance here
M5	#22	An independent author adds reusable capabilities without core edits, and the agreed authoring experience is fully connected.	LATER — independent author experience and full feature coverage
M6	#23	Independent operating areas hand over work and reconcile after disconnection without losing authority or custody.	LATER — cross-area behavior after local guarantees
M7	#24	A clean Linux consumer can install, operate, recover and upgrade the draft; a second site can reuse it with measured burden.	LATER — installable software draft, not official release authorization

Each milestone description now contains entry conditions and demonstrable exit criteria. The controlling requirements remain docs/48_draft_product_milestones.md, docs/46_workflow_product_experience.md and the detailed M0–M1 execution plan. Existing WF01–WF17, RF01–RF14 and PG07 requirements are not replaced by a small happy-path demo.

Tracking objects

Object	Meaning	How it is used
Project	Ongoing RX delivery workspace	One place for goals, backlog, plans and evidence links
Product goal	Final measurable user outcome	#25; parent of capability epics
Epic	A coherent capability or user journey	#32, #26, #19–#24; parent of executable tasks
Task	A bounded implementable or verifiable change	Child issue with owner, dependency, output and checks
Milestone	Acceptance checkpoint across work	DRAFT-M0–M7; entry/exit criteria and demonstration
Sprint	Short planning window with one goal	Schedules leaf tasks; never an extra parent layer

Native hierarchy: Goal → Epic → Task. level:goal, level:epic, level:task describe hierarchy; bug/enhancement/type:* describe the nature of work. Priority, Status, Acceptance, Size and Sprint remain Project fields. GitHub percentages indicate issue closure, not product acceptance.

Milestone and Epic are different dimensions. The initial stage/capability mapping is convenient, not a permanent one-to-one constraint. An epic can support several checkpoints; a checkpoint can require several epics. Each issue has one primary GitHub milestone; link cross-checkpoint dependencies instead of duplicating tasks.

Goals & epics view shows the outcome hierarchy. Current sprint and Sprint planning show executable tasks. Future epics remain unscheduled until refined; the current milestone does not auto-start later work.

Issue hierarchy and counting

Product goal #25 contains capability epics #32, #26 and #19–#24. Enabling epic #32 contains M0 task #13. M1 outcome #26 contains implementation/verification/handoff #14–#18. M4 #21 contains diagnostic #11; M7 #24 contains performance #10 and SDK/distribution #12. M5 references the SDK dependency without duplicating #12.

An epic is an outcome container, not an extra unit of delivery. Count leaf outcomes once; do not sum parent and child estimates, interpret a progress bar as acceptance, or create duplicate issues for different views. Later epics are XL until broken into bounded slices before Ready.

Sprint execution contract

1. Select one concrete user outcome and the minimum end-to-end slice. Refine only the next slice deeply; keep future detail flexible.
2. Ready requires a bounded result, accountable owner, dependencies, authorized environment, positive and negative checks, and evidence destination.
3. Pull work within WIP: at most two implementation items and one integration/verification item. Agent count is not independent human review capacity.
4. Report daily: demonstrated behavior, exact evidence, blocker and next action. Record actor/host separately from jack0682 as owner.
5. Review through the real UI/runtime path and ask the owner to repeat the stated scenario. M1 technical handoff stays USER_ACCEPTANCE_PENDING until accepted.
6. Retrospect using one measured friction and one improvement. Carry incomplete work explicitly; preserve prior sprint/evidence history. Added scope displaces something or goes to backlog.

Milestone dates are unset until an evidence-backed commitment. Do not invent velocity, staffing capacity or percentage completion. Measure M1 authoring time, code/configuration edits and commands, diagnosis/recovery time and developer interventions first. Later stages compare equivalent workloads and environments. Track leaf cycle time and blocked age separately from owner acceptance.

Historical migration disposition

Milestone	Current disposition	Remaining record
MIG-0	Open: scoped technical restoration ready for review; acceptance and off-device destination outstanding	#1; no off-device guarantee claimed
MIG-1	Closed: scoped signed bootstrap/import delivered	PR #2/#3
MIG-2	Closed: scoped unified CI/canonical docs delivered	PR #4/#5
MIG-3	Closed as superseded, not delivered	Draft PR #6 remains Blocked; #12 continues product verification
MIG-4	Closed: approved T1-prime cutover delivered	RT PR #7/#8/#9; legacy notices/archive preserved
MIG-5	Closed as deferred, not implemented	#27 preserves the layout decision with no Sprint

Historical milestone closure is tracking disposition, not CP2/product acceptance. Existing names/URLs and failures are retained. #27 is optional structural work, not a new product prerequisite.

Limits and evidence

Use isolated Linux for product builds/tests and actual browser integration. Preserve the original CP2 IDs, held resources, UNKNOWN, DB, volumes and load. No UI-only executor, canned success, relaxed deadlines/authority/completion, retry-to-green or silent failed-state cleanup.

Project · Project workflow · Milestones and labels · Evidence and acceptance

This is planning/governance configuration, not a claim that product acceptance has occurred. GitHub native parent/sub-issue relationships follow its sub-issue interface.