[docs] reconcile merged recovery candidate and continuation plan

Signed-off-by: Viwat Vchirawongkwin <viwat.v@chula.ac.th>

Author: yyods

CHANGELOG.md

@@ -10,16 +10,15 @@ or firmware release. Firmware v0.6.1 is published on the owner's confirmation;
 incomplete automated evidence remains pending. The qualified v0.6.0 release
 remains a separate historical baseline built from its annotated tag.
 
-The current compatible app feature set now targets `0.2.0`; build `5` was
-handed off through Transporter for TestFlight. This candidate identity improves
-test and evidence traceability but does not designate a qualified store release
-or claim App Store Connect processing, beta-review approval, or availability.
-The next prepared Android open-testing candidate is `0.2.0 (8)`; its bundle
-and submission packet do not claim Play submission, approval, or rollout.
+The merged app source now targets `0.3.0+9`. Its local Android and iPad Preview
+installations are engineering candidates, with release qualification and channel
+delivery tracked separately. The recorded existing-channel baseline is Android
+Play `0.2.0 (8)` and iPad TestFlight `0.2.0 (6)`; the earlier build-5 Transporter
+and build-8 submission handoffs remain historical artifact records.
 
 ### App source
 
-- Prepared app source candidate `0.3.0+9` with bounded on-device current-text
+- Merged app source candidate `0.3.0+9` with bounded on-device current-text
   recovery using Drift. Exact text and metadata commit atomically; startup
   offers offline preview, Restore and confirmed Discard, with separate local
   checkpoint status and an explicit Save recovery copy action. Storage errors

README.md

@@ -75,7 +75,7 @@ fetches and validates the complete batch, shows the exact destination paths,
 and asks separately before overwriting existing files. Import never creates a
 remote folder hierarchy, opens an editor document, or runs downloaded code.
 
-The next App source candidate is `0.3.0+9`; App and firmware versions are
+The merged App source candidate is `0.3.0+9`; App and firmware versions are
 independent. The published Android version is `0.2.0`, available through
 [Google Play open testing](https://play.google.com/store/apps/details?id=dev.pyble.pyble).
 iPad testing continues through TestFlight. The
@@ -93,7 +93,7 @@ same Flutter source and app test gates. The iOS/iPadOS project minimum is 15.
 
 ### Next app candidate: local draft recovery
 
-The `0.3.0+9` source candidate adds one on-device current-text recovery copy.
+The merged `0.3.0+9` candidate adds one on-device current-text recovery copy.
 After restart, preview and explicitly Restore or Discard the last committed
 copy before connecting. “Saved locally” means the matching transaction finished;
 pending edits may not survive immediate termination. The separate **Save
@@ -104,8 +104,9 @@ This bounded feature covers text up to 1 MiB, including Python explicitly copied
 from Blocks. Blocks workspace graphs, projects/history and exported backups
 remain outside this increment. Uninstalling or clearing app data removes local
 copies. See the [candidate execution record](docs/developments/2026-q4-reliable-workflow/c1-s2/00_Execution_Record.md)
-for automated and device evidence; source implementation does not establish
-store availability or release qualification.
+for passing automated checks and candidate-specific device evidence. Local
+Android and iPad Preview installations are engineering candidates; their
+installation does not establish store availability or release qualification.
 
 ### Firmware
 

docs/ROADMAP.md

@@ -38,13 +38,14 @@ v0.7.0 remains non-normative and requires separate maintainer approval.
   was not exercised. The pilot kit, recovery design and validation inventory
   are prepared; this does not complete the Sprint or board qualification.
 - Validate and qualify the implemented [bounded current-text recovery candidate](developments/2026-q4-reliable-workflow/c1-s2/00_Execution_Record.md)
-  against the [contract](specifications/App/current-draft-recovery.md). Source
+  against the [contract](specifications/App/current-draft-recovery.md). Merged
   candidate `0.3.0+9` supplies atomic local checkpoints and offline recovery;
   full A-24 and Blocks graph persistence remain separate scope. The original
   45–72 hour estimate remains a forecast, not measured effort.
 - Correct the [stale public TestFlight description](developments/2026-q4-reliable-workflow/c1-s1/05_TestFlight_Metadata_Correction.md)
   through the distribution owner; replacement copy is prepared, not published.
-- Prepare the next app `0.3.0+9` candidate while retaining the published 0.2.0 channel baseline. The
+- Complete release qualification and channel delivery for merged app `0.3.0+9`,
+  retaining the recorded 0.2.0 channel baseline until the new channel is verified. The
   [Android publication review](testing/website/android-open-testing-2026-09-25.md)
   records live open-testing availability. The
   [prepared build-8 handoff](testing/google-play/0.2.0-build-8.md) remains a

docs/decisions/0048-bounded-current-text-draft-recovery.md

@@ -5,8 +5,9 @@
 
 **Status:** Accepted for the bounded implementation; candidate source implemented
 2026-10-31 under the user's next-release request. The contract was specified
-2026-09-25 during C1-S1. Final integrated checks, required physical evidence and
-release admission remain pending; no named human sign-off is claimed.
+2026-09-25 during C1-S1. PR #40 merged the source and integrated CI passes.
+Required physical acceptance and release admission remain pending; no named
+human sign-off is claimed.
 
 ## Context
 

docs/developments/2026-q4-reliable-workflow/01_Overview_and_Scrum_Framework.md

@@ -18,7 +18,7 @@
 
 This package derives execution views from the strategy. It does not replace normative specifications, expand hardware claims, create GitHub issues, or authorize store/website publication. The strategy and original package were recorded together in planning baseline `d039db0`. The [C1-S1 execution record](c1-s1/00_Execution_Record.md) owns actual results and blockers.
 
-**31 October implementation update:** bounded recovery work is underway for candidate `0.3.0+9`, following the user’s next-release request. [C1-S2 implementation record](c1-s2/00_Execution_Record.md) records source, automated and physical states separately. S1 remains six Done / two Prepared / four Awaiting evidence. Original dates/hours below remain the planning baseline; no completed Sprint, adopted 60-hour capacity forecast or release admission is inferred.
+**31 October continuation update:** bounded recovery candidate `0.3.0+9` is merged in [PR #40](https://github.com/PyBLE-dev/PyBLE/pull/40) at `6f5b3ea`; the integrated suite and post-merge CI pass. Both tablets have local candidate installations and native storage restart evidence. [C1-S2 implementation record](c1-s2/00_Execution_Record.md) tracks the remaining physical acceptance separately from release qualification. S1 remains six Done / two Prepared / four Awaiting evidence. Original dates/hours remain the planning baseline; the current continuation order and unresolved capacity inputs are recorded in the [Sprint plan](04_Sprint_Plan.md#31-october-continuation-order-and-reforecast).
 
 ## Navigation and ownership of information
 
@@ -35,7 +35,7 @@ This package derives execution views from the strategy. It does not replace norm
 
 ```mermaid
 flowchart LR
-    Strategy["Strategy revision 1.4"] --> Goal["One Product Goal"]
+    Strategy["Strategy revision 1.6"] --> Goal["One Product Goal"]
     Goal --> Roadmap["Outcome roadmap and milestones"]
     Roadmap --> Product["Ordered Product Backlog"]
     Product --> Planning["Sprint Planning"]
@@ -140,7 +140,7 @@ When facts or priority change, update the canonical file above and its dependent
 
 | Source | Use and precedence |
 |---|---|
-| [Strategy revision 1.4](../../planning/PyBLE_Implementation_Plan_and_Strategy_v1.0.md) | Scope, targets, six-Sprint capacity, three outcomes, Ready program and conditional horizons |
+| [Strategy revision 1.6](../../planning/PyBLE_Implementation_Plan_and_Strategy_v1.0.md) | Scope, targets, six-Sprint capacity, three outcomes, Ready program and conditional horizons |
 | [Public roadmap](../../ROADMAP.md), [README](../../../README.md) | Current capability and distribution baseline |
 | [App specification](../../specifications/App/specs.md), [App TDD](../../specifications/App/TDD.md), [ADR-0010](../../decisions/0010-working-loop-in-memory-document.md) | Persistence contract and recorded implementation deviation; consult frozen working-loop scope |
 | [Firmware roadmap](../../planning/firmware-v0.6.1-v0.7.0-roadmap.md), [PBLE/1](../../specifications/protocol.md) | v0.7 proposals versus frozen wire behavior; old v0.6.1 publication/#24 wording is historical |

docs/developments/2026-q4-reliable-workflow/02_Product_Roadmap.md

@@ -7,13 +7,13 @@
 |---|---|
 | 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 |
 | Planning date | 25 September 2026; dates use Asia/Bangkok |
-| Source | [Implementation strategy revision 1.4](../../planning/PyBLE_Implementation_Plan_and_Strategy_v1.0.md), particularly §§1, 6–9, 12, 14, and 19 |
+| Source | [Implementation strategy revision 1.6](../../planning/PyBLE_Implementation_Plan_and_Strategy_v1.0.md), particularly §§1, 6–9, 12, 14, and 19 |
 | Inspected baseline | `main` at `23ed764b0ef88dce9720c66fbd1c0655268860cf` |
 | First cycle | C1: 28 September–20 December 2026; later horizons conditional through September 2028 |
 | Planning authority | Product Owner orders the Product Backlog; Developers forecast feasible work during Sprint Planning; names and capacity remain unassigned |
 | Related documents | [Framework](01_Overview_and_Scrum_Framework.md), [milestones](03_Milestones.md), [Sprint Plan](04_Sprint_Plan.md), [stories](05_Product_Backlog_and_Stories.md), [Sprint Backlogs](06_Sprint_Backlogs.md) |
 
-**31 October implementation update:** bounded recovery work is underway for candidate `0.3.0+9`, following the user’s next-release request. [C1-S2 implementation record](c1-s2/00_Execution_Record.md) records source, automated and physical states separately. S1 remains six Done / two Prepared / four Awaiting evidence. Original dates/hours below remain the planning baseline; no completed Sprint, adopted 60-hour capacity forecast or release admission is inferred.
+**31 October continuation update:** bounded recovery candidate `0.3.0+9` is merged in [PR #40](https://github.com/PyBLE-dev/PyBLE/pull/40) at `6f5b3ea`; the integrated suite and post-merge CI pass. Both tablets have local candidate installations and native storage restart evidence. [C1-S2 implementation record](c1-s2/00_Execution_Record.md) tracks the remaining physical acceptance separately from release qualification. S1 remains six Done / two Prepared / four Awaiting evidence. Original dates/hours remain the planning baseline; the current continuation order and unresolved capacity inputs are recorded in the [Sprint plan](04_Sprint_Plan.md#31-october-continuation-order-and-reforecast).
 
 ## Product Goal and decision principle
 

docs/developments/2026-q4-reliable-workflow/03_Milestones.md

@@ -7,12 +7,12 @@
 |---|---|
 | Status | M-01/SG0 remains Blocked on 25 September by pilot ownership/cohort/setup and capacity decisions; existing channel installations verified on retry. M-02 is in progress in the 31 October candidate with acceptance pending; other milestones remain Proposed and forecast windows need replanning |
 | Planning date | 25 September 2026; dates use Asia/Bangkok |
-| Source | [Implementation strategy revision 1.4](../../planning/PyBLE_Implementation_Plan_and_Strategy_v1.0.md), especially §§4, 8–10, 14, and 19 |
+| Source | [Implementation strategy revision 1.6](../../planning/PyBLE_Implementation_Plan_and_Strategy_v1.0.md), especially §§4, 8–10, 14, and 19 |
 | Inspected baseline | `main` at `23ed764b0ef88dce9720c66fbd1c0655268860cf` |
 | 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) |
 | Meaning | Milestones describe inspectable outcomes and decision evidence; they are not additional Scrum events or promised releases |
 
-**31 October implementation update:** bounded recovery work is underway for candidate `0.3.0+9`, following the user’s next-release request. [C1-S2 implementation record](c1-s2/00_Execution_Record.md) records source, automated and physical states separately. S1 remains six Done / two Prepared / four Awaiting evidence. Original dates/hours below remain the planning baseline; no completed Sprint, adopted 60-hour capacity forecast or release admission is inferred.
+**31 October continuation update:** bounded recovery candidate `0.3.0+9` is merged in [PR #40](https://github.com/PyBLE-dev/PyBLE/pull/40) at `6f5b3ea`; the integrated suite and post-merge CI pass. Both tablets have local candidate installations and native storage restart evidence. [C1-S2 implementation record](c1-s2/00_Execution_Record.md) tracks the remaining physical acceptance separately from release qualification. S1 remains six Done / two Prepared / four Awaiting evidence. Original dates/hours remain the planning baseline; the current continuation order and unresolved capacity inputs are recorded in the [Sprint plan](04_Sprint_Plan.md#31-october-continuation-order-and-reforecast).
 
 ## Assessment and evidence states
 

docs/developments/2026-q4-reliable-workflow/04_Sprint_Plan.md

@@ -5,14 +5,14 @@
 
 | Field | Value |
 |---|---|
-| Status | C1-S1 remains partial; bounded S2 candidate implementation selected 31 October with acceptance pending. Original S2–S6 dates/hours remain baseline forecasts requiring capacity reconciliation |
+| Status | C1-S1 remains partial; bounded S2 candidate merged 31 October with physical acceptance pending. Original S2–S6 dates/hours remain baseline forecasts requiring capacity reconciliation |
 | Cycle | `C1`, 28 September–20 December 2026, Asia/Bangkok |
-| Basis | [Strategy revision 1.4, §8](../../planning/PyBLE_Implementation_Plan_and_Strategy_v1.0.md#8-twelve-week-implementation-schedule) |
+| Basis | [Strategy revision 1.6, §8](../../planning/PyBLE_Implementation_Plan_and_Strategy_v1.0.md#8-twelve-week-implementation-schedule) |
 | Product Goal and quality rules | [Working agreement](01_Overview_and_Scrum_Framework.md) |
 | Acceptance criteria | [Product backlog and stories](05_Product_Backlog_and_Stories.md) |
 | Task-level proposal | [Sprint backlogs](06_Sprint_Backlogs.md) |
 
-**31 October implementation update:** bounded recovery work is underway for candidate `0.3.0+9`, following the user’s next-release request. [C1-S2 implementation record](c1-s2/00_Execution_Record.md) records source, automated and physical states separately. S1 remains six Done / two Prepared / four Awaiting evidence. Original dates/hours below remain the planning baseline; no completed Sprint, adopted 60-hour capacity forecast or release admission is inferred.
+**31 October continuation update:** bounded recovery candidate `0.3.0+9` is merged in [PR #40](https://github.com/PyBLE-dev/PyBLE/pull/40) at `6f5b3ea`; the integrated suite and post-merge CI pass. Both tablets have local candidate installations and native storage restart evidence. [C1-S2 implementation record](c1-s2/00_Execution_Record.md) tracks the remaining physical acceptance separately from release qualification. S1 remains six Done / two Prepared / four Awaiting evidence. Original dates/hours remain the planning baseline; the current continuation order and unresolved capacity inputs are recorded in the [Sprint plan](04_Sprint_Plan.md#31-october-continuation-order-and-reforecast).
 
 ## Forecast and commitment boundary
 
@@ -44,7 +44,7 @@ The remaining 18h under S2–S4's combined 78h ceiling cannot silently absorb al
 The next-release instruction selects PYB-006.2 engineering and its required
 verification, supporting PYB-009.1 recipe work and applicable PYB-008.1 evidence.
 The [execution record](c1-s2/00_Execution_Record.md) owns actual results. Source
-storage/coordinator/UI/guard work is implemented; the usable story remains in
+storage/coordinator/UI/guard work is merged and automated checks pass; the usable story remains in
 progress until all applicable acceptance passes. The original 12–25 October S2
 window is historical; calendar position does not mark S2 or S3 complete.
 
@@ -54,6 +54,32 @@ the tables below. Reorder displaced matrix/activation work with actual capacity;
 keep pilot evidence and the M-01/SG0 gap visible while known engineering work
 continues. No automatic completion of S1, SG0, broader A-24 or PyBLE Ready follows.
 
+## 31 October continuation order and reforecast
+
+The user requested completion of the remaining work after reviewing the stage
+assessment. The selected engineering order is below. This records actual work
+selection; it does not invent a completed Sprint Planning event, human staffing,
+measured velocity or a new delivery deadline. The original C1-S3 window is
+26 October–8 November; unfinished S2 acceptance carries into that window.
+
+| Order / stream | Current work and completion evidence | Forecast treatment |
+|---|---|---|
+| 1 — M-02 recovery acceptance | Complete remaining representative iPad/Android recovery, current-board consent and Blocks-to-Editor checks; reconcile DR-T01–14 against exact artifacts and review the result | Selected now; record actual duration and residual scenarios before forecasting completion |
+| 2 — M-04 release qualification | Freeze the selected app artifacts and complete the applicable five-profile × two-platform affected app matrix, provenance and release review | Follows accepted recovery behavior; unchanged firmware does not automatically require fresh firmware-release qualification |
+| 3 — M-05 distribution | Prepare the existing Play/TestFlight handoffs; submit only an admitted candidate; record processing/availability and installed-channel evidence separately | Preparation can overlap qualification; external access/review duration is unresolved |
+| Parallel — M-01 pilot baseline | Confirm pilot owner, primary cohort, exact reference setup and actual weekly capacity; collect real consented baseline sessions using the prepared kit | Awaiting human inputs; engineering observations are not participant starts |
+| Later — M-03/M-06 learning | Collect useful-task and prospective day-7–14 follow-up observations from actual consenting activations | Preserve original recruitment targets; reforecast dates after real recruitment and capacity are known |
+| Conditional — Ready rehearsal | Use an assigned second operator for one exact profile only after capacity is selected | Remains optional; it is not a prerequisite for unrelated maintenance delivery |
+
+Required planning inputs are the named pilot/recruitment owner, selected cohort
+and reference setup, actual engineering/pilot hours per week, and any existing
+consented session records. Until supplied, the 20h/week assumption, 45–72h
+recovery estimate and 60h allocation option remain historical planning inputs.
+Do not subtract agent wall-clock time from human capacity or relabel elapsed
+calendar time as measured engineering effort. Maintain the original 22 November
+activation target alongside any later approved forecast; missed windows remain
+missing or late evidence.
+
 ## Capacity model
 
 The source assumes one primary maintainer at 20 hours/week. Confirm real availability and any contributor capacity at Planning; extra roles do not create extra hours.