1030 Commits (17e694caedcdfd9cd15dbc02b739cbf51e9d4f32)

Author	SHA1	Message	Date
diffwireauto	17e694caed	fix(#1079): scroll long menus and keep links tappable beside mentions ... #1075: the contact, channel, message and channel-sender menus were plain Columns in a sheet capped at 9/16 of the screen, so items past the cap were clipped. A room server's Delete Contact was unreachable on an iPhone. They now scroll, and the sheet can grow to the safe area. #1074: a message with an @mention or contact card was built as rich text whose plain segments were never linkified. Those segments now go through LinkifySpan with the same options, style and confirm dialog as Linkify. Three new widget tests fail without the fix and pass with it. Epic #1078. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	1 week ago
diffwireauto	adce54be1c	fix(#1052): give iOS a way out of a channel ... iOS has no system Back. The chat had a hamburger in place of the back arrow, PopScope(canPop: false) switched off the edge swipe, and the keyboard covered the bottom bar with nothing to dismiss it. Add a back arrow to the channel and the line-of-sight map, keep the edge swipe on pushed screens on iOS, and dismiss the keyboard by tapping the channel's messages or dragging either chat's list. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2 weeks ago
diffwireauto	c3da9d7541	fix(#1050): the app name is Offband MeshCore everywhere ... The rebrand wrote Offband Meshcore, against the owner's capitalization. Launcher label, title, strings, notifications, window titles, web, release titles and docs are corrected. ProductName in Runner.rc deliberately keeps the old spelling: path_provider builds the Windows data folder from it, so changing it would orphan every Windows user's data. Bundle IDs, past release texts and the certificate subject are unchanged. Epic #1014, Feature #200. Agent: ChartreuseBay (session 425e424d) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2 weeks ago
diffwireauto	98f36a2397	feat(#1051): hide Donate and the Experimental section on iOS ... Owner decision for the first App Store submission. Guideline 2.5.19 bars hidden features, and a personal sponsorship link is an unclear fit. With no unlock on iOS, CoreScope is unreachable there, so the privacy label becomes Data Not Collected, and the notes no longer need the disclosure. Other platforms are unchanged. Epic #1014, Feature #200. Agent: ChartreuseBay (session 425e424d) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2 weeks ago
diffwireauto	ccc59ccbd5	fix(#1048): hide the Google Play link in About on iOS ... App Store guideline 2.3.10 bars naming other marketplaces in an app. Other platforms keep the link. Epic #1014, Feature #200. Agent: ChartreuseBay (session 425e424d) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2 weeks ago
diffwireauto	4b9da631f5	fix(#1033): tell the user when a Bluetooth scan cannot start ... On Android 11 and below the BLE plugin refuses to scan while system Location is off. The Scan button caught that error and only logged it, so the user saw nothing; one tapped Scan 172 times. A failed scan now shows a persistent message: a specific one when Location is off, a plain generic one for anything else, never the raw exception. The detail still goes to the log, and Scan stays pressable. New owner-approved strings scanner_scanFailedLocationOff and scanner_scanFailedGeneric; other locales fall back to English via untranslated.json. Tests: each message present on its failure, absent on success, still shown after 10 s, and Scan retries after a failure. Each check was made to fail first against a broken build (persist false; log-only; misclassification). Plan by EmeraldBrook on #1033. Agent: BrightDog (session 38fb0e08) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2 weeks ago
diffwireauto	d469fd502e	fix(#1030): act on the Gemini review of the app-only settings ... Route into the app on return from settings only when the scanner is the current route again, the same condition the connection listener uses. A popping route is outside the navigator's present set, so the settings route does not block it. The share tests now wait frame by frame on their own condition instead of a fixed 2-second window, and the persistence checks were re-proven to fail with persist: false. Correct a stale comment: the Experimental unlock is on the Device Info Build row, not About. Agent: BrightDog (session 38fb0e08) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2 weeks ago
diffwireauto	92a9cd75a2	feat(#1030): reach Share logs and About from the connect screen ... A radio that will not connect is exactly when a user needs the log, and the only way to it ran through device Settings, which needs a connected radio. The scanner now has a settings icon that opens an app-only settings screen: App Settings, Debug (Share logs, the logging switch, both log viewers) and About. Navigation only. How logs are written is untouched: Share logs calls the same LogExport.shareLogs the log screens use, on the same on-disk file. The device Settings screen keeps every category. Its About pane and the app-level Debug rows moved into AboutView and DebugLogTiles, which both screens now share; Device CLI, Serial capture and Mesh topology need the radio and stay in device Settings only. Export failures now persist until dismissed and are logged: "No log available to export" was a 4-second snackbar, and a share or save that threw had no handler at all. New owner-approved string: debugLog_exportFailed. Other locales fall back to English per untranslated.json. Tests pin both sides with the radio disconnected: Share logs hands the on-disk file to the share sheet, About shows the version, no device category or radio row appears, both error messages persist, and device Settings still has everything. Each check was made to fail against a deliberately broken build first. Part of Epic #693. Agent: BrightDog (session 38fb0e08) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2 weeks ago
diffwireauto	15754624d5	fix(#999): offer the companion CLI console only on a 1.18 radio ... The companion "CLI console" entry was gated only on the target being a companion. A pre-1.18 radio, including Offband before the absorb, refuses a type-3 send: companion-v1.17.1 CMD_SEND_TXT_MSG accepts only plain and CLI_DATA and answers anything else with ERR_CODE_UNSUPPORTED_CMD (companion-v1.18.0 adds CLI_COMMAND). The connector only logs error frames, so the command waited out its mesh timeout and the console showed the #891 row, which blames the target for a limit of the user's own radio. - Gate: DeviceCliScreen.offersRemoteConsole requires a companion target AND a connected radio that speaks the 1.18 CLI (allowsCliFrame, the same check that gates the local Device CLI; type-3 send and frame 66 shipped together in 1.18). Disconnected or unclassified offers nothing. The chat menu uses it. - Fail fast: RemoteCliTransport fails the command at once with CliConsoleUnsupported when the radio refuses the send. The window arms only when the text frame is written (the onAttempt hook, after the path update) and closes on the command's SENT, which on 1.18 carries an expected-ack of 0. So an unrelated unknown-command refusal before the write, or a DM's SENT, cannot be pinned on this command. Dispose releases a command still waiting. - Console: a refused send shows "<command>: not sent. Your radio's firmware doesn't support remote CLI." (owner-approved), not the timeout row. Tests: the gate (positive and negative across populations, roles, and disconnected); fail-fast on the refusal, ignoring other codes, errors after the radio accepted the send, a DM's SENT, an error before the write, and dispose; the console row. Reviewed by a one-off Sonnet adversarial pass (Gemini budget down). Its Medium finding, that the window armed at run() before the write, is fixed here. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2 weeks ago
diffwireauto	63c345e042	feat(#891): explain a remote CLI command that gets no reply ... A companion that has not granted us remote CLI queues our command as a plain message and never answers, so from the console's side the silence is as likely a permission answer as a lost packet. The console showed the same bare "no reply in N s" row it uses for the local device, which reads as "the radio is down". The remote console now shows: "<command>: no reply in N s. This radio may not allow remote CLI from you, or is unreachable. Not retried." The local console keeps its plain frame-timeout row. The send itself was already a single attempt (#999), so "Not retried" states what happened. - device_cli_screen: the timeout row picks the remote string when the console targets a contact. A transportOverride test seam lets a test drive a deterministic timeout; the screen owns and disposes it. - l10n: deviceCli_remoteNoReply (owner-approved wording). Tests: the remote timeout renders the full interpolated string; the local timeout renders its exact string and never the remote permission hint. Reviewed by a one-off Sonnet adversarial pass; its test gaps are fixed. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2 weeks ago
diffwireauto	3e40979e94	feat(#999): remote-CLI console for a companion, kept out of chat ... Extend the one CLI console (device_cli_screen, F2 #883/#884) to target a permitted companion over the mesh (TXT type 3, #888/#889), reusing the console rather than adding a screen or a chat-borne command path. Opened from a "CLI console" action on a companion contact; command and reply both live in the console. - cli_console_transport.dart: CliConsoleTransport with a local and a remote implementation, and one CliConsoleTimeout the console catches. The remote transport sends with retries: 1 (no auto-retry - an unpermitted companion queues the command and never replies, so a retry only spams the mesh) and correlates the reply via the receivedFrames listener, gated to CLI_DATA so a chat message or inbound command from the same contact can't complete it (Sonnet review). - device_cli_screen: optional remoteContact; "Remote CLI" + contact name. - chat_screen: companion-only "CLI console" entry (Contact.isCompanion). Also corrects #890: CLI and chat are separate surfaces. The receive pipeline filed every contact frame into the conversation regardless of TXT type, so a companion's CLI reply (type 1) and an inbound command (type 3) leaked into the chat thread. A guard now drops CLI-typed messages from the message pipeline - the console is their only surface - and #890's in-chat command bubble is removed. Review (Sonnet, one-off, Gemini budget down): redact secret reply text in the remote path's late/unmatched log, matching LocalCliService; dispose cancels the subscription; document that remote truncation is not detectable post-reassembly. Tests: transport round-trip / sender-filter / timeout / no-retry / CLI_DATA gate; Contact.isCompanion; remote console title; and the pipeline keeping CLI (type 1 and 3) out of the conversation while a plain message still enters. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2 weeks ago
diffwireauto	bd6b578136	feat(#890): accept and render inbound remote-CLI commands ... Upstream 1.18 lets a permitted contact send a remote-CLI command (TXT type 3) to run on our radio. Before this, _parseContactMessage only knew plain (0) and CLI_DATA (1), so a type-3 frame was warn-dropped as an unknown type and never surfaced. - meshcore_connector: accept txtTypeCliCommand in _parseContactMessage, skip SMAZ decode for it (like CLI_DATA), and flag the Message isCliCommand. Add @visibleForTesting parseContactMessageForTest. - message model: new isCliCommand field threaded through the constructor and copyWith. - message_store: persist and read isCliCommand; skip SMAZ on read for it. - chat_screen: label an inbound command bubble "Command for your radio" and exclude it from the incoming-translate action. - l10n: chat_remoteCliCommand. test/connector/inbound_cli_command_test.dart: type-3 accepted+flagged, type-1 isCli-not-command, plain-neither. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2 weeks ago
diffwireauto	d476734aac	feat(#889): route CLI to companions by target role ... F3/E3.1 target split. The command service now picks the message type by the target contact's role: a companion (chat) gets TXT_TYPE_CLI_COMMAND (type 3), a repeater/room server keeps the universal CLI_DATA (type 1) it has always used. One line in the send path; the reply handling, correlation and timeout model (which already carries the 600 ms companion reply hold) are unchanged and serve both. Companion replies come back as CLI_DATA (verified: MyMesh.cpp companion), so the existing contact-agnostic reply listener routes them to handleResponse unchanged; a UI entry point to open the CLI console for a companion is the remaining downstream piece. Tests: a real send proves companion -> type 3 and repeater -> type 1, driven deterministically off the send frame. Full suite green (1432); Gemini review: test race fixed, the reply-path concern refuted against the source-verified CLI_DATA reply. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2 weeks ago
diffwireauto	0f0c34b054	feat(#888): role-based CLI txt-type selection for remote CLI ... F3/E3.1. When sending a CLI command to a remote peer, the message type is chosen by the contact's ROLE (owner ruling): a companion (chat) gets the upstream-1.18 command type (3); a repeater or room server keeps the universal CLI_DATA type (1) it has always used. Decided by role, not firmware version: a Contact carries no version, the user types the commands (passthrough), and a non-1.18 companion silently drops the command type (surfaced as no reply, #891). Adds txtTypeCliCommand (3) and cliTxtTypeForContactType(), and parameterizes buildSendCliCommandFrame with the txt type (default CLI_DATA, so the existing repeater path stays byte-identical). A later refinement could pin a peer's version via a `ver` probe on connect. Tests: the role mapping and the frame's type byte + command passthrough. Full suite green (1430); Gemini 2.5-pro review: one naming nit taken. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2 weeks ago
diffwireauto	8017ce4baf	feat(#887): contact remote-CLI permission toggle (flag 0x10) ... F3/E3.1. Upstream 1.18 gates remote CLI (TXT type 3) on contact flag 0x10 (isRemoteCLIAllowed): the receiving radio checks it, so setting it on a contact grants that contact permission to run CLI on this radio. Adds the constant, Contact.remoteCliAllowed, a remoteCli param to setContactFlags (same set/clear pattern as the telemetry flags, reading a fresh device snapshot first), and an opt-in SwitchListTile in the shared contact settings dialog (default off). Written with the existing add/update-contact frame; the flags byte already rides it. Tests: the 0x10 bit on the write-path frame (set/clear/coexist) and the getter. Full suite green (1424); Gemini 2.5-pro review: no defects. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2 weeks ago
diffwireauto	2984ece46c	fix(#997): make a connect wait for a disconnect still in progress ... Owner test 2026-10-26: Stop, then a BLE connect to another radio 6 s later. The Stop disconnect was still releasing the T1000-E; every connect path only refused connecting and connected, so the new connect started during disconnecting. The disconnect's tail then cleared the new link's device, name and state: the status stuck, and the frame size stayed at 20 bytes with MTU 176, which left the channel composer unusable. - disconnect() tracks the one in progress; a connect (BLE, USB, TCP) waits for it, and a second disconnect joins it. A manual caller joining an automatic disconnect still suppresses the retry. - A superseded attempt logs its own radio's name, not whatever name the newer connect has written by then. Watched failing first: the TCP connect started before "Disconnect complete". Full suite 1720 pass, analyze clean. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	3 weeks ago
diffwireauto	5fb3286134	fix(#997): bound the BLE auto-reconnect and let the user take over ... On 2026-10-25 the client retried an unreachable T1000-E about every 14 s for 7.7 hours, and no other connect could start meanwhile (#995). - connect() reset the attempt counter at the start of every automatic attempt, so the backoff never grew and nothing gave up. A ReconnectPolicy now owns the count: 5 attempts or 3 minutes, and only a user connect, a manual disconnect or a successful link resets it. - A connect the user starts, BLE, USB or TCP, abandons an automatic attempt in flight instead of being refused. A generation check after each await in the BLE connect stops an abandoned attempt before it writes shared state. - Refusals are logged and shown, never silent (the USB screen dropped taps without a trace). - The scanner status bar shows the attempt with a Stop button, and "Couldn't reach" with Retry once the retry gives up. Tests watched failing first: the attempt count (1, expected 2), the give-up, the TCP refusal, the silent BLE refusal, and the three screen cases. Full suite 1719 pass, analyze clean. Epic #996, design on #995. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	3 weeks ago
diffwireauto	6678700e78	fix(#985): decode channel hop counts from the packet, not the byte length ... Three defects turned a 13-hop 3-byte-hash message into a 39-hop badge: - log-RX ingress stored the width-stripped hop count; now stores the raw packed path-len byte, the same encoding fromFrame keeps - the repeat merge substituted the path BYTE length into the packed field; mergePathLenRaw now compares decoded hop counts and never sees a byte length - fromFrame read the V3 path_len field signed, so 3-byte-width values (>= 0x80) collapsed into the flood sentinel; now unsigned with 0xFF kept as the direct marker Rendering now groups path hashes by the packet's own declared width (ChannelMessage.effectivePathHashWidth), with the radio's device-wide mode only as the legacy fallback, so the path screen, chat via-line and route-reply all agree with the badge. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	3 weeks ago
diffwireauto	72241b1adf	fix(#750): keep a custom name from following a switch to another radio ... _customNames was only ever added to. Rename contact X on radio A, switch to radio B which also holds X, and B showed A's label, breaking the owner's decision that custom names are per radio. - The hydrate clears the map before loading the connected radio's names. - disconnect() clears it with the contact list, so no label outlives the link it belongs to (Gemini finding). T37 (switch) and T37b (disconnect) both failed with the previous radio's "Chuck" before the fix and pass after. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	3 weeks ago
diffwireauto	b6ea54e146	fix(#750): stop a rename leaking to other operators when sharing a contact ... Found by the pre-PR adversarial gate, which earned its keep: this is the worst instance of the exact leak the epic exists to prevent, and I had missed it. toShareUri and toChannelShare both read the .name getter, so sharing a renamed contact put the user's private label in the payload. A share payload becomes the RECEIVED name on every device that imports it, so the label would land as another operator's ground truth and overwrite a signed advert name. Worse than sending it to our own radio, because it propagates outward instead of stopping at one device. Both now send receivedName. The static build helpers keep their name parameter, since the device also shares its OWN name through them with no Contact involved. KNOWN LIMIT now documented in the guard, because the near-miss matters more than the fix. T14 matches the pattern name-colon-identifier-dot-name, so it structurally CANNOT see an intra-class read, where the getter is reached as a bare name with an implicit this. That is precisely where this bug was living. Reverting the fix was confirmed to leave T14 green while T36 failed, so the limit is measured, not assumed. Widening the regex to catch a bare name is not possible without flooding on the legitimate parameter pass-through in the same file, where the static helpers forward a name argument correctly. So cross-class reads are guarded by T14, intra-class reads behaviourally by T36 and T11, and contact.dart joins the watched list for the cross-class case. Three tests added. T36 falsified before being trusted. Gates: analyze --fatal-infos --fatal-warnings clean, dart format 0-changed, 1505 tests passed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	3 weeks ago
diffwireauto	f2cf677893	feat(#750): declare the custom-name key in the scoping inventory ... The rebase brought in Feature #853's scoping gate, which requires every storage key in lib/ to carry a per-radio or global verdict with a reason. contact_customname_ was undeclared, so the gate failed the build. That gate did its job: a new key cannot land unnoticed. Declared per-radio, prefix + device key + contact key, matching its neighbour in the same store. The reason records why it is not in contact_store, since that is the decision most likely to be undone by someone later: contact_store is rebuilt from radio contact-sync data, so a save after a sync would wipe the rename. Also renames the fixture arg in #940's radio_isolation_matrix_test, which the 750.1 compile break caught the same way #754's test was caught two rebases ago. Gates: analyze --fatal-infos --fatal-warnings clean, dart format 0-changed, 1502 tests passed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	3 weeks ago
diffwireauto	d1ed88d460	feat(#750): let the user rename any contact, stock parity ... Task 750.4 of the contact-naming plan: the UI. Rename sits on the per-contact sheet, above the destructive Block tile, and the sheet shows what the node calls itself whenever a custom name is set. The dialog shows the node's own name at the moment of the decision, and only while it differs from what is typed, so the user can see the name they are overriding without having to remember it and the same string never appears twice. It also says plainly that the rename is local and that adverts keep the node's own name up to date, so nobody has to guess what renaming costs them. Empty and whitespace-only are normalized to a clear in the dialog as well as in the connector and the store. Three layers enforce it independently so none is load-bearing and the dialog never hands a blank downstream to be cleaned up. A 32-character cap keeps tiles readable. Counted in characters, not bytes: a custom name never crosses the wire, so #636's grapheme truncation does not apply and a byte cap would mean 'shorter for CJK' for no reason. Thirteen tests. T29 and T30 came from the pre-PR review and I had them wrong first: they accepted an empty string, which IS the defect the review found, so they would have passed against a broken save path. Tightened to assert null strictly, then falsified: reverting the normalization makes both fail where before they passed. Gates: analyze --fatal-infos --fatal-warnings clean, dart format 0-changed, 1335 tests passed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	3 weeks ago
diffwireauto	d9c356a4a4	feat(#750): reattach the custom name wherever a Contact is rebuilt ... Task 750.3 of the contact-naming plan. The custom name lives in contact_settings_store keyed by pubkey, not in contact_store, so the live Contact objects have to be reattached to it. Two paths drop it otherwise, and both fail silently. Cache hydrate rebuilds every Contact from contact_store, which does not hold the custom name on purpose, so a restart would lose every rename the user made. Radio contact-sync replaces an existing Contact with one built from the device frame, where no custom name exists. Adds a _customNames map as the in-memory mirror, _withCustomName to reattach, and _loadCustomNames to batch the load. Batched for the reason already documented on the cyr2lat loader: a notify per contact rebuilds the tree twice per contact and each rebuild walks the contact list. Applied at five sites: cache hydrate and the four contact-sync rebuilds. Paths that copyWith from an EXISTING contact need nothing, because copyWith preserves customName unless clearCustomName is passed, which is why the advert handler from 750.1 already behaves. setContactCustomName is the write path. Null, empty and whitespace all clear, matching Contact.name and the store, so a user who deletes the field's text cannot end up with a blank name and no way back. Eleven tests. T35 was falsified before being trusted: dropping the hydrate mapping made it fail alone. T16 to T22 guard behaviour 750.1 already delivered and passed on arrival, so they are regression guards rather than watched failures, and the file says so. Gates: analyze --fatal-infos --fatal-warnings clean, dart format 0-changed, 1324 tests passed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	3 weeks ago
diffwireauto	1a3ab19a12	feat(#750): keep the user's label off the wire and out of exports ... Task 750.2 of the contact-naming plan: the radio boundary. The radio's contact table is the shared record of what a node calls itself, and firmware has a single char name[32] per contact with nowhere to put an override, so a private label must never reach it. This was the hole the type system cannot see. After 750.1 renamed the field, every frame-builder call site still read .name and compiled, which meant they were silently sending the custom name. T11 demonstrated it live before the fix: the custom name was present in the emitted frame bytes. Four connector sites and the stock config export now send receivedName. The export matters for a second reason: a stock config file is an interchange format other operators import, where a name reads as the node's own, so exporting one user's label would hand it to everyone who loads the file. T14 is a source-reading guard, because nothing else can hold this. It fails if any watched file passes a Contact display name into a name field, and separately if the frame-builder call-site count changes. Its allowlist is keyed by path, not by line content, so an exception in one file cannot excuse the same line in another. Correction to the plan's own count: analyze caught that stock_config_import_service reads a StockContact parsed from an imported file, not our Contact, so that site was never wrong. The real number of Contact-typed write sites is eight, not the nine recorded on #750. The reason is in the code and in the guard's allowlist. Eight tests. T11, T33 and T14 were each falsified before being trusted: reverting the export line alone failed both T33 assertions and the source guard independently. Gates: analyze --fatal-infos --fatal-warnings clean, dart format 0-changed, 1313 tests passed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	3 weeks ago
diffwireauto	3a0ad8f273	feat(#750): separate what a node calls itself from what the user calls it ... Task 750.1 of the contact-naming plan: model and storage. Stock MeshCore has a per-node CUSTOM NAME field and keeps the original underneath; Offband could not rename a contact at all. Contact gains receivedName (the name the mesh gave us, wire and storage) and customName (the user's label, client-side only). name becomes a getter returning customName ?? receivedName, so all 85 existing display reads stay correct and a future read cannot forget. Empty and whitespace-only custom names count as unset at both the getter and the store, so clearing the field cannot leave a contact blank with no way back. The constructor and copyWith take receivedName, which made the rename a compile error at every write site. The compiler enumerated 23 of them across 5 lib files and 11 test files; none was found by reading. The advert handler is the one that matters: receivedName now updates while customName is untouched, so an advert improves accuracy without moving what the user sees. That was the defect making a client-held name impossible. customName is deliberately NOT in contact_store. That record is rebuilt from radio contact-sync data where no custom name exists, so a save after a sync would wipe it. It lives in contact_settings_store keyed by pubkey hex, which a sync cannot reach. Both stores persist receivedName, never the getter. The plan's correction on #750 found that persisting the getter is one-way data loss: the custom name would be read back as the received name and the real one destroyed with no advert able to restore it. The ?? 'Unknown' fallback is kept with a comment, since the rename is exactly the edit that drops a trailing fallback and would crash the load for a legacy row. 19 tests, positive and negative. T31 and T32 were falsified before being trusted: breaking the persist and the fallback made exactly those two fail and nothing else. Gates: analyze --fatal-infos --fatal-warnings clean, dart format 0-changed, 1305 tests passed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	3 weeks ago
diffwireauto	b50d4a73f9	fix(#850): live adverts feed discovery only, not the contact list ... A long-lived session drifted hundreds of contacts above radio truth (#838): the client promoted every overheard advert into the persisted contact list using only the radio's auto-add type policy, applying neither the radio's hop limit nor its capacity, and ignoring its eviction/full pushes. The firmware fires NEW_ADVERT (0x8A) and the raw RX firehose (0x88) even for adverts it rejects, so those became phantom contacts the next manual sync had to prune. Option A, sync is truth: the persisted contact list is populated only by the contact sync stream. Both live-advert paths now feed discovery only; a new advert whose type the radio would auto-add nudges a debounced incremental reconcile so a contact the radio actually stored still surfaces without a manual sync, while one it rejected simply never returns in the stream. The existing-contact path/GPS refresh and the reconnect full-sync prune are unchanged. The reconcile debounce (and the sibling channels-changed debounce) is cancelled on both disconnect paths so a timer scheduled against one radio can't fire against the next (pre-PR Gemini review finding). Epic #842. Build #850. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	3 weeks ago
diffwireauto	820258471f	fix(#970): act on the adversarial review, cite the merged firmware ... No preview is sent while a slot transfer runs, so neither can take the other's refusal. A final SLOT_SET reply that is not 0 is no longer read as a commit. Back during a read or save now says why it is held. Comments now cite meshcore-firmware f3d30a88 on firmware-base, which merged 3e788e2a with the contract files unchanged. The wider attribution fix is #991. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	3 weeks ago
diffwireauto	f651b3d79d	feat(#970): say when RTTTL defaults are out of order, and fix them in one tap ... The badge's player reads d=, o=, b= positionally, in that order, so RTTTL from elsewhere that lists them otherwise (owner's Take On Me: o=5,d=8,b=160,b=160) is refused as a stray colon, and firmware's 21-column words do not say why. When the header is the only fault, the editor now says the badge reads d=, o=, b= in that order, each once, and offers Fix order. The fix refuses to pick between two different values for one key, and must itself pass rtttlProblem, so it never hides a second problem. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	3 weeks ago
diffwireauto	1827308339	feat(#986, #970, #971, #987): badge tones and screen settings parity over 0xC5 ... Builds the owner-approved parity design (docs/initiatives/standalone/975-settings-restructure/tones-screen-parity-mockups.html) against meshcore-firmware 3e788e2a: - #986: the six event tones (DM, Channel, Room, New contact, Ack, Sent) on Buzzer and tones, one shared picker with a play button per row (0x0F/0x10/0x11). DM is one tone for every direct message. - #970: all eight custom slots listed; the editor reads the stored tune back (0x12), checks typing with a port of firmware's rtttlProblem(), and saves in transport-sized chunks (0x0A), restarting once if displaced. - #971: Radio tone in the channel sheet and chat menu, Default naming what it plays. - #987: Screen (text sizes, Screen off, time zone with a phone-matched suggestion) and Battery (full point, set here, back to auto) under Node Settings, gated on caps2 0x40. Caps2 0x10 is now TUNES (slots, channel tone, event tones, preview). Also corrects the mockup's zone count: 40 zones plus not set. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	3 weeks ago
diffwireauto	317ce17437	feat(#981): channel tune codec over 0xC5 0x0B/0x0C ... Codec and connector for per-channel tune (#971), gated on caps byte 2 0x10 per meshcore-firmware#1789. ChannelTune makes inherit (stored 0) and Silent (tune id 0, stored 1) distinct values with the byte never built by hand, because collapsing them is unrecoverable from the user's side. Per-channel state follows only the device's re-read reply, a refusal is attributed to the channel-tune surface, and a new radio clears the previous one's tunes. No UI yet: the picker waits for an owner-approved mockup, and for the tune catalogue (builtin ids and names), which is not on the wire. Agent: MistyLynx (session 6c0d5797) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	3 weeks ago
diffwireauto	bf47a26155	feat(#978): split Button and buzzer into Node Settings and Message Settings ... Button actions stay under Node Settings, shown only on caps byte 2 0x02. Buzzer and tones move to Message Settings as their own card under the phone-notifications card, shown only on 0x01. DeviceUiView now renders one part, requests only that part's state, and shows a refusal only on the screen it belongs to. Boards with a buzzer and no button exist (m5stack_unit_c6l, thinknode_m9, wio-tracker-l1-eink), which is why the homes are separate. Placement and entry gates only: the screen already showed each half from its own bit, and every wire write is unchanged. The Buzzer and tones subtitle says 'When this radio beeps' rather than the mockup's 'and which tone', because no tone picker exists until #971 and #970. Tests: all four button/buzzer combinations, and that each entry opens and requests only its own half. Full suite 1506 pass. Agent: MistyLynx (session 6c0d5797) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	3 weeks ago
diffwireauto	4209b75284	feat(#969): GPS mode and Power-save interval over 0xC5 ... Codec for 0xC5 sub-codes 0x0D/0x0E, gated on caps byte 2 0x20, per the contract on meshcore-firmware#1789: the 14-byte state reply (resolved mode, raw stored byte incl. 0xFF, ps_ok, activity, 32-bit interval and wait), extended in place in offband_device_ui.dart and the existing 0xC5 dispatcher rather than a second codec. Caps bits 0x10 channel tune and 0x20 GPS mode added beside the others. On a 0x20 radio the Location GPS card is the approved one Off / On / Power save control, one status row naming backed off with its wait and last fix, and a sleep row only in Power save where 0 reads as the firmware default. Power save is offered only where ps_ok says the build can run it. Every value shown is the device's reply. Other radios keep the #977 on/off toggle unchanged. Safety: a mode change resends the radio's own interval, so setGpsMode refuses visibly until state has been read rather than send an interval it does not know. The 0x7F error frame names no sub-code, so a refusal is attributed to the outstanding write and each screen shows only its own. A confirmed mode keeps the legacy gps custom-var mirror, and so the 0xC1 poll, in step, but never invents the var. Tests: codec, connector (gate, bytes, attribution, mirror) and screen. Full suite 1499 pass. Agent: MistyLynx (session 6c0d5797) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	3 weeks ago
diffwireauto	2a6d7383fc	feat(#977): Location is a top-level settings category and the only home for GPS ... New LocationView pane directly under Radio Settings: the GPS toggle and the 0xC1 GPS status, then Coordinates and Position reporting interval as rows that open their own editors. The GPS toggle and the Location row leave Node Settings, and the combined Location dialog is gone, so GPS appears in exactly one place. What the radio sees is unchanged: the same gps and gps_interval custom vars, the same 60 to 86399 s validation, the same error messages. One deliberate difference: coordinates and the interval now save independently. The old dialog returned early on an empty or invalid interval and silently skipped saving the coordinates too. Tests: settings_location_test pins placement from both sides and the writes. Two existing settings tests now scroll a category into view before tapping it; the lazily built category list put Debug past a 900 px viewport once Location was added. untranslated.json is a full regeneration and also picks up two block_noRadio keys dev was already missing. Agent: MistyLynx (session 6c0d5797) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	3 weeks ago
diffwireauto	5b061924c7	feat(#966): mock-ups, a confirmation that states the scope, and the eligibility bug it found ... The owner asked why there were no UI mock-ups to review. There was no good answer: this Epic's card was built and installed on both his machines without him ever seeing the design, and the plan had no step requiring otherwise. So the plan now has B0: mock-ups first, owner-approved before any of it is built, as a committed HTML file beside the plan in the format his firmware initiative already uses. epic-b-storage-mockups.html is that file: eleven numbered variants with real Material 3 tokens, a 360-wide pane, example values from his own install, and the behaviour to build as bullets under each. Owner-approved 2026-10-23. The confirmation (B1a, variants 8 to 10). It states how many copies, roughly how much space, how many messages are NOT affected, and that it cannot be undone, with the count on the action button so the scope is the last thing read. Cancel, a tap outside and back all decline. Nothing eligible opens no dialog at all, because a dialog that only says zero is not worth opening. That needed a preview pass: verify every eligible key and total it without deleting, so the numbers are real rather than estimated. Verification now runs twice for a confirmed clear, once to preview and once under the key lock. That is the cost of saying what will go before it goes. approximateBytes is named for what it is: the sum of blob lengths, not what VACUUM returns, because page rounding moves the real figure; the dialog says "about" and the result reports what actually changed. Writing the preview found a real bug, and it was about to bite him. The "skip anything stamped this pass" guard exists so installing an update never deletes a blob on sight, and it was being applied to the button as well. Every install that migrated before #962 has an empty __msgrows_migrated_at, so the first press stamped everything and cleared NOTHING. His install is exactly that: 47 migrated keys, none stamped. He would have pressed the button on a 70.9 MB database with 16.6 MB of reclaimable blobs and been told "nothing to clear". Fixed as eligibleByAge, one static rule both preview and run share, so the dialog cannot promise what the sweep will not do. An explicit press includes newly stamped keys; the automatic sweep still refuses them. Three tests on the rule directly, plus one proving the automatic path refuses while the press clears. Label stays "Clear Stale History Now" rather than "Compact", owner's call and the better argument: the name generalises to clearing stale history for other reasons later, such as #963's retention limit. 14 widget tests and 34 storage tests. Full suite 1,502 pass, 1 skipped. analyze clean, format clean. Task: meshcore-open-gan Agent Mail: TealGlen Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	3 weeks ago
diffwireauto	3168c413c9	feat(#966): a durable audit of what the sweep deleted ... The owner asked whether the delete and compact are logged or silent. Checked rather than assumed, and the answer was bad on two counts: - A delete logged only a COUNT. "Cleared 40" names nothing, so there was no record of WHICH keys were reclaimed. Refusals were already logged properly, with the key and up to three missing records; deletions were not. - All of it goes through appLogger, which is gated on appDebugLogEnabled. That is off by default and off on his install, so on a normal install an irreversible delete left no trail at all. Both fixed. The summary now names the cleared and kept keys, and the sweep also writes a durable entry into the database itself, under __msgrows_reclaim_audit: timestamp, the cleared keys in full, the refused keys, and the byte counts either side. In the database because that survives restarts and the logging toggle, and can be read back without the app running, which is also how it gets verified on hardware. Key lists are stored in full. Truncating them would recreate the "Cleared 40" problem the entry exists to solve. Capped at the last 5 sweeps instead, which is generous given a key is cleared once and then has no blob to consider again, so this is close to a once-per-install operation. A failure to write the audit is logged and tolerated rather than failing the sweep: the deletes already happened and were each verified, so losing the record is worse than nothing but far better than reporting a correct sweep as broken. An unreadable audit likewise starts a fresh list and is logged, never silently replaced. scoping_inventory gained the key, globalOnPurpose: one sweep spans every radio and the entries name store keys that already carry the radio. Six tests: a sweep records which keys it deleted; the entry survives a fresh store object over the same database, so it is really on disk; refusals are recorded too; a sweep that did nothing writes no entry; the cap drops the oldest and keeps the newest; and an unreadable audit does not stop a sweep. Lands on Epic B's branch rather than Epic A's, where the sweep lives, to avoid restacking B over a changed A for a change that reaches dev through both either way. Origin is #965's engine. Full suite 1,489 pass, 1 skipped. analyze clean, format clean. Task: meshcore-open-gan Agent Mail: TealGlen Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	3 weeks ago
diffwireauto	cc2fb23b2e	feat(#966): Clear Stale History Now, with refusals reported ... Epic B of #962. The manual trigger for Epic A's sweep, so a user does not wait 30 days. It passes olderThan: Duration.zero, which skips the WAIT and not the safety: the per-key verification inside reclaimVerifiedHistoryBlob is unchanged, proved by a test that Duration.zero still refuses a key whose rows cannot be verified. Its own widget rather than another card in app_settings_view.dart, which is already past a thousand lines, and so the tests can drive it without standing up the whole settings screen. Stateful against the repo's usual StatelessWidget-plus-Consumer habit, because the running flag and the last result are local to this card and belong to no service. The sweep is INJECTED, and that is a finding rather than a convenience. The first version of the widget test called the real sweep and hung past ten minutes instead of failing: the sweep uses compute, and an isolate deadlocks pumpAndSettle inside flutter_test's fake-async zone. A widget test should test the widget. So the card takes the sweep and the size read as parameters, the nine widget tests feed outcomes in directly, and the two new tests in stale_history_sweep_test.dart keep the injected semantic honest under plain test() where isolates work. Owner decision 2026-10-22, and the reason this Epic exists: the button REPORTS keys it refused, it does not only log them. "Cleared 1 old copies, 16.0 MB returned" and "Kept 1 that could not be verified" are both shown, including when a refusal is the reason nothing was cleared, which is the most important case to surface rather than the least. The automatic sweep stays log-only. Two Gemini findings, both fixed: - A fast double tap ran two sweeps. The disabled button is not enough on its own, because setState only SCHEDULES a rebuild, so two taps inside one frame both see a live onPressed. _clear now returns early on _running, and a test taps twice in one frame and asserts the sweep ran once. Two concurrent sweeps would have meant two concurrent VACUUMs. - A throw after real deletes was reported as a total failure. The honest fix was in the sweep, not the string: a successful sweep must not become an error because the closing size read threw, so that read now falls back to bytesBefore, which understates the reclaimed figure rather than inventing one. The failure string no longer claims nothing happened either. Strings are English-only, as everywhere else here: gen-l10n falls back to the template locale, and untranslated.json records the 9 keys across 17 locales, which is what that tracked file is for. 29 tests in the two files, full suite 1,483 pass, 1 skipped. analyze clean, format clean. Task: meshcore-open-gan Agent Mail: TealGlen Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	3 weeks ago
diffwireauto	84c2dbd9da	fix(#965): act on the Gemini gate findings ... Three findings, all addressed. One was a real data-loss hole. 1. CRITICAL, fixed. missingFromRows trusted the converter's own output as the measure of the converter. A callback that silently dropped a record, rather than throwing, would have had every record it DID produce found present, returned "nothing missing", and the blob holding the only copy of the dropped one would have been deleted. The migration gate has always guarded this with an independent countJsonArrayElements in a separate compute; the verify path I added did not, which left the two halves of the same rule unequal. It now does the same cross-check and refuses as unverifiable on a mismatch. New test: a converter that drops its last row is refused with missing == null, not missing == []. 2. Measured, not redesigned. VACUUM takes an exclusive lock, and the review called it a UI freeze. It is not: drift_flutter runs SQLite in a spawned isolate (_isolateEntrypoint -> DriftIsolate.inCurrent, verified in the package), so database access queues behind it while the UI thread stays free. That is a stall on history-backed reads, not an ANR, which is the distinction that matters for an app whose storage work began as an ANR investigation. It is also close to once per install, since a cleared key has no blob to consider again. The duration is now logged, because 0.6 s on the owner's 70.9 MiB database is a number worth watching in the field rather than assuming. 3. Fixed, and the review was right about why. The non-history-key test asserted only that the isHistoryKey helper returns false, which would still pass if run() stopped calling it: the loop visits keys that HAVE rows, and contacts and friends normally have none, so they were never reachable anyway. Those keys now get a planted row and a 99-day-old timestamp, so the prefix guard inside run() is the only thing standing between them and a delete. Also carried over from the previous round: the check-then-delete window is closed by BlobStore.reclaimVerifiedHistoryBlob, which holds the per-key lock across both the verify and the delete and so also serialises the sweep against a migration or a blob merge on the same key. Two tests cover it, including that a second call on a blobless key reports neither a delete nor a problem, which is what makes a repeat sweep silent. On the owner's database 7 of 47 aged keys are in that state, having migrated through the empty-blob path. 18 tests in the file, full suite 1,472 pass, 1 skipped. Re-verified against a copy of the owner's real database after the changes: blob keys: 477, migrated history keys aged: 47 cleared 40, refused 0, 17362944 bytes returned (16.56 MiB) kept keys missing: 0, byte-changed: 0 integrity_check: ok, rows 29950 -> 29950 Task: meshcore-open-5vt Agent Mail: TealGlen Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	3 weeks ago
diffwireauto	1b38c674e4	feat(#965): per-key migration timestamps and the stale-blob sweep ... Epic A of #962. The engine only; the manual action is #966. A1 wrote the diagnosis as failing tests first, and they were red for the right reason: no sweep existed and six BlobStore methods did not. Also lands a control test asserting that DELETE alone does not shrink the database, which passes today and must keep passing, since it is the entire reason a VACUUM step exists. A2, the timestamps. A second blob, __msgrows_migrated_at, keyed by store key. Deliberately NOT a reshape of __msgrows_migrated: that marker is read on every save and every load through a cache, so changing its shape would put a migration of its own on the hottest storage path. Owner decision 2026-10-22. An install that migrated before this ships has no timestamp, so backfillMigratedAt stamps it on FIRST SIGHT and the sweep skips anything it stamped this pass: updating the app can never delete a blob on the spot, and every key gets the full 30 days measured from when we first knew about it. A3, the sweep. Eligibility is age plus a fresh verification, never the marker alone, which is the difference between "we recorded that this migrated" and "we just confirmed it". missingFromRows returns null for "could not tell" and an empty list for "verified nothing missing", and those are deliberately different values: collapsing them is how the only copy of an unreadable history gets deleted. A4, one VACUUM, only when something was deleted. A failure there is logged and tolerated: the deletes already happened and were each verified, so it costs space and not data, and the next sweep retries it. The comparison rule now lives in ONE place, _absentFrom, used by both the migration gate and the sweep. The gate still decodes its own blob, because a second compute over multiple megabytes on the migration path would cost more than the duplication saves, so the rule is shared even though the decode is not. Wired into main.dart's existing post-frame callback, beside the #906 exit-info collector, for the same reason: storage hygiene must never be on the path to a usable screen. The catchError sits at that fire-and-forget call site rather than inside run(), so #966's button still gets a failure it can report. scoping_inventory gained the new key, because the #853 gate caught it exactly as designed. Its verdict is globalOnPurpose for the same reason as the marker: it is keyed BY store keys that already carry the radio. 15 tests, the plan's whole acceptance bar: the 29-day and 30-day boundaries; one missing row refuses AND the same key clears once its rows are complete, which is what proves the gate discriminates rather than never deleting; an undecodable blob refuses; an unstamped key is stamped not deleted; an unmigrated key is untouched; contacts, discovered_contacts and path_history_ are asserted non-candidates BY NAME; a DM key sweeps through the DM converter; and every kept blob is byte-identical across the sweep and VACUUM with the row count unchanged. A5, verification against a copy of the owner's real database through the production sweep: blob keys: 470, migrated history keys aged: 47 cleared 40, refused 0, 17367040 bytes returned (16.56 MiB) kept keys missing: 0, byte-changed: 0 integrity_check: ok, rows 29949 -> 29949 47 aged and 40 cleared because the other 7 migrated through the empty-blob path and never had a blob to reclaim. Full suite 1,469 pass, 1 skipped, up from 1,454. analyze clean, format clean. Task: meshcore-open-5vt Agent Mail: TealGlen Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	3 weeks ago
diffwireauto	5f79c6e1db	fix(#943,#952): act on the Gemini gate findings ... Two of five findings were real. Log the downgrade refusal BEFORE the path lookup and the throw. onUpgrade runs inside drift's beforeOpen, so it fires on whichever isolate issued the first query, and whoever catches the exception decides what the user sees. A downgrade that only stopped background work, with nothing in the log, would be the quiet failure this branch exists to replace. The log line now lands first, so the record exists however the exception is handled. Strengthen the recovery bench. It asserted row COUNTS, so a converter producing the right number of rows with wrong contents would have passed. It now also checks that every identified blob record has a row carrying its identity, and that no payload is empty, both derived from the raw blob rather than from the converter under test so the check is not circular. Records with no messageId are not identity-checked, because reproducing the `x:` fallback key here would make it circular again; the count assertion still covers them. Verified on a copy of the owner's database with the trap reconstructed (the 6,308-message channel removed from the marker plus one planted row the blob does not contain): the key migrates, and all 6,308 identities are present. Then verified the new assertion can FAIL, by planting an empty payload the migration does not overwrite: Expected: empty Actual: WhereIterable<String>:['{}'] Three findings were rejected, with reasons in the PR body: the duplicate merge-key collapse is pre-existing and unchanged by this diff, the claimed migration/blob-save race cannot occur because of the re-check inside the per-key lock, and the path_provider call is bounded and already proven. Task: meshcore-open-lkp Agent Mail: TealGlen Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	3 weeks ago
diffwireauto	b08b42bff8	fix(#943): refuse a newer schema loudly instead of rewriting the version ... Owner decision, 2026-10-22: downgrades stay unsupported, and must fail deliberately rather than silently. Before this, onUpgrade guarded on `from < 2`, so a database from a FUTURE schema fell straight through it. The open succeeded, and drift then stamped user_version back down to this build's 2, because it writes schemaVersion whenever the versions differed. The database's only record of having been on a newer build was destroyed, and a later run of that newer build would re-run its own upgrade against tables already in their new shape. onUpgrade now throws OffbandSchemaDowngrade when `from > to`, naming both schemas, saying the upgrade is one-way, and giving the database path when it can be resolved (path_provider has no web implementation, so the path is best-effort and the message stands without it). Not made to work, deliberately. Once a key is on rows its blob is frozen, so an older build would read stale history and write into the blob while this one reads rows, orphaning everything it received. Supporting a downgrade would mean dual-writing the blob on every save, which is the cost #917 exists to remove. The two tests that documented the old silent behaviour now assert the refusal, including that user_version is left at 3 on a file-backed database, which is the whole point of throwing. Three more guard the upgrade direction: an equal version takes neither branch, a fresh database still lands on 2, and a real 1 to 2 upgrade still carries its blobs across, since that is the path every existing install takes. Release-note disclosure and rollout staging are tracked separately. Task: meshcore-open-3e1 Agent Mail: TealGlen Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	3 weeks ago
diffwireauto	eef192ea7f	fix(#952): the migration gate asserts a superset, not equal totals ... Four of the owner's store keys could never migrate to rows. Each held rows whose merge_key is absent from its blob (1, 3, 7 and 5 of them), and the readback gate compared the key's TOTAL row count against the number of distinct records in the blob. Those two numbers can never be brought level again: nothing removes the extra rows, and the frozen blob can never come to contain them. Every attempt refused, for good. His two largest channels were among them, 6,313 and 5,648 messages, so they kept re-encoding 3.77 MB and 3.55 MB of history on every save. That is the cost #920 removed and they were not getting it. No data loss: the blob stays complete and authoritative for a refused key. The gate asserted the wrong invariant. What it exists to catch is a record from the blob failing to reach a row, which is a SUBSET question. Equality became wrong the moment rows could legitimately hold messages the frozen blob does not, which is true for every migrated key the instant a new message arrives. - messageMergeKeys(storeKey) reads back the stored identities, and the gate now requires every deduped blob key to be among them. Rows beyond that are logged and accepted rather than treated as corruption. - The refusal log names how many records are missing and samples three, which is more use than the two totals it printed before. - The four keys need no healing migration: they migrate normally at next access, pinned by "a key stuck under the old gate recovers on next access". The step can still fail, and both halves of the loop are proved: a BlobStore whose insert silently drops a row is refused and stays on the blob, and a lossy converter is still refused before anything is written. Renamed the test file, since it now guards the gate rather than describing the trap it was written to demonstrate. Task: meshcore-open-lkp Agent Mail: TealGlen Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	3 weeks ago
diffwireauto	e2b8970f1f	fix(#943): establish what governs a downgrade, and correct the claim in code ... #943 says drift "refuses to open a database whose user_version is newer than the binary's schemaVersion". That is wrong, and the real mechanism points somewhere else. drift has no newer-schema refusal. It compares the stored user_version against schemaVersion for INEQUALITY and routes both directions into onUpgrade ("Schema version upgrades and downgrades will both be run here"). The pre-#917 build declared schema 1 and no migration getter at all, so it got drift's default onUpgrade, which throws. That is why the owner's old install would not start: not a version check, but a missing strategy, so it never reached the blobs it would have found. The consequence matters for the decision. This build does NOT throw on a downgrade: the guard is `from < 2`, so a database from a future schema opens silently, and drift then stamps user_version back down to 2, erasing the only record that it has been through a newer build. The next schema bump inherits a silent failure rather than #943's loud one. - schema_downgrade_test.dart, six tests: a newer version reports as hadUpgrade rather than being refused; a bare strategy throws (the #943 failure); this build opens a schema-3 database without complaint; and it rewrites the version backwards. Two more pin that an equal version takes neither branch and that a fresh database still lands on 2, so the downgrade cases are genuinely testing the downgrade path. - Corrects the stale claim in offband_database.dart, which still told readers a downgrade finds its history. The merged plan was corrected in 4b8f5731; this is the same correction in the code it describes. Also lands migration_refusal_trap_test.dart for #952, found while gathering this evidence: four of the owner's store keys hold rows the blob does not, so the readback gate's equality check refuses them on every attempt, for good. Five tests, including the clean-key control and a check that no message is lost. Fix deliberately not included; #952 carries the decision. The three decisions in #943 are untouched and remain the owner's. Task: meshcore-open-3e1 Agent Mail: TealGlen Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	3 weeks ago
diffwireauto	6574ecfa90	epic(#939): close the stale-read window, and a verdict on #190 ... Epic D of Feature #853. A different defect class from Epic B: these stores ARE correctly per-radio and bled anyway, through timing. **D2, #158: the window was an unexpected disconnect.** A manual `disconnect()` clears `_selfPublicKey`; `_handleDisconnection()` did not. So after a drop, every per-radio store, and the one `channels_screen` builds from `selfPublicKeyHex`, still held the previous radio's prefix. Connect a DIFFERENT radio and any read before its SELF_INFO landed served the old radio's history. That matches #158 being seen on desktop and not Android: it is a race, not a logic error. `_clearStorageScopeKeys()` now runs on an unexpected drop. It clears `_selfPublicKey` as well as the eleven connector-owned stores and StorageService, because `channels_screen` does not share those instances and derives its key from the getter, so clearing only the stores would have left that path reading stale. Verified before relying on it: every one of the thirteen per-radio stores guards on an empty key, in BOTH directions. I checked rather than assumed, because if any had used a bare prefix instead, clearing the key would have created a NEW unscoped global key, which is the exact bug class this Feature exists to remove. The names and deviceId stay, so the UI can still say which radio it is reconnecting to; only the data-scoping identity goes. **D1, #190: its named root cause is addressed, proven not argued.** #190 blamed slot-index keying with no PSK binding. Two mechanisms landed since: PSK-identity keying (#194) and the reuse-clear in `setChannel` (#193). Rather than assert that, there are tests reproducing #190's own scenario, a slot reassigned to a different channel: - keyed by PSK, the newly added channel reads a different key and sees nothing of the old occupant, which is #190's reproduction - the old occupant keeps its own history, because this is isolation by identity rather than deletion - the index fallback still works and still warns, pinning the remaining surface What remains of #190 is the index fallback firing before the channel list has loaded, which is #333 and a timing problem, so it belongs to this Epic rather than to #190. Recommendation for the owner: close #190 as superseded by #193, #194 and this Epic. Not closing it myself; it is his call and D1 was scoped as a verdict with evidence, not a closure. Suite 1,425 pass, analyze clean, format clean. Citadel: meshcore-open-pdx, meshcore-open-cwd Refs #939, #158, #190, #333, #853 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	3 weeks ago
diffwireauto	afbab311e6	fix(#946): classify stock 1.18.0 by frame shape, not version suffix ... Real stock 1.18.0 reports its version as "v1.18.0-81dbae5" (semver + git-describe hash), which classifyVersionString reads as the Offband dual form. On a stock-shape (82-byte) frame the classifier treated that as an inverse conflict and failed closed to stockLegacy, so the Device CLI console (#883/#884) was hidden on every real stock 1.18.0 device. Found by E2.2 bench verification (#869) against a live device. An 82-byte device-info frame is definitively stock: the Offband fork always appends at least one caps byte (>=83 bytes). So a stock-shape frame is now classified by ver code alone, regardless of the version string. The fork-shape branch is unchanged - it still requires dual-version corroboration before emitting fork frames, the direction where being wrong is dangerous. Regression test uses the real hardware string v1.18.0-81dbae5. Full suite green (1394); Gemini 2.5-pro review found no defects. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	3 weeks ago
diffwireauto	a21ff98c6c	epic(#938): Blocked pane says "no radio" instead of "no blocked users" ... Epic C of Feature #853, carrying #507. Much smaller than the plan assumed, because `BlockedView` already existed and was already wired into Settings. What it did not have was the distinction #507 asked for, or any tests. **The gap.** With no radio connected the pane rendered "No blocked users", which is indistinguishable from a connected radio with an empty list. Since #471 made blocks per radio, that wording invited exactly the wrong conclusion: that the blocks had been lost. Now a disconnected pane says "No radio connected" and explains why ("Blocks belong to the radio that holds them"), because the reason is what stops it reading as data loss. English-only string additions per the repo convention; `untranslated.json` tracks the other 17 locales. **Tests: 5, and the first one has teeth.** I proved it by disabling the new branch and watching it fail: Expected: exactly one matching candidate Actual: Found 0 widgets with text "No radio connected" Then reverted. A test nobody has watched fail is not evidence, and this session has already produced three harnesses that reported success while measuring nothing. Covered, all through the widget rather than the service: - no radio says so, and gives the reason - a connected radio with nothing blocked says THAT - a block made on radio A is absent on radio B - switching back restores A's list, because isolation is not deletion - an unblock survives a switch and back, which is #507's clear-sticks case and the re-clear that #471 was about #507 also lists "migration drops the global keys". That already exists: `BlockService.loadForDevice` calls `_store.dropLegacyGlobal()` on every device load. Noted rather than re-implemented. Suite 1,419 pass, analyze clean, format clean. Still outstanding for this Epic: the T1000e hardware check #507 asks for, which is an owner step and the only part I cannot do. Citadel: meshcore-open-uu9, meshcore-open-9ft Refs #938, #507, #471, #853 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	3 weeks ago
diffwireauto	a475cc21b4	task(#937): B2+B3 path history and delivery observations per radio ... Both scoped by the device-key prefix, and the legacy untagged data deleted per the owner's decision 1 rather than orphaned. **#854 path history: per radio AND out of SharedPreferences.** Two changes in one migration, because doing them separately means two migrations over the same data. The key was prefix + contact, so a route measured by a 1 W handheld was applied to a repeater and the reverse. It now lives in drift as prefix + device key + contact. The move out of prefs is not gold-plating: that one store held 2,092 keys and 86% of a 4.28 MB file, and every prefs write on Windows re-encodes the whole file (#923). This resolves #924 and makes every unrelated settings write cheaper in proportion. **#856 delivery observations: per radio, staying in prefs.** A repeater's 45-second deliveries were training the ACK-timeout model a 1 W handheld then used. One small key, 3,091 bytes and 14 entries on the owner's install, so unlike path history there is no cost argument for moving it and a move would be churn. **The legacy purge is chunked, and that is measured rather than guessed.** Each prefs `remove` re-encodes and rewrites the whole file, so I measured the real sequence against the owner's live prefs before designing it: 2,092 keys, 12.7 s of total work, mean 6.1 ms, but 32 ms for the first removal and under 1 ms by the last, because the file collapses from 4.28 MB to 45 KB as it goes. I had assumed ~57 s and was wrong; it is tractable. One unbroken pass would still block for 12.7 s, well past the 5 s watchdog, which is the exact failure #917 just fixed. So it yields every 20 removals. It runs after the startup loads so it never delays first paint, and it is idempotent: no writes once there is nothing left, so running it on every connect is safe. Legacy and new cannot be confused, which is what makes the purge safe: the new scheme writes to drift and the legacy keys are in prefs, so no length or shape heuristic is needed to tell them apart. That is decision 2 making decision 1 unambiguous. **Wiring:** StorageService is shared with PathHistoryService and TimeoutPredictionService, so the connector cannot own it like the other per-radio stores. It is injected from main() and fed the device key on SELF_INFO alongside them. Unset, both surfaces load nothing and never write, so a read before the handshake cannot serve another radio's data (#754 precedent). **Tests: Epic A's bleed tests inverted, 11 of them.** Every expectation that demanded the bleed now demands isolation, and the before/after is the git history of one file. Plus the purges: prefix-only, idempotent, and the scoped data surviving the purge of the unscoped. **Not done, and flagged rather than dropped:** the plan's B2 also said "bound what persists to what PathHistoryService actually caches". That bound existed to stop the prefs file growing. In drift a write costs one row and growth costs nothing per write, so the bound would now delete regenerable route history for no benefit. Skipping it is a judgement, not an oversight, and it is called out here and in the PR. The inventory's known-holes set is empty for the first time: {854, 855, 856} at Epic B's start, then {854, 856} after B1, now none. An Epic A sanity assertion that holes must exist failed on that and was corrected, because the invariant that matters is conditional: if a hole is declared it must name an issue, and empty satisfies it. Citadel: meshcore-open-0z3, meshcore-open-z8t Refs #937, #854, #856, #924, #853 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	3 weeks ago
diffwireauto	a7882b62e0	task(#937): B1 delete the dead pending_messages API ... #855 was filed as "pending messages are stored globally, not per radio". It is not a scoping bug. `loadPendingMessages`, `savePendingMessages` and `clearPendingMessages` had no callers anywhere in lib/ or test/, and the key was absent from the owner's live prefs. The `_pendingMessages` field in message_retry_service.dart is an unrelated in-memory list that happens to share the name. So the surface is DELETED, not scoped: three methods and the key constant. Scoping it per radio would have been three careful changes and a migration decision, for an API nothing calls. This is the finding that justified consolidating #854, #855 and #856 into one Epic instead of landing three PRs. Nobody reading #855 on its own would have gone looking for callers, because the issue already told them what the fix was. Removed with it: - the inventory row, replaced by a comment saying the surface is GONE rather than reclassified, so the history is readable - A2's round-trip test, whose job was to prove the thing being deleted actually worked. It served that and then became a test of nothing - 855 from the known-holes expectation, which now reads {854, 856}; that set shrinking to empty is what closing Epic B looks like What still guards it: the inventory's "declared but vanished from source" check fires if `pending_messages` ever comes back undeclared. Citadel: meshcore-open-li1 Refs #937, #855, #853 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	3 weeks ago
diffwireauto	9ffa9a3c0b	task(#936): A1 scoping inventory, with a gate that already caught four things ... Feature #853's acceptance bar is that every store has "a verified scoping verdict and no hole remains". Until now, verifying that meant a human re-reading an audit in an issue body, which is how three separate bleeds (#754, #854, #856) survived earlier rounds of bleed fixes. `scoping_inventory.dart` is that audit in code: every persistence surface with perRadio / globalOnPurpose / knownHole, a mandatory reason, and the file that owns it. A reason is required because an unexplained verdict is how a settled surface gets re-opened as a hole later. The test makes it a gate. It scans lib/ for the shape every key in this repo uses, a `const String` with a lower snake_case value, and fails when one is neither a declared surface nor an explicitly justified non-key. It also checks the reverse: a surface declared here but gone from the source. That one will fire when Epic B deletes `pending_messages`, which is intended. **It caught four things on its first two runs**, which is the argument for building it before Epic B rather than after: - `channel_cyr2lat_` and `contact_cyr2lat_` were never audited. #853 listed channel_settings_store as one surface; it owns two keys. - `los_error_elevation_unavailable`, a third error sentinel I had not found by hand. - `__msgrows_migrated`, declared by me and then reported missing, because my pattern required a letter first and internal markers start with underscores. The gate caught my own declaration bug. Scope of the scan, stated so nobody mistakes it for total: it would miss a key built inline with no constant, and a key that is not snake_case. Scanning every string literal in lib/ was tried and rejected, because it fires on asset paths and log tags, and a check that cries wolf gets worked around. That is the #927 lesson, which is also why there are three tests that prove this gate can fail rather than assuming it. Citadel: meshcore-open-z36 Refs #936, #853 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	3 weeks ago
diffwireauto	b59bc728fc	fix(#471): don't offload the client block list onto a blank radio ... On connect, the block reconcile unioned the client's block list with the radio's and pushed the difference, so a fresh/erased radio (empty list) had every client block offloaded onto it and came up pre-blocked (#471, owner verdict ERROR). Owner decision: Option A. A radio that reports an EMPTY block list is treated as blank and is NOT auto-offloaded; the client stays the source of truth and blocks reach a radio only by explicit user action. A radio that already holds blocks still unions normally. Client-side only, no wire change. Added a setOffbandCapsForTest seam so the reconcile is testable. Part of radio-profile isolation Feature #853. The per-radio Blocked view + provenance (#507) is the follow-on. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	3 weeks ago
diffwireauto	a331075a8b	fix(#754): scope discovered contacts per radio ... Discovered contacts (nodes heard but not added) were stored under one global 'discovered_contacts' blob shared by every radio, so one radio's discoveries showed up while another was connected (#754, Feature #853). Scope the store by the connected device-key prefix like contact_store and the others; the connect block sets the key and the existing startup load clears + reloads the list for that radio. An unset key loads nothing and never writes, so it can't read or clobber the legacy shared blob. No migration: the legacy blob is orphaned and each radio's list self-heals as it re-hears adverts. Part of radio-profile isolation Feature #853. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	3 weeks ago