Sprint Plan

Sprint forecast — 2026-10-07

Final goal: an operable, installable RX product draft that a solo SI developer/operator can configure, simulate, change and recover with almost no manual code for supported workflows. Goal #25.

This is a rolling planning forecast, not a promised November 11 completion date. Sprint 1 is active. Sprints 2–4 have proposed leaf tasks; Sprints 5–12 are directional goal windows only. Actual capacity/velocity is not yet measured, so any milestone may consume additional sprints. Preserve the full accepted requirements instead of shrinking them to fit this calendar.

Current evidence: M0_BASELINE.md and M1_VALIDATION.md still record incomplete integration validation. Implemented code, successful unit checks and closed duplicate issues #28–#31 do not establish M1 acceptance. The exact M1 candidate/evidence and owner reproduction must be reviewed first.

Three-day goal forecast (Asia/Seoul)

Sprint	Planning window	Primary checkpoint	User-visible goal	Entry / review gate	Work
1	2026-10-07–2026-10-09	M0–M1	One real configured Task roundtrip	Complete T01–T10 and verified handoff; M1 remains Pending until owner repeats/accepts.	Existing #13–#18
2	2026-10-10–2026-10-12	M2 / first exchange	One complete exchange with correct material and custody	M1 accepted + M2 scope authorized; otherwise prioritize M1 carryover.	#33,#34
3	2026-10-13–2026-10-15	M2 / full cycle	Normal repetition, parallel machining/preparation and readiness join	Sprint 2 slice demonstrated; accepted full M2 demo required before M3.	#35,#36
4	2026-10-16–2026-10-18	M3 / one variation	Change one process configuration and preserve its prior version	M2 accepted + M3 scope authorized; select a real bounded change.	#37,#38
5	2026-10-19–2026-10-21	M3 / configuration breadth	Property Sets, Target Groups, repetition and single/dual variants	Review Sprint 4 results; refine remaining WF configuration requirements.	Refine from Epic #20
6	2026-10-22–2026-10-24	M4 / diagnosis	Known failure vs UNKNOWN, original custody and operator decisions	M3 review; retain M1 guarantees and reproduce supported failure scenarios.	Refine from Epic #21 and #11
7	2026-10-25–2026-10-27	M4 / operational return	Supported restart/restore/replacement and new work in the same installation	Diagnostic evidence and explicitly supported recovery paths available.	Refine from Epic #21
8	2026-10-28–2026-10-30	M5 / external author	Independent capability registration and execution without core edits	Stable authoring/execution/recovery surfaces; define isolated author trial.	Refine from Epic #22 and SDK dependency #12
9	2026-10-31–2026-11-02	M5 / full authoring	Close agreed authoring-feature and PG07 integration gaps	External author trial reviewed; preserve full WF/RF/PG07 requirement matrix.	Refine from Epic #22
10	2026-11-03–2026-11-05	M6 / area cooperation	Handover, bounded disconnection and reconnection settlement	Local recovery proven; define two-host and third-area chain cases.	Refine from Epic #23
11	2026-11-06–2026-11-08	M7 / installation	Clean install, upgrade, SDK consumers and verified operator reproduction	Earlier required outcomes accepted; define exact supported artifact matrix.	Refine from Epic #24 and #12
12	2026-11-09–2026-11-11	M7 / draft review	Load/soak, second-site reuse and final software-draft review	Do not waive existing 24-hour/quality requirements to fit a three-day window.	Refine from Epic #24 and #10

Near-term task commitments

The six new task issues contain a user outcome, checks, parent Epic, dependencies and evidence requirements. Assigning a future Sprint is a planning proposal; they remain Backlog / P2 / Acceptance Pending until entry conditions and next-phase authorization are satisfied. Do not begin M2+ under the current M0–M1 execution instruction.

• Sprint 2: #33 (one exchange) and #34 (prerequisites/refusal), Epic #19.
• Sprint 3: #35 (parallel work/join) and #36 (repetition/startup/shutdown), Epic #19.
• Sprint 4: #37 (one configuration variation) and #38 (immutable prior version), Epic #20.
• Proposed Size: M for each, relative uncertainty/complexity, not an hourly estimate. Review size before Ready and split a task if it cannot fit a coherent demonstrable slice.

Dependencies: M1 owner acceptance → #33/#34 → #35 → #36 + M2 acceptance → #37 → #38. This is delivery sequencing, not a license to skip independent verification or create false acceptance.

Capacity and carryover

Use at most two new implementation tasks per planned future sprint, with verification/integration included in their completion scope. Reserve available effort for failure diagnosis, regression, review and carryover; no fabricated hours or velocity. Retain WIP at most two implementation items plus one integration/verification item. Agent concurrency does not create independent maintainer review capacity.

If M1 does not meet its gate, Sprint 2 first completes original M1 verification/handoff. Do not start the new exchange scope merely because the calendar advanced. Each later window shifts or loses scope when its entry gate is unmet. Existing tasks/IDs/evidence stay intact; record the original and revised assignment in the sprint review. No silent reset, deadline relaxation or cherry-picked green run.

Three-day routine and review output

• Opening planning: state one sprint goal; review carryover, prerequisite acceptance, authorized environment, owner, size and positive/negative checks. Confirm the selected leaf tasks, not whole epics.
• Daily update: new user-visible behavior / exact evidence / blocker and unblock condition / next action.
• Mid-sprint check: reduce new scope if the integrated path or negative cases are not demonstrated; do not postpone all integration until the last day.
• Review: the owner follows the real UI scenario and reviews normal, confirmed failure, UNKNOWN/custody and version behavior. Technical handoff and user acceptance remain separate.
• Retrospective: record one measured friction, one retained practice and one small improvement for the next sprint. Use authoring/change/diagnosis/recovery burden, leaf cycle time and blocked age; do not double-count parents and children.

Review template:

Sprint / original goal / selected task IDs:
Demonstrated behavior and exact source/environment:
Normal and negative evidence / unverified limits:
Owner acceptance decision or USER_ACCEPTANCE_PENDING:
Carryover IDs, reason, and proposed next assignment:
One improvement for the next sprint:
Next sprint goal and entry conditions:

All product tests/builds/browser runtime remain on isolated Linux. Preserve the original CP2 installation/identities/UNKNOWN/custody and its original failures. Calendar planning does not authorize physical operation, new paid infrastructure, an official release or an unreviewed semantic change.

Goals and epics · Sprint planning · Current sprint

Three-day cadence decision — 2026-10-07

The owner selected 3-day Sprints. Twelve existing iteration identities and task assignments are retained, with contiguous calendar-day windows from October 7 through November 11 (36 days). This replaces the earlier weekly forecast; it is not a promise that all product requirements will fit 36 days. Milestone due dates remain unset.

Day 1: select the smallest complete user result, confirm prerequisites and implement its connection. Day 2: integrate the real UI/API/runtime path and exercise negative cases. Day 3: demonstrate, review evidence with the owner, and record acceptance or explicit carryover plus one improvement. Each near-term two-task pair serves one outcome; if capacity is insufficient, reduce new scope rather than omitting verification.

No regression, UNKNOWN/custody, deadline/authority/completion, owner acceptance or required 24-hour soak check is removed. If a gate is unmet, shift the next window's scope and preserve original evidence. A new iteration added later must also be configured as three calendar days.