You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 5083842
Browse filesBrowse the repository at this point in the historyBrowse files
Copy file name to clipboardExpand all lines: docs/developments/2026-q4-reliable-workflow/02_Product_Roadmap.md
+10-7Lines changed: 10 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,9 +5,9 @@
5
5
6
6
| Control | Value |
7
7
|---|---|
8
-
| Status | C1-S1 repository work recorded; physical/pilot tasks blocked. Future direction remains conditional and forecasts need revision after sizing |
8
+
| Status | C1-S1 has six tasks Done, two Prepared awaiting pilot setup and four Awaiting evidence; existing channel installations verified. Future direction remains conditional and forecasts need revision after sizing |
9
9
| Planning date | 25 September 2026; dates use Asia/Bangkok |
| Inspected baseline |`main` at `23ed764b0ef88dce9720c66fbd1c0655268860cf`|
12
12
| First cycle | C1: 28 September–20 December 2026; later horizons conditional through September 2028 |
13
13
| Planning authority | Product Owner orders the Product Backlog; Developers forecast feasible work during Sprint Planning; names and capacity remain unassigned |
@@ -32,14 +32,17 @@ continues to communicate direction without promising release dates.
32
32
33
33
## Completed baseline and remaining uncertainty
34
34
35
-
These records are inputs to planning, not new achievements of this development
36
-
cycle. The [C1-S1 record](c1-s1/00_Execution_Record.md) distinguishes completed design/evidence preparation from blocked installations and observations. Future work remains **Proposed** until explicitly selected.
35
+
These records distinguish the historical baseline from the dated device retry.
36
+
The [C1-S1 record](c1-s1/00_Execution_Record.md) records completed design/evidence
37
+
preparation and existing channel installations separately from prepared pilot
38
+
work and missing observations. Future work remains **Proposed** until explicitly
39
+
selected.
37
40
38
41
| Baseline item | Recorded state at the planning date | Consequence for this roadmap |
39
42
|---|---|---|
40
43
| Android distribution and public copy | Google Play 0.2.0 open testing; direct live-site checks on 25 September confirm the PR #33 correction | Preserve accurate copy; newly found TestFlight description discrepancy is PYB-002.1 |
41
-
| App source and installed identity |Source `0.2.0+8`; source version alone does not identify an installed Play/TestFlight binary | PYB-001 records actual installed versions/builds and source mapping or explicit unknowns|
42
-
| iPad distribution |External TestFlight beta is the recorded channel | Verify the selected installation path and artifact evidence; do not infer production App Store availability |
44
+
| App source and installed identity |[Lenovo Android](c1-s1/06_Android_Channel_Verification.md): Play `0.2.0 (8)` with beta enrollment, Open and launch verified; 38/38 code/asset entries match the retained AAB | Evidence supports historical source `768fafe`; it is not complete binary equivalence, a Play Console record or validation of later source changes|
45
+
| iPad distribution |[iPad](c1-s1/07_iPad_Channel_Verification.md): existing TestFlight `0.2.0 (6)` with offered build, Open, launch and beta signing verified | Source mapping remains unknown; minimum-OS metadata conflict needs owner review. Fresh enrollment/reinstallation and production App Store availability are not claimed|
43
46
| Existing workflow | PBLE/1 editing, files, run/stop, console, Blocks, tutorials, and reviewed import already exist | Reuse implementation and tests; improve measured failures rather than rebuild the workflow |
44
47
| Firmware v0.6.1 | Owner-confirmed publication for five exact profiles; incomplete automated evidence remains visible | New qualification and compatibility claims require their own applicable evidence |
45
48
| Historical issue #24| Closed as superseded; incomplete checklist was not declared passed | Do not recreate closure as a new dependency or treat historical closure as qualification |
@@ -81,7 +84,7 @@ for one maintainer. All rows in this table have status **Proposed**.
81
84
**Sizing update:** recovery now has a 45–72 hour working estimate including supporting tasks. Its 60-hour S2–S4 allocation option would displace original matrix/activation work. The table above is the original sequencing baseline, not a validated selection; replan before using its delivery dates. The full matrix has its own [costed inventory](c1-s1/04_Validation_Inventory_and_Operator_Recipe.md).
82
85
83
86
The [Sprint Plan](04_Sprint_Plan.md) owns detailed dates and capacity. The first
84
-
Sprint Backlog now records early C1-S1 execution and its remaining blockers;
87
+
Sprint Backlog now records early C1-S1 execution and pending pilot evidence;
85
88
later allocations are forecasts requiring replanning. A milestone review neither replaces a Sprint Review nor supplies
Copy file name to clipboardExpand all lines: docs/developments/2026-q4-reliable-workflow/03_Milestones.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,9 +5,9 @@
5
5
6
6
| Control | Value |
7
7
|---|---|
8
-
| Status | M-01/SG0 assessed Blocked on 25 September; other milestones remain Proposed and forecast windows need replanning |
8
+
| Status | M-01/SG0 remains Blocked on 25 September by pilot ownership/cohort/setup and capacity decisions; existing channel installations verified on retry. Other milestones remain Proposed and forecast windows need replanning |
9
9
| Planning date | 25 September 2026; dates use Asia/Bangkok |
10
-
| Source |[Implementation strategy revision 1.3](../../planning/PyBLE_Implementation_Plan_and_Strategy_v1.0.md), especially §§4, 8–10, 14, and 19 |
10
+
| Source |[Implementation strategy revision 1.4](../../planning/PyBLE_Implementation_Plan_and_Strategy_v1.0.md), especially §§4, 8–10, 14, and 19 |
11
11
| Inspected baseline |`main` at `23ed764b0ef88dce9720c66fbd1c0655268860cf`|
12
12
| Related documents |[Framework](01_Overview_and_Scrum_Framework.md), [roadmap](02_Product_Roadmap.md), [Sprint Plan](04_Sprint_Plan.md), [stories](05_Product_Backlog_and_Stories.md), [Sprint Backlogs](06_Sprint_Backlogs.md)|
13
13
| Meaning | Milestones describe inspectable outcomes and decision evidence; they are not additional Scrum events or promised releases |
@@ -51,7 +51,7 @@ no role in this table implies committed staffing or independent review.
51
51
| M-05 — Proposed | Users can obtain the selected qualified app build through a verified existing channel | C1-S5–C1-S6, 23 Nov–20 Dec; PYB-014 and residual 002 | M-04; distribution-owner access; separate submission, availability, installed build/provenance, and installation outcome records; current user-facing claims | Verified-channel milestone passes only for the stated evidence; store delays are recorded as blockers; release owner |
52
52
| M-06 — Proposed | Useful-repeat and support evidence drives one explicit next-stage investment | C1-S6, 7–20 Dec; PYB-011 follow-up, cycle review; Ready inputs only if selected | Mature consented cohort accounting, useful Task C/return outcomes, task opportunity, prompting, missing responses, support burden, and status of candidate/channel evidence; retain blocked outcomes | SG3 assessment plus dated continue/narrow/pause-expansion decision; Product Owner with pilot and Developers |
53
53
54
-
[C1-S1 evidence](c1-s1/00_Execution_Record.md)prepares the ledger, pilot protocol, recovery contract and cost model, but does not satisfy missing human ownership, confirmed capacity, device installations or participant observations. M-01/SG0 remains blocked. M-02's S2–S3 window is the original baseline; a sized S2–S4 option now requires explicit replanning, with downstream matrix/recruitment dates reviewed together.
54
+
[C1-S1 evidence](c1-s1/00_Execution_Record.md)includes the ledger, pilot protocol, recovery contract, cost model and verified existing Play/TestFlight installations. Six tasks are Done, two are Prepared awaiting pilot setup and four await participant/observation evidence. Human ownership, cohort/setup and actual capacity remain unconfirmed, so M-01/SG0 remains blocked. Missing participants are recorded as a recruitment gap, not completed observations. Current-build verification does not pass M-05 for a future qualified update. M-02's S2–S3 window is the original baseline; a sized S2–S4 option now requires explicit replanning, with downstream matrix/recruitment dates reviewed together.
55
55
56
56
M-04 may occur in any Sprint once a maintenance candidate qualifies. M-03 and
57
57
M-06 do not block it. M-06 can assess learning and choose a narrower next step
|`C1-S1`|Early repository execution recorded; remaining device/pilot tasks blocked. Actual staffing and the original formal timebox still require confirmation |
19
+
|`C1-S1`|Six tasks Done, including existing channel installations; two Prepared awaiting pilot setup and four Awaiting evidence. Actual staffing and the original formal timebox still require confirmation |
20
20
|`C1-S2` … `C1-S6`| Forecasts revised using preceding results, capacity and learning |
21
21
| Sprint Goal | One coherent outcome confirmed by the Scrum Team at Planning |
22
22
| Scope and task details | Developers select feasible items and adapt their plan with the Product Owner as learning changes scope |
@@ -26,14 +26,14 @@
26
26
27
27
## C1-S1 findings and required reforecast
28
28
29
-
[Execution evidence](c1-s1/00_Execution_Record.md) records four completed repository tasks and eight blocked installation/pilot tasks. The original calendar is retained; no completed Sprint or SG0 approval is claimed.
29
+
[Execution evidence](c1-s1/00_Execution_Record.md) records six Done tasks after verifying existing Play and TestFlight installations. T04/T05 are Prepared awaiting pilot setup; T06–T08 await participants and T09 awaits observation records. These more specific states preserve their acceptance criteria. The original calendar is retained; no completed Sprint or SG0 approval is claimed.
30
30
31
31
| New sizing input | Planning consequence |
32
32
|---|---|
33
33
| Recovery engineering 38–63h; recipe, representative physical work and one follow-up allowance bring the original two-week scope to 45–72h | Original S2 allowance is insufficient; contract and all required failure/session protections remain intact |
34
34
|[Working allocation option](c1-s1/03_Recovery_Design_and_Sizing.md): S2 26h, S3 22h, S4 12h, totaling 60h | Fits within the three 26h ceilings only by replacing original selections; includes 50h engineering, 2h recipe, 5h physical and 3h rolling follow-up |
35
35
|[App matrix](c1-s1/04_Validation_Inventory_and_Operator_Recipe.md): 13.5–26 operator h; fresh firmware qualification 30–59h excluding builds/access/repair | Select the applicable scope; do not treat app-only work as a new firmware release or count representative recovery runs twice |
36
-
|Missing human capacity, pilot owner and physical access | Confirm before selecting the revised scope; maintain rolling follow-up only for actual consenting activations |
36
+
|Connected tablets now verified; human capacity, pilot owner and exact-board setup still unconfirmed | Bind future recovery runs to their actual candidate and board, and confirm owners before selecting revised scope; maintain rolling follow-up only for actual consenting activations |
37
37
38
38
The remaining 18h under S2–S4's combined 78h ceiling cannot silently absorb all displaced matrix, activation and repair tasks. Reorder those tasks, review the November recruitment window, and reforecast S5/S6 if required. The tables below preserve the original allowance/calendar for comparison; they are **not** an adopted revised forecast. A tested foundation is not the completed recovery user story. All selected increments still need their applicable Definition of Done.
0 commit comments