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 9badcdb
Browse filesBrowse the repository at this point in the historyBrowse files
Copy file name to clipboardExpand all lines: docs/developments/2026-q4-reliable-workflow/c1-s2/02_Platform_Qualification.md
+58-6Lines changed: 58 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -67,8 +67,8 @@ technology and P01–P15 coverage are still outstanding.
67
67
| Release compile |`flutter build ios --release --no-codesign` succeeded in the isolated copied project |
68
68
| Signed harness compile |`flutter build ios --debug --target integration_test/draft_recovery_device_qualification.dart --dart-define=PYBLE_RECOVERY_TEST_PHASE=seed` succeeded using an available development identity |
69
69
| Installation | Direct `devicectl` installation of the signed isolated harness succeeded; the existing TestFlight application was preserved |
70
-
| Launch |Both wireless and USB Flutter attempts reported that Developer Mode must be enabled; no successful harness or production-UI execution is claimed|
71
-
| Next action |Owner enables Settings → Privacy & Security → Developer Mode, restarts/confirms if required, unlocks and reconnects; then execute seed → terminate → verify and P01–P15 as applicable|
70
+
| Launch |Wireless and USB Flutter debug attempts reported that Developer Mode must be enabled; subsequent signed profile harness execution succeeded as recorded below|
71
+
| Next action |Complete production UI/board P01–P15 as applicable. Profile seed → terminate → verify has passed using current settings; Developer Mode remains an optional prerequisite for the separate debug/JIT route|
72
72
73
73
A signed build is build evidence. It does not establish successful installation,
74
74
execution, offline restoration, TestFlight availability or physical BLE behavior.
@@ -106,10 +106,26 @@ Names are contextual labels, not new identity or authorization evidence.
106
106
Source inspection found no four-result limit: the adapter filters by PBLE
107
107
service UUID, the accumulator retains distinct OS device IDs and the list
108
108
renders the complete hit count. Both ESP/Pico agents resume advertising after
109
-
disconnection. An active connection elsewhere or absent firmware advertising
110
-
can explain a missing board, but neither cause has yet been established for
111
-
`8C9E`. USB enumeration of its CP2102 adapter alone does not prove agent health.
112
-
No board was reset, flashed or sent a command during this diagnosis.
109
+
disconnection. The live classic ESP32 was subsequently identified through its CP2102 ROM
110
+
interface: ESP32-D0WD revision 1.0, base MAC ending `8C:9C` (Bluetooth suffix
111
+
`8C9E`). A 115200-baud read of the first 256 KiB matches the retained c8f549ee
112
+
0.6.1 install prefix at offset 0x1000. The initial 460800-baud attempt had a
113
+
framing error; no flash write occurred. Exact complete-image equivalence is
114
+
not inferred from a prefix.
115
+
116
+
A 45-second controlled startup trace then captured:
117
+
`PyBLE workspace recovery is required; reconnect by USB.`, followed by the
118
+
MicroPython 1.28.0 / PyBLE 0.6.1 banner and REPL. This confirms the workspace
119
+
mount/refusal path, which deliberately withholds BLE agent startup. It explains
120
+
the absent fifth advertisement. Short early captures missed the later message;
121
+
the guard scans the complete 2 MiB workspace before refusing it.
122
+
123
+
Retained September qualification records for the same board contain an
124
+
intentional invalid-media fixture and a failed acquisition before its planned
125
+
recovery. Its fixture hash is preserved separately; this history alone does not
126
+
prove current contents. The fresh complete current workspace backup exactly matched that refusal fixture. The verified original owner backup
127
+
and its valid LFS2 workspace remain intact, with identical partition geometry.
128
+
ROM reads and startup tracing involved controlled resets. The verified valid pre-test workspace was then restored only to its original region, and the next scan shows all five boards. See the [recovery report](03_Classic_ESP32_Workspace_Recovery.md) for backups, hashes, offline inventory and the verified write.
`lenovo-real-save-consent.xml`, `lenovo-real-run-consent.xml` and
159
+
`lenovo-print-run-result.xml`. The automated recording seams remain the evidence
160
+
for exact zero-verb cancellation/race assertions; no radio packet capture was
161
+
claimed for the physical cancellation.
162
+
163
+
Afterward only the created 10-byte `/untitled.py` test file was explicitly
164
+
deleted, with its exact-name confirmation. Existing directories were preserved.
165
+
New then committed the empty local slot; the disposable Editor text was cleared
166
+
and its saved-local status retained. A fresh launch after that tombstone showed no stale recovery prompt or test text, and the final disconnected scan again showed all five boards.
167
+
168
+
The iPad's isolated harness was terminated and removed after its receipts,
169
+
checkpoint files and signed archives were retained. The original TestFlight
170
+
application remained installed and was brought forward without terminating it.
171
+
The separate Lenovo production-entry candidate remains available for review;
172
+
its test draft and board test file were cleared as described above.
| Confirmed cause | Workspace contained exactly the intentional invalid-media fixture from the earlier qualification run; firmware correctly refused mounting and withheld BLE agent startup |
13
+
| Result | Verified pre-test workspace restored; native scan subsequently shows all five boards including `PyBLE-8C9E`|
14
+
| Firmware | Existing PyBLE 0.6.1 retained; no application, bootloader or partition-table update |
15
+
| Evidence | Ignored `local/recovery-implementation/`: startup trace, fresh backups, hashes, restoration log, offline inventory and five-board UI XML |
16
+
17
+
## Diagnosis and preservation
18
+
19
+
Source inspection established that there is no four-result limit. The adapter
20
+
filters only by PBLE service UUID, the accumulator retains distinct OS device
21
+
IDs and the UI renders the full result count. Pico 2 W (`3DCB`) was present.
22
+
23
+
Serial ownership was free. Short UART captures saw only the ROM boot; a longer
24
+
45-second controlled capture reached the workspace recovery message, then the
25
+
MicroPython 1.28.0 / PyBLE 0.6.1 banner and REPL. This is the intentional
path, rather than evidence of unsupported silicon or a scan-list cap. The
28
+
complete read-only media scan explains the delayed startup message.
29
+
30
+
A 115200-baud ROM read established that the installed first 256 KiB matches the
31
+
retained c8f549ee candidate image prefix at flash offset 0x1000. An earlier
32
+
460800-baud attempt had framing errors; no write was attempted at that speed.
33
+
Only prefix correspondence is claimed, not an independently read whole-image
34
+
hash.
35
+
36
+
The fresh **entire 2 MiB workspace** exactly matched the earlier refusal fixture:
37
+
first 8,192 bytes `0x00`, remainder `0xFF`. This proves the current region contains
38
+
the synthetic test fixture rather than a new user filesystem. The earlier run
39
+
failed after that test and never produced its planned erased-media/recovery
40
+
receipt. That leftover test state should have been restored before handback.
41
+
42
+
| Preserved or prepared input | SHA-256 / validation |
43
+
|---|---|
44
+
| Fresh current workspace backup |`cc5fcfcad390f42a5f7b0603f08f0142e9d0618c3ac102cb2ffab08722626ee1`; 2,097,152 bytes, exact equality with retained fixture |
45
+
| Immutable original full owner backup |`2aa2280b9fa0d66bbd60e73d0858e8df62f8025aa1e93f1c900ea86eb36aca3e`; rehashed before extraction |
46
+
| Original valid workspace extraction |`33490a100808d7fc89854d079bfa072e53ee0d48a80aa2ce8cd895ca643a0f37`; same 2 MiB region and identical partition geometry |
47
+
| Offline original-workspace inspection | Explicit LFS2 mount on a copied buffer; one empty diagnostic `.pbltmp` file, no user programs or boot scripts; original bytes unchanged |
48
+
| Existing NVS region | Erased in the captured image; workspace restoration does not restore old autorun settings |
49
+
50
+
The offline reader (`littlefs-python` 0.19.0) was installed only in an ignored
51
+
inspection environment. Its buffer was mounted explicitly without formatting;
52
+
no board or immutable backup was changed during inspection. It is not an app
53
+
or firmware dependency.
54
+
55
+
## Controlled restoration and result
56
+
57
+
The explicit operator restoration wrote **only flash 0x200000–0x3fffff**, using
58
+
the verified original workspace extraction. Both current and original backups
59
+
remain preserved. The operation restored the board from synthetic test data to
60
+
its valid pre-test workspace; it did not format unknown owner data or install a
61
+
new firmware image.
62
+
63
+
The flash tool reported `Hash of data verified.` before its normal reset. The
64
+
next native Lenovo scan included `PyBLE-8C9E` at approximately −45 dBm and
65
+
reported **Boards seen: 5**. The other four advertisements remained present.
66
+
67
+
```mermaid
68
+
flowchart LR
69
+
FIXTURE["Invalid test fixture left on board"] --> REFUSE["Workspace mount refused"]
70
+
REFUSE --> OFF["BLE agent not started"]
71
+
OFF --> FOUR["Four boards visible"]
72
+
BACKUP["Fresh backup and verified original workspace"] --> RESTORE["Restore workspace region only"]
73
+
RESTORE --> MOUNT["Valid LFS2 mount"]
74
+
MOUNT --> ADV["8C9E advertises again"]
75
+
ADV --> FIVE["Five boards visible"]
76
+
```
77
+
78
+
## Future qualification handback
79
+
80
+
After intentional invalid-media or interrupted-install tests, retain the actual
81
+
failed evidence and explicitly restore or hand off the disposable board state.
82
+
A completed host report does not prove that the physical board is ready for
83
+
ordinary use. Verify normal startup and advertisement, and record remaining
84
+
work before disconnecting the bench. Do not run old destructive qualification
85
+
collectors as a recovery shortcut or silently format a nonblank workspace.
0 commit comments