287 commits

Author	SHA1	Message	Date
andodeki	6f4fb8058e	refactor(spreadsheet-ui): keep shared model attachment single-source	2026-08-02 07:34:54 +00:00
andodeki	92b1daf9ba	refactor(spreadsheet-ui): remove grid-owned spreadsheet data	2026-08-02 07:32:19 +00:00
andodeki	775eec4424	fix(pay): remove PIN capture from default builds rather than hiding it (0.3) ... Asked in review: "does the latest code have the PIN input field?" It did. ## Hiding was weaker than it looked pin_input, form_pin and the reveal toggle were all present, and the default build hid them at runtime in on_after_new. Three problems: 1. The DSL declared the control visible and Rust hid it afterwards, so anything re-applying the UI definition — a hot reload, a re-instantiated sheet — brought it back. Defect B11 already names this class. 2. Hidden is not absent. The TextInput stayed in the widget tree, and a hidden input can still be focused or filled programmatically. 3. form_pin was compiled into every build, so any path reaching it could populate it. Item 0.3 asks for removal, not concealment. ## The field no longer exists without `demo` form_pin, pin_visible, the eye-toggle handler, the text-input handler, both PIN checks, the request construction and try_build_ussd_request are all #[cfg(feature = "demo")]. A default build has no field to write to. The DSL now declares visible: false on the PIN input and its reveal button, so hidden is the default state rather than a runtime correction; demo unhides them on init. That closes the reload path in (1). One runtime call remains as belt-and-braces: if a hot-reloaded definition surfaces the input, the non-demo arm wipes what was typed. It has no form_pin to clear, because there isn't one. ## Proving absence rather than asserting it A grep for form_pin proves nothing — it passes just as happily against a field still present behind a runtime if. tools/check-no-pin-capture.sh is a compile probe: it references the field outside any cfg block and requires the default build to fail with "no field `form_pin`" while demo succeeds. The script restores the file on every exit path. Verified both directions: passes on current code, exits 1 when the field is re-exposed un-gated. ## Validation cargo check -p {nigig-pay-ui,nigig-pay,nigig-mpesa,nigig-core} pass cargo check -p {nigig-pay,nigig-mpesa} --features demo pass nigig-pay-ui: cargo test --lib pass (61) domain / storage / platform / mpesa harness pass no-PIN-capture guard: verified to fail on a re-exposed field pass ## What 0.3 still leaves open The Java-side KEY_PIN scrubbing was already done, so 0.3 is complete for the default product. A demo build still captures a PIN by design — that path exists for authorised device testing and is covered by the unresolved Play-policy decision in ADR 0007. If that decision goes against the USSD rail, the demo path and its PIN capture are deleted with it.	2026-08-02 07:31:44 +00:00
nigig-ci	cbe47a5f6c	perf(sms): close the outstanding Phase B and D items ... An audit of Phase 0 through D against the tree found three tasks marked done in prose but absent from the code. This closes them. D5 -- bulk send still blocked the UI thread. The send loop ran synchronously in handle_send_bulk. SmsManager.sendTextMessage queues to the radio and rate-limits, so a 200-recipient batch was a multi-minute ANR with no progress and no way to tell whether anything was happening. Phase E8's throttle bounded the worst case at 30 sends, but bounded blocking is still blocking -- and I said as much when deferring it. Now uses the worker pattern D1 established: spawn, publish progress through a mutex-guarded slot, SignalToUI, drain on the UI thread. The status line counts up ("Sending 12/200…") instead of freezing. BULK_SEND_IN_FLIGHT prevents two overlapping batches. D2 -- the ContentObserver, the half I left open. Phase D removed the 5-second poll that re-armed itself via redraw() and stopped the app ever idling. That fixed the busy loop but left a gap I documented rather than closed: a message arriving while the app was open did not surface until the next Resume or manual pull. Adds SmsInboxObserver.java -- a ContentObserver on content://sms, registered with a main-Looper Handler, idempotent so onResume can call it freely -- compiled and dexed by the existing build.rs pipeline and loaded through the same in-memory dex loader as the receivers. onChange calls into Rust, which does two cheap things: set an atomic, and invoke a registered waker. The waker matters. robius-sms has no UI dependency and cannot call SignalToUI itself, so without it the flag would only be observed on the next event-loop turn that happened for some other reason -- which, with the poll gone, might be never while the app sits idle. The app registers SignalToUI::set_ui_signal, so this is a genuine push. Native binding is dynamic, not #[no_mangle], for the same reason as E6: the class comes from an in-memory dex and is not on the JVM's search path. B0 (wider) -- 23 crates declared robius-sms and never called it. Phase B removed the three declarations that put RUSTSEC advisories on nigig-build and explicitly flagged the rest as "the same latent problem, sweep separately". This is that sweep: every crate with zero references to robius_sms in its sources loses the dependency. nigig-mpesa, nigig-pay and nigig-sms keep it -- they are the only real users. nigig-system-prefs only mentions robius-sms in its package description, so its manifest is untouched. Cargo.lock loses another 21 lines. Verified: 13/13 CI checks. clippy -D warnings clean on host and aarch64-linux-android; the Android build compiles, javac-builds and dexes the new observer class. cargo deny still "advisories ok, bans ok, licenses ok, sources ok". clippy ratchet holds at 49. Sampled four of the 23 stripped crates plus all five I edited; all build. Pre-existing and unrelated: nigig-map fails to compile on pristine origin/main (12 errors in view.rs, a Script/Widget derive problem), so pageflipnav and anything else reaching it cannot be checked here. I touched no files under crates/apps/map. NOT verified on a device. The observer's registration, the onChange callback and the waker all need an emulator or handset with a live SMS provider; this sandbox has neither, and there is still no CI runner.	2026-08-02 07:28:01 +00:00
Arena Agent	44c87d4f7b	fix(cad): viewport sync reissued live part ids and undid edits ... Two defects in sync_parts_from_any_dirty_viewport, both from the same root cause: three viewports each own state that only one of them can win with per frame. 1. THE ID ALLOCATOR MOVED BACKWARDS. Each CadViewport owns a `next_part_id` counter, and replace_parts_snapshot assigned the source's value directly. Only one viewport wins a sync frame, so the loser's allocations are absent from the winner's snapshot -- and its counter is then reset below what it has already handed out. Draw a part in the 2D view and one in the 3D view between two syncs: both allocate the same id independently, the loser's part is discarded, and the next part in that view reuses an id that is still live. NodeId is the key for MeshCache, part_geoms and every command, so a duplicate silently aliases two parts. Now reconciled via scene_holder::reconcile_next_part_id, which takes the max of the destination's counter, the source's, and one past the highest id actually in the incoming list. It cannot retreat, cannot collide with a live id, and saturates rather than wrapping at u64::MAX. Four tests, negative-tested. 2. THE LOSING VIEWPORT UNDID THE WINNER'S EDIT. The source loop broke on the first dirty viewport. take_script_dirty clears the flag as it reads it, so a viewport never visited kept its flag set, won the *next* frame, and pushed its own now-stale snapshot back over the edit that had just been applied. The loop now visits all three and clears every flag in one pass. The first dirty one still supplies the snapshot; the others' edits are already in it, because a sync pushes the winner's full parts list. Modelled both interleavings against the real control flow before changing anything. These are worth recording as evidence for Phase 5.2 rather than just fixed: a single counter duplicated three ways cannot be made correct by copying, only bounded. ARCHITECTURE.md now says so at the point where someone would otherwise reach for another patch. 730 lib + 154 integration, 0 failed. All twelve gates pass.	2026-08-02 07:27:01 +00:00
arena-agent	ac1ddfe2c2	feat(doc): float the platform clipboard menu on long-press selections ... The touch clipboard surface is now complete: a mobile long-press selection requests the platform clipboard menu (cx.show_clipboard_actions, iOS/Android backends) right after the selection lands, and its actions re-enter through the synthesized hits the editor already answers -- Copy/Cut as TextCopy/TextCut, Paste as TextInput (which also flows through multi-line block splitting). - Edit mode only: View keeps the long-press for merge/highlight (its hits stay gated), and desktop sessions never reach the touch-driven frame clock, so their clipboard story is unchanged. - has_selection follows the copyable payload exactly like the native menu: word selections anchor on the union of their glyph rects and offer Copy/Cut, while a cell range carries no payload and gets a paste-only menu anchored on the pressed cell's rect. - The request is mirrored on the widget as pub clipboard_menu: makepad's platform op queue is crate-private, so hosts rendering their own menu (and tests asserting the request) read it there. Runtime tests (real TouchUpdate + 24-frame NextFrame clock) cover the Edit word-menu request with Copy flowing back out, the cell paste-only menu rect matching the pressed cell with a menu Paste splicing into the parked cell, and View mode making no request at all.	2026-08-02 07:24:37 +00:00
Arena Agent	5c8ee16cbb	fix(cad): a dropped rebuild request left the spinner up forever ... CadRebuildWorker::request discarded the channel send error: pub(crate) fn request(&self, request: CadRebuildRequest) { let _ = self.request_tx.send(request); } The caller then unconditionally sets rebuild_pending = true and shows "Computing 3D model...", and that flag is cleared in exactly one place: drain_rebuild_results, on a result whose seq matches. So if the worker thread is gone the request vanishes, no result can ever arrive, and the spinner stays up for the rest of the session with every later edit appearing to hang. No error is logged and nothing recovers. request now returns whether the send succeeded. request_rebuild acts on it: drops the dead worker so the next edit constructs a fresh one, clears rebuild_pending, and says "Rebuild worker stopped; retrying on the next edit" instead of lying about work in progress. Test builds the worker from raw channel halves so a closed receiver can be staged without a thread or a Cx. Negative-tested by restoring the `let _ =`. Also examined and found sound, recorded because the absence of a bug is worth knowing: - The seq protocol. I suspected a stale result could strand the pending flag and modelled the interleavings; it cannot. The worker only emits seqs the UI requested, seqs are monotonic, and drain keeps the last result in the channel -- so the final result always matches the current seq. wrapping_add on a u64 needs 2^64 rebuilds. - Worker panic safety. catch_unwind wraps the evaluation, and both save_cad_state and cad_mesh_data_from_solid are inside it, so a panic in either is converted to an Error payload rather than killing the thread. The dead-worker path this commit handles is therefore defensive rather than routine -- but it costs three lines and the failure it prevents is unrecoverable without a restart. Swept the module for other discarded sends: none remain. 726 lib + 154 integration, 0 failed. All twelve gates pass.	2026-08-02 07:21:49 +00:00
Arena Agent	92e4a2515a	fix(cad): a failing undo or redo destroyed the command ... UndoRedoStack::undo popped the entry and then ran it: let cmd = self.undo_stack.pop_back().ok_or(..)?; cmd.undo(ctx)?; // <- early return drops `cmd` self.redo_stack.push(cmd); If `cmd.undo` fails, `?` returns while the command is still a local, so it is dropped: gone from the undo stack and never reaching the redo stack. The user silently loses a history entry, and that edit can never be reversed again. `redo` had the identical shape. This is reachable, not defensive. Every command's undo bottoms out in move_node / update_node / delete_node, each of which returns NodeNotFound when the node is missing -- which is exactly what happens after a script rebuild replaces the parts list. Undo an edit to a part the script no longer produces and the entry evaporates. Fixed by running the command while the stack still owns it (`back()` / `last()`) and only moving it across after it succeeds. The subsequent pop cannot fail, but is still handled with `if let` rather than an unwrap, matching the no-panic rule this module now enforces. Two tests, negative-tested by restoring the pop-first order: both assert `undo_depth + redo_depth == 1` after the failure, i.e. the command is still *somewhere*. Asserting only that undo returns Err would have passed against the broken code -- it did return Err, while destroying the entry. The failure message prints both depths, so a regression says which stack lost it. Swept the rest of the CAD module for the same pop-then-fallible-call shape: no other instances. 725 lib + 154 integration, 0 failed. All twelve gates pass.	2026-08-02 07:16:57 +00:00
andodeki	a176b212ea	refactor(spreadsheet-ui): bind shared model before first grid draw	2026-08-02 07:16:27 +00:00
andodeki	4d161f1da9	refactor(spreadsheet-ui): attach shared model before grid render	2026-08-02 07:13:13 +00:00
Arena Agent	cb5def965b	fix(cad): exports reported success on a failed write ... Every file export buffered its output through a BufWriter and never flushed it. BufWriter flushes on drop and DISCARDS any error it hits doing so, so a write that fails only when the buffer is pushed to disk -- full disk, revoked permission, a network mount going away mid-export -- returned Ok(()). The status label then said "STL: 11 parts -> model.stl" while the file on disk was truncated. Demonstrated before fixing, with a writer that accepts buffered writes and fails on flush: without explicit flush -> Ok(()) with explicit flush -> Err("flush failed: disk full") Three affected paths: PDF (exporters.rs), STL and GLB (workspace.rs). All now go through exporters::export_to_file, which owns the BufWriter, flushes it, and maps a failed flush to "<what>: could not write file: <cause>". Putting the flush in one place is the point -- it was forgotten three times independently. The fourth BufWriter, in arch_pdf, writes into a Vec<u8> where flush cannot fail. Left alone and excluded from the gate with that reason recorded, rather than churned for uniformity. Two tests pin the mechanism rather than one exporter: a small write stays in the buffer, so write_all succeeds and only the flush can report the failure. One asserts the drop path hides it, the other that an explicit flush surfaces it. If BufWriter's drop behaviour ever changed, the first test would fail and tell us the helper is no longer needed. CI gate added and negative-tested: no BufWriter::new in the CAD module outside the flushing helper. Also checked, and found clean: arch_svg still escapes both XML sinks after the Phase-4 projection rewrite, and all three cargo-deny exemptions are still live -- removing them makes exactly those three advisories fire, so none is a stale entry silently widening the policy. 723 lib + 154 integration, 0 failed. All twelve gates pass.	2026-08-02 07:12:23 +00:00
andodeki	9be2dd8d7c	refactor(spreadsheet-ui): remove obsolete data swap bridge	2026-08-02 07:05:43 +00:00
arena-agent	920827a440	feat(doc): split multi-line paste into blocks with one-step undo ... A pasted TextInput payload containing newlines used to land as a single run of text with literal line feed characters. It now splits block-per-line like a desktop editor: line 0 splices into the caret block, middle lines become sibling blocks inheriting the caret block's kind, and the trailing SplitBlock carries the caret block's suffix onto the last pasted line (ab|XY pasted with "l0\nl1\nl2" yields abl0 / l1 / l2XY). The caret parks after the last pasted atom. The whole paste folds into one Compensation::Group (undo applies group members in reverse, redo applies the inverse group in authored order), so N lines retract in a single Ctrl+Z. The caret anchor may be tombstoned (the caret a selection delete leaves behind): the new CrdtDocument::live_offset_of resolves it to the same live-text offset RGA splicing uses, so pasting over a deleted selection lands exactly where a single-line paste would. CRLF payloads strip their \r. Surfaced and fixed at the source while building this: the synthetic block a SplitBlock opens was a text dead end -- atoms and style ops addressed to a split op id landed in the op log but evaporated from the projection, and the child always spliced directly behind its parent. Split children are now first-class materialization targets: suffix atoms re-link head-to-tail (keeping ids and inherited style runs), child-addressed atoms splice in RGA-wise, and the child's splice skips the parent's real-chain descendants, keeping the middle paste lines ahead of it. Runtime tests cover the split/suffix/caret/undo/redo cycle, paste-over-selection as two undo steps, and the in-cell newline guard. Engine tests cover grouped-undo chronology, tombstone anchors, empty middle lines, CRLF, table refusal, peer convergence, and the synthetic-child text/style/order regressions underneath.	2026-08-01 05:44:28 +00:00
User	0718743e19	feat(map): implement Phase 2 route overlay system with markers and position puck ... Complete overlay rendering system ported from Makepad upstream: ## New Features - **Route Overlay Rendering**: Route polyline with casing (9px) and fill (5.5px) - Traveled portion dimming (alpha 0.30) for navigation progress - Additive glow effect (route_glow) for visual enhancement - Destination dot at route end - Screen-space rendering with viewport clipping - **Drop Markers**: Professional pin-shaped markers with: - Soft ground shadow (ellipse) - Triangular tail + circular head pin shape - White pip in center - 16px tap detection radius for interaction - Custom color support per marker - **Position Puck**: Current location indicator with: - Accuracy circle (scales with zoom, 10-28% alpha) - Heading wedge (20px tip, shows direction) - White ring + blue dot (9px/6.2px) - Automatic viewport clipping (60px margin) ## Implementation Details - **OverlayCamera**: Screen-space transformation system - norm_to_screen() converts normalized coords to screen pixels - Supports rotation and 2.5D tilt (for future phases) - Meters-per-pixel calculation for accuracy circle scaling - **Integration**: Seamlessly integrated into NigigMapView - Added draw_overlay: DrawVector field to widget - Added overlay_state: MapOverlayState field - Rendering happens after tile passes, before status text - Zero overhead when no overlays are active (is_empty() check) - **Helper Functions**: - draw_route(): Multi-pass route rendering with travel dimming - draw_marker(): Pin-shaped marker with shadow and highlight - draw_puck(): Location indicator with accuracy and heading - marker_at(): Hit testing for tap interaction - **Viewport Enhancement**: Added meters_per_pixel() method - Calculates real-world scale for accuracy circle sizing - Accounts for latitude-based distortion - Used by position puck for realistic accuracy visualization ## Technical Architecture - Immediate-mode rendering using DrawVector - Per-frame geometry rebuild (route scale: few hundred points) - Viewport clipping with margin (24px for routes, 30px for markers) - Decimation for performance (1.5px threshold on zoom-out) - Additive blending for glow effects (no HDR required) ## Files Changed - crates/apps/map/src/overlay.rs (NEW, 379 lines) - crates/apps/map/src/lib.rs (module registration) - crates/apps/map/src/view.rs (widget integration, 15 lines added) - crates/apps/map/src/viewport.rs (meters_per_pixel method, 18 lines) ## API Usage ## Performance - Zero cost when no overlays (early return on is_empty()) - Efficient viewport clipping reduces overdraw - Route decimation prevents excessive geometry at low zoom - All rendering uses GPU-accelerated DrawVector ## Compatibility - Backward compatible: existing map functionality unchanged - Overlay state persists across frames (no per-frame allocation) - Integrates with existing theme system (route colors from theme) - Supports future 2.5D camera and heading-up rotation ## Testing Recommendations 1. Verify routes render with casing/fill at all zoom levels 2. Test traveled portion dimming updates correctly 3. Verify markers appear at correct screen positions 4. Test position puck accuracy circle scales with zoom 5. Verify heading wedge rotates correctly 6. Test viewport clipping at screen edges Refs: Phase 2 from MAKEPAD_DEV_BRANCH_GAP_ANALYSIS.md Built on: Phase 1 (POI icon system, commit ae23d36)	2026-08-01 05:27:00 +00:00
User	913929f07f	feat(map): add 42 SVG POI icons with vector tessellation infrastructure ... Add complete vector-based POI icon system with: - 42 OpenStreetMap-carto SVG icons (alcohol, atm, bakery, bank, bar, etc.) - icons.rs module with zoom-constant vector tessellation - Icon mesh generation at compile time using OnceLock caching - Integration with existing sprite.rs classification system - Icon name mapping for vector rendering Key features: - Tessellate SVG paths once at startup (cached globally) - Icons appear from zoom level 17 (carto standard) - Support for micro-POIs (trees, benches, recycling, etc.) - Label color classes for semantic styling - Fallback to existing color-based rendering Icons included: - Food & Drink: restaurant, cafe, bar, pub, fast_food, ice_cream, etc. - Shopping: supermarket, bakery, butcher, clothes, florist, etc. - Transport: parking, charging_station, bicycle - Health: pharmacy, hospital - Culture: museum, theatre, cinema, library, place_of_worship - Nature: tree, park, garden - Infrastructure: bench, waste_basket, recycling, traffic_signals This completes Phase 1 of the map feature integration plan. Icons are now available for rendering but use colored rectangles in the current POI pass. Vector rendering will be added in a follow-up phase. Refs: Phase 1 from MAKEPAD_DEV_BRANCH_GAP_ANALYSIS.md	2026-08-01 05:13:09 +00:00
arena-agent	7e0012b866	feat(doc): undo cross-block cuts losslessly via range tombstones ... ReplaceBlockRange pushed no undo compensation, so a multi-block cut or selection delete could never be undone: the range op rewrites only the projection (drained blocks and every atom beneath the span stay in the op log untouched), and no op existed to make it stop applying. Add the CancelBlockRange/RestoreBlockRange op+compensation pair, resolved chronologically per target like every other tombstone pair (merge splits, cell styles, blocks, text, rows, columns). Undo of a cross-block delete tombstones the range op itself, which is lossless: splices, middle blocks and their texts all re-materialize exactly from the untouched log, in a single undo step. Redo clears the tombstone. The controller also refuses spans whose endpoints do not resolve against the projection in order, so a no-op range never strands an entry on the undo stack. Coverage: engine tests for the one-step undo/redo cycle (with a double undo proving the chronological tombstone), text typed beneath a cancelled range surviving, and unresolved-span refusal growing no undo stack. Widget runtime test cuts across three blocks, asserts the joined payload, then Ctrl+Z restores all three blocks and Ctrl+Shift+Z re-cuts.	2026-08-01 05:02:19 +00:00
nigig-ci	a38c41c00a	security(sms): stop persisting message bodies, throttle sends (Phase E) ... E1 -- the inbox was written to disk in plaintext. offline_store wrote every SMS body to app_data_dir/offline_store/sms_messages.json as pretty-printed JSON. SMS is the transport for OTPs, banking codes and M-Pesa confirmations, so that file was the user's complete authentication history sitting in app-private storage -- readable by anything running as the same UID, and included in backups. This repository already knew the answer. THREAT_MODEL.md T-I2 records "Raw SMS persisted to PSV file" as fixed in Phase 0, with raw_message omitted from save_to_disk() so it "lives in memory only". The SMS app then re-introduced the same defect at larger scale: the entire inbox rather than just M-Pesa messages, and with no retention limit until D6. OfflineSmsMessage.body is now #[serde(skip)]. Dropping the field rather than encrypting it is the deliberate choice: every consumer already reads the device provider FIRST and writes the cache second (nigig-sms fetch_from_device, and the mpesa and pay transaction pages), so the provider is the system of record and no body needs to survive a restart. Encryption would keep the plaintext reachable to anything holding the key. Not writing it removes the asset. Two consequences handled: sms_key() no longer hashes the body, since a reloaded row has an empty one and dedupe would otherwise never match its own cached entry and grow a duplicate per refresh; and the cached first paint shows a neutral placeholder rather than a blank preview for the instant before the provider read lands. E9 -- the Linux backend's dependencies were pure cost. robius-sms declared polkit =0.17.0 and gio =0.17.0 for target_os = "linux". sys/linux.rs references neither: all twelve functions return Err(PermanentlyUnavailable). Those two crates dragged in glib and proc-macro-error and were the origin of RUSTSEC-2024-0370 and RUSTSEC-2024-0429 for every consumer of this crate. Deleting the block removes 340 lines from Cargo.lock. polkit, gio, glib and proc-macro-error no longer appear in the workspace at all, which also closes the LGPL-2.1 linkage question outright rather than routing around it as Phase B did for nigig-build alone. E4 -- ROBIUS_SMS_BOOT_LIB was a code-injection vector. build.rs interpolated that environment variable straight into a Java string literal, which is then compiled, dexed and loaded at runtime with the app's full permissions. A value containing a quote closes the literal and injects arbitrary Java that runs on the device at boot. Build-time environment is not trusted input. Now validated against [A-Za-z0-9_]+ and the build fails loudly otherwise. Tested both ways: an exec payload is rejected, a legitimate name builds. E5 -- undefined behaviour in the dex loader. new_direct_byte_buffer was handed RECEIVER_BYTECODE.as_ptr() as *mut u8 -- a &'static [u8] in .rodata cast to a mutable pointer, when the API is documented as taking writable memory and InMemoryDexClassLoader may write through it. Now copies into an owned allocation and leaks it, which is correct rather than lazy: the buffer backs a ClassLoader cached in a OnceLock for the process lifetime. E6 -- two bindings for one native method. rustRestoreSchedules was both exported #[no_mangle] and registered dynamically via register_native_methods. Which one won was unspecified. Kept the dynamic one, because the class is loaded from an in-memory dex and is not on the JVM's search path, so symbol binding is not guaranteed to find it. E8 -- no send rate limiting. Nothing capped send rate, and the bulk UI exists to blast a scraped directory. Android's practical throttle is ~30 messages per 30 minutes per app, past which sends are silently dropped -- so an unthrottled batch both overspends and fails opaquely. Adds SendRateLimiter, a pure token bucket taking an explicit clock so it is unit-testable without sleeping, wired into the bulk sender. A 200-recipient blast now stops at 30 and says why. E10 -- robius-sms carried no license field, so cargo-deny needed a [[licenses.clarify]] override asserting one. Stated in the manifest; override removed. E2 was already satisfied by D6 (retention capped at 5,000). E7/E11 are documented rather than fixed, which is the honest status: delivery confirmation needs real PendingIntents plumbed through (A8 documents that Ok != delivered), and sender validation cannot be solved client-side. Both are now rows in THREAT_MODEL.md instead of findings in a markdown report -- along with T-I2b for E1 and T-I4 for E3, which is NOT done: scheduled message bodies are still plaintext in SharedPreferences. CI: adds a gate asserting OfflineSmsMessage.body keeps #[serde(skip)]. Removing that attribute silently resumes writing plaintext and nothing else would fail. Negative-tested. deny-nigig-build.toml drops to 2 exemptions (from 5 before Phase B). Tests: robius-sms 21 -> 25. Verified: 12/12 CI jobs, clippy -D warnings clean on host and aarch64-linux-android, cargo deny "advisories ok, bans ok, licenses ok, sources ok", clippy ratchet holds at 49.	2026-08-01 04:58:46 +00:00
andodeki	acbd956791	refactor(spreadsheet-ui): route autofill reads through shared model	2026-08-01 04:58:30 +00:00
Arena Agent	03dea4d14f	fix(cad): remove panics from CAD production paths ... Continued auditing the code the KeyCode fix (667f565) made reachable, and followed the panic sites out from there. Command::merge's default was `panic!("merge() called on a Command that didn't override it")`. That is reachable, not defensive: any command that overrides can_merge but forgets merge hits it. UndoRedoStack::execute runs it on every frame of a drag, and the code five lines away already declines to panic on a genuinely unreachable branch, with the comment "never panic on the undo path". A CAD editor holds unsaved work -- losing the session is far worse than the mis-merged undo entry being reported. Now a debug_assert!: loud in development where it is actionable, and survivable in a shipped build. Proven by test in both configurations -- the release behaviour is pinned by a test marked `#[cfg_attr(debug_assertions, ignore)]`, since the dev build is *supposed* to fire the assertion. Negative-tested by restoring the panic. Also replaced three `unreachable!()`s: - add_part_command and split_selected_part_at both did `position(..)` then `get(idx).unwrap_or_else(|| unreachable!())`. The index round-trip is what created the Option they then had to discharge with a panic; `find(..).cloned()` and `enumerate().find(..)` express the same thing without arming one. - The DDE digit match's `_ => unreachable!()` arm is genuinely dead (the outer arm narrows to Key0..Key9), but a keyboard handler is not worth a crash to say so. It swallows the keystroke instead. CAD production code now contains no panicking macros at all, enforced by a new CI gate that scans each file up to its first #[cfg(test)] -- test code may panic freely. Negative-tested. One test-authoring note worth recording: my first version of the merge test built five MoveNode commands all with `from: 0`, which tripped MoveNode::execute's debug_assert that the scene's previous position matches `from`. The assertion was right and my test was wrong; a real drag chains each frame's `from` to the previous `to`. The corrected test now also verifies the thing that assertion protects -- five drag frames collapsing into one undo entry. 710 lib + 154 integration, 0 failed. All ten gates pass.	2026-08-01 04:56:02 +00:00
User	36c1da92fd	fix(map): resolve frozen-vec theme errors by using pure Rust theme builders ... The DSL-defined MapFillRule, MapRoadRule, MapWaterwayRule, and MapRailRule children in style_light and style_dark were causing 86 'cannot push to frozen vec' errors per startup. The Makepad VM freezes the MapThemeStyle object after first evaluation, preventing re-evaluation from adding new children. This left compiled_style_light and compiled_style_dark with no theme rules, resulting in 0 rendered features (only brown background and labels visible). Solution: - Strip all DSL rule definitions from view.rs style_light/style_dark blocks - Add default_light_theme() and default_dark_theme() pure Rust builder functions to style.rs that construct complete CompiledMapTheme instances - Update rebuild_compiled_styles() to call the Rust builders instead of compiling from frozen DSL objects This preserves the identical visual output (same colors, widths, sort ranks) while eliminating the frozen-vec errors. Roads, buildings, water, railways, and all other styled features should now render correctly. Fixes: 86 'cannot push to frozen vec' errors per startup Fixes: 0 rendered features on all map tiles	2026-08-01 04:55:32 +00:00
andodeki	3cbd61cd31	refactor(spreadsheet-ui): route grid mutation commands through shared model	2026-08-01 04:51:57 +00:00
andodeki	538848f527	refactor(spreadsheet-ui): route recalculation state through shared model	2026-08-01 04:45:49 +00:00
nigig-ci	69dd169ca6	perf(sms): get blocking I/O off the render thread (Phase D) ... D1 -- the SMS read blocked the render thread. fetch_from_device() called robius_sms::list_messages() directly from draw_walk. That is a blocking cross-process ContentProvider query over Binder, plus ~10 JNI calls per message row, plus a full rewrite of the offline JSON store. On a populated inbox it is a multi-hundred- millisecond stall, taken on the render thread. robius_android_env::with_activity() calls attach_current_thread_permanently() and ContentResolver.query is thread-safe, so the read is safe off the UI thread. It now runs on a worker and hands back through a results queue drained on Event::Signal -- the same shape the contact lookup in this file already used. D2 -- the app never idled. draw_walk ran a 5-second wall-clock refresh, and that refresh called redraw(), which scheduled the next frame, which re-entered draw_walk. A self-sustaining loop, running whether or not the SMS tab was even visible, each cycle paying D1's cost plus D3's clone. Refresh is now event-driven: first load, Event::Resume, pull-to-refresh, and the permission-granted callback. NOT yet a ContentObserver on content://sms -- that is the remaining half of D2 and is called out in the code. Until it lands, a message arriving while the app is open appears on the next Resume or pull rather than within 5s. That is a deliberate trade: a bounded staleness window in exchange for an app that can reach idle. D3 -- a deep clone per refresh, purely to diff. `let previous = self.conversations.clone()` copied every message in every conversation on each cycle so the result could be compared for equality. Replaced with a u64 digest over (count, address, message_count, newest date_ms). Bodies are immutable once stored, so that is sufficient to notice an insert, a delete or a new message -- and the test asserts exactly those three cases. D4 -- ~900 pointless worker kicks per second. start_contact_lookup_worker() was called once per visible row per frame (~10-15 per frame, ~900/s at 60fps). Each call took 3-4 mutex locks before early-returning, contending with the worker thread trying to write results back. Now called once, after the draw pass. The per-row code only enqueues. D6 -- the offline store grew without bound. upsert_sms_messages re-read, re-hashed, re-sorted and rewrote the whole file on every call, with no cap -- while append_location() a few lines below has always truncated to 512. Capped at MAX_CACHED_SMS (5000), newest-first so truncate drops the oldest. This is a display cache; the device provider stays the system of record. D7 -- O(rows x selected) per frame in the bulk list. get_selected_companies() returns a Vec and the draw path called `selected.contains(..)` once per visible row, so "Select All" over the Nairobi directory made every frame quadratic. Now a HashSet. Same fix in sync_selected_to_recipients, whose phone de-duplication was also O(n^2) via `phones.contains()`. Refactor note: group_into_conversations() and conversations_digest_of() were lifted out as free functions. ConversationsList holds a Makepad View and is not Default, so nothing in it could be unit tested; the logic D1/D3 depend on now can be. CI: adds a gate rejecting blocking robius_sms provider calls inside any draw_walk. Negative-tested by reinserting the call and confirming it fails. Tests: nigig-sms 19 -> 22, nigig-core +1. Verified: clippy ratchet holds at 49, clippy -D warnings clean on host and aarch64-linux-android, nigig-build still builds. NOT measured. The plan asked for before/after frame timings on a 5,000 message fixture and this sandbox has no device or emulator, so the figures above are reasoned from the code, not profiled. D5 (bulk send still blocks the UI thread) is untouched and needs the same worker treatment as D1. Pre-existing and unrelated: nigig-core's pending_tx_lifecycle test fails identically on pristine origin/main (wall-clock assumption in an M-Pesa expiry test).	2026-08-01 04:34:22 +00:00
arena-agent	a3ff59e512	feat(doc): clipboard copy/cut/paste across blocks and table cells ... The CRDT editor had no clipboard surface at all. It now answers the platform clipboard queries exactly like makepad's TextInput: - Hit::TextCopy / Hit::TextCut fill the response cell with the selection payload: the text-block selection joined with newlines, or the in-cell character span when the caret lives in a table. Nothing selected leaves the response empty, so the platform keeps the clipboard alone. - Cut removes the payload through the shared selection-deletion path and paste flows through the existing TextInput insert path (replace- selection semantics for both blocks and cells). Three latent production bugs uncovered and fixed at the source: 1. delete_selection's applied flag was wired to the empty replacement's missing trailing atom, so same-block Backspace-over-selection over-deleted by one char and left live anchors behind. 2. engine delete_text pushed no undo compensation, making every selection deletion (cut, type-over, Backspace-over) unrecoverable. It now pushes the symmetric RestoreText pair. 3. All six engine tombstone pairs (text, blocks, rows, columns, merge splits, cell style clears) resolved as union-minus-union: once a restore op existed, delete→undo→redo could never re-delete. They now resolve chronologically per target in operation order. 13 new tests: 5 clipboard runtime (payload, cut+undo, cell span, no-payload, newline join), 2 widget regressions (over-delete, delete-key), 6 engine (delete undo/redo, empty-replace single-step, block/row/merge/cell-style chronology cycles). nigig-build 704 -> 711, doc-engine 62 -> 68.	2026-08-01 04:31:06 +00:00
Arena Agent	f54dda90dc	fix(cad): direct distance entry lost its direction on 0 and negatives ... Fixing the KeyCode bindings (667f565) made the direct-distance-entry keyboard path reachable for the first time -- BracketLeft had been an unguarded catch-all sitting above every numeric arm, so none of it had ever run. Newly-live code that has never executed is worth auditing, and dde_live_preview had two defects waiting in it. Both come from the same mistake: the function derived the draw direction from `current_world`, and then wrote its own result back to `current_world`. Each keystroke therefore measured from the previous keystroke's output. Typing "0": the point moves onto the anchor, so the direction becomes atan2(0, 0) == 0. Every later digit draws along +X instead of the cursor ray, and the original direction is unrecoverable. Typing "0" then "5" gave (5, 0) where it should give a point 5 units along the ray. Negative distance: "-5" flips the point 180 degrees, so the next keystroke measures from the flipped ray and the sign cancels itself. "-5" then "-50" landed at +50, not -50. Both reproduced numerically against the original arithmetic before changing anything. The direction is now captured once, on the first keystroke of an entry, and held in DrawingState::dde_ray_deg. It is cleared when the entry commits (Enter) and when backspace empties the buffer, so the next entry re-captures from wherever the cursor is then; DrawingState::default() covers the other resets. The geometry moved to construction_geometry::dde_resolve_point, which takes the ray as a parameter -- that is what makes the bug structurally impossible rather than merely fixed, and it is testable without a Cx. Five tests: the zero case, the negative case, that polar input ignores the ray (it carries its own azimuth), relative-cartesian offsetting, and that Spherical returns None. Negative-tested. Spherical stays unresolved on purpose. It has an elevation component a flat plan preview cannot represent, and projecting it as if it were flat would silently draw the wrong segment. That was already the old behaviour via a bare `return`; it is now explicit in the return type. 690 lib + 154 integration, 0 failed. All nine gates pass.	2026-08-01 04:24:37 +00:00
andodeki	3d7b61730a	refactor(spreadsheet-ui): route undo redo through shared model	2026-08-01 04:16:29 +00:00
nigig-ci	0614a70888	fix(sms): correctness pass on grouping, errors, dates and iOS (Phase C) ... C1 -- one contact appeared as several conversations. populate_display_messages() keyed the group HashMap on the RAW provider address. A Kenyan inbox routinely carries three forms of the same person -- +254712345678, 0712345678, 254712345678 -- depending on whether they were on-net, roaming, or saved in contacts. Each became a separate thread holding part of the history, and a reply went to whichever one happened to be open, so the user's own messages scattered across the duplicates. normalize_number() (last 9 digits) already existed and was already used for contact-NAME lookup; it just was not used for grouping. get_conversation() and insert_sent_message() now match the same way, so a reply joins the existing thread. Alphanumeric senders ("Safaricom", "MPESA") normalise to empty and fall back to the raw address, so they are not all merged into one bucket. C3 -- every JNI failure said "Unknown error". From<jni::errors::Error> mapped everything to Error::Unknown, discarding the payload. A failed send read identically whether the cause was a missing method, a mismatched descriptor, a Java exception or an unreachable JVM. Field diagnosis was impossible -- and this is how the setRepeating signature bug (fixed in A4) stayed invisible. Adds Error::Jni { kind: JniFailure, detail } and classifies. Also fixes sys/unsupported.rs, which returned Unknown for all twelve functions where every other stub backend returns PermanentlyUnavailable, so unsupported targets reported "Unknown error" instead of "not supported here". C4 -- dead branch in show_conversation(). Two blocks; the second ran unconditionally and re-applied the no-search behaviour, making the search branch above it dead. Opening a conversation with an active filter scrolled to the bottom of the UNFILTERED timeline instead of the top of the matches. A merge artifact, invisible unless you read the control flow rather than the surrounding "Mirror Robrix" comments. C5 -- timestamps were wrong outside East Africa. ~160 lines of hand-rolled civil-date arithmetic with a hardcoded UTC+3. The desktop branch attempted to read $TZ but stripped the alphabetic characters and parsed the remainder, so "America/New_York" became "/New_York", failed, and fell through to +3 as well: it could never have worked for any named zone. Deleted in favour of chrono, which was ALREADY a dependency of this crate and already used correctly in conversation_screen.rs. Verified green under TZ=UTC, Africa/Nairobi, America/New_York and Asia/Tokyo. C6 -- iOS thread ids were from the wrong namespace. read_modern_db selected m.handle_id -- a PARTICIPANT id -- and wrote it into SmsMessage.thread_id. But list_thread_messages() filters on chat_message_join.chat_id and read_modern_threads() reports chat.ROWID. Three namespaces, so an id handed out on read never matched the id expected on query: thread navigation on iOS was broken by construction. Now joins chat_message_join and selects the chat id. apple_date_to_ms() also assumed nanoseconds unconditionally; older chat.db revisions store whole seconds in some columns, which divided by 10^9 and rendered as 1970. Now disambiguates by magnitude. C7 -- the bulk path skipped its validation. The app never called send_bulk_sms; it wrote its own loop over send_sms so it could report per-recipient success. That also skipped validate_bulk_send_request, the only check that rejects a whitespace-only recipient inside a batch -- a stray blank line in the recipients box. Rather than give up the per-recipient reporting, the rule moves onto BulkSendRequest::validate() and the caller runs it explicitly. C2 was already fixed in Phase A (A10, persisted id counter). Tests: robius-sms 15 -> 21, nigig-sms 15 -> 19. CI: nigig-sms clippy ratchet 50 -> 49 (C5 removed the dead helpers). Verified: clippy -D warnings clean on host and aarch64-linux-android, nigig-build still builds, cargo deny still passes.	2026-07-31 22:56:08 +00:00
andodeki	b6d81e10fd	refactor(spreadsheet-ui): route autofill reads through shared model	2026-07-31 22:52:35 +00:00
nigig-ci	817ba02625	build: drop the unused robius-sms dependency and its two advisories (Phase B) ... nigig-build declared robius-sms and robius-location and called neither: zero references to robius_sms or robius_location anywhere under nigig-build/src. That dead dependency pulled in robius-sms -> polkit -> gio -> glib -> glib-macros -> proc-macro-error which is the ONLY reason deny-nigig-build.toml carried RUSTSEC-2024-0370 (proc-macro-error, unmaintained) RUSTSEC-2024-0429 (glib VariantStrIter unsoundness) plus an unanswered LGPL-2.1 distribution question about linking polkit into a shipped mobile binary -- all of it for code that never ran. Removing the direct dependency alone was NOT enough, which is the part worth recording. `cargo tree -p nigig-build -i polkit` showed three paths, not one: the direct declaration, and two more through nigig-core and nigig-uikit. Both of those also declare robius-sms and also never use it. All three declarations had to go before polkit left the graph. nigig-core keeps robius-location: unlike the others it genuinely uses it, in src/location.rs. Verified, not assumed: - before: cargo tree -p nigig-build -i polkit resolved, three paths - after: polkit, gio and proc-macro-error no longer resolve at all - cargo deny check -> "advisories ok, bans ok, licenses ok, sources ok" with two fewer ignores (5 -> 3) - nigig-build, nigig-core, nigig-uikit and nigig-sms all still compile - Cargo.lock loses 5 lines Also in this commit: - A CI gate so the declarations cannot come back. Deliberately scoped to robius-sms/robius-location on these three manifests rather than a blanket `cargo machete`: five other unused dependencies exist here (chrono, futures, postcard, rand, serde_json) and a gate that is red on its first run gets switched off. Negative-tested by re-adding the dependency and confirming the gate fails. - Three pages carried the same placeholder string telling the user they were looking at a "RobrixStackNavigationView destination ... just like SMS conversation screens". That is user-visible UI copy, not a comment. Replaced with text describing the page. The identical "This follows the SMS/Home pattern" comment in the same three files now says what the code does instead of naming another module. Note the scope limit: 26 of the 29 crates in this workspace declare robius-sms and never use it. This commit fixes the three that put advisories on nigig-build. The rest are the same latent problem and should be swept separately.	2026-07-31 22:45:58 +00:00
andodeki	276fee245e	refactor(spreadsheet-ui): read rendered cells from shared model	2026-07-31 22:45:24 +00:00
andodeki	b720a166ec	feat(pdf): AcroForm actions and validation; JavaScript refused, not run ... Phase 8 #8 of REVIEWS/DART_PDF_VS_MAKEPAD_PDF_GAP_ANALYSIS.md ("AcroForm full support"). Design and merge criteria in REVIEWS/adr/0012-pdf-acroform-full.md. Form editing already worked. What was missing is everything that makes a real form behave like one. Probing an invoice-shaped document: "qty" required=true /AA present? false "price" required=false /AA present? true "total" required=false /AA present? true -> is any /AA action exposed? no accessor exists -> is /CO exposed? no accessor exists The /AA dictionaries sat in the raw field dictionary, reachable only by a caller who knew to go digging. Nothing surfaced them, nothing ordered calculations, and /Ff bit 2 (Required) was parsed and never enforced - a form could be submitted with a mandatory field blank and nothing said so. THE JAVASCRIPT DECISION The review names JavaScript actions as a prerequisite. That is a product and security call, and I flagged it for a human three times without a specific answer; continuing to block the whole feature on it helps nobody. This takes the reversible option and documents it loudly enough to overrule: JavaScript is parsed, exposed, and NEVER EXECUTED. Running it means embedding an interpreter and feeding it attacker-controlled source from every PDF a user opens, with an API that reaches the file system, network and host - and review rule 5 already forbids the viewer launching anything. run_action returns FormError::JavaScriptRefused carrying the source, so a host with its own sandbox can decide for itself. A later ADR turns a refusal into an execution; nothing has to be un-built. Equally deliberate: this does NOT emulate JavaScript by recognising AFNumber_Format and AFSimple_Calculate in the source and reimplementing them natively. That works on boilerplate and produces a confidently wrong number the moment a script differs by a character. WHAT IS IMPLEMENTED - /AA parsed into typed actions across all 14 triggers, on fields and widgets, with indirect action dictionaries resolved. - /CO calculation order exposed in document order. - Validation that needs no scripting: required, /MaxLen, comb fields, choice values against /Opt, checkbox and radio states. - A field whose rules live in a script reports as UNVALIDATED, which is distinct from valid. Confusing the two is how a form silently accepts a value its own rules would reject. - /SubmitForm parsed into URL, flags and fields and returned as data. This crate opens no sockets. Also found: the /Ff comb bit (25) was absent from the flags module entirely, and DO_NOT_SPELL_CHECK carried the wrong doc comment ("caps input at /MaxLen", which is what /MaxLen does). 4 corpus fixtures, 13 acceptance tests, 20 unit tests. Both tripwires mutation-checked: adding a helper that pattern-matches a script's source fails one, removing the refusal branch fails the other. TEST_TARGET=pdf 575 -> 607, TEST_TARGET=pdf-ui 619 -> 651. rustfmt and clippy -D warnings clean.	2026-07-31 22:41:50 +00:00
arena-agent	9f0765c6e1	feat(doc): pointer-driven in-cell selection, char-exact caret parking ... Cell taps parked the caret at the end of the cell text no matter where the pointer landed, and in-cell character selection was keyboard-only. Cells now handle the full desktop pointer surface: - `cell_char_offset_at` maps a layout-space x to the nearest char offset on the cell's fixed grid (midpoint-split 7px cells, clamped to the text end) — one convention for taps, drags and the caret rect. - Taps (desktop FingerDown and mobile short tap) park the cell caret on the char under the pointer instead of always at the text end. - A desktop press arms the in-cell drag anchor; a drag spans a character selection clamped to the pressed cell — crossing an edge clamps at the text ends instead of jumping cells — and reuses the existing span machinery, so typing/Backspace/styles consume the dragged span exactly like a keyboard-spanned one. Touch keeps its passive caret and long-press cell-range path. - Shift+tap extends a live in-cell selection to the tapped offset, mirroring the text-block shift-press. - Draw-loop fix for armed anchors across real frames: a collapsed anchor (fresh press, or a selection stepped back onto itself) draws nothing but STAYS armed — pointer drags and further Shift steps extend from it; only a stale cell (undo) drops it. Previously the highlight pass cleared collapsed anchors between the press and the first drag move, which would have silently disarmed desktop drags on real frame clocks. 6 new tests: offset math + clamps (pure), tap char parking, drag span + type-over, backward drag, edge clamping with cell identity, Shift+tap extension. nigig-build 698 -> 704.	2026-07-31 22:40:24 +00:00
arena-agent	4daaacaed2	feat(doc): in-cell character selection for table cells ... Cell editing knew caret movement, whole-cell styles and mergeable cell ranges, but no way to select part of a cell's text — Shift+Arrow inside a cell moved the caret plainly. Cells now span a real character selection: - `ProjectionSession::cell_text_anchor` (anchor offset; the cell caret is the focus). Shift+Arrow inside a cell begins/extends the span on the shared session; at the cell edge the span ends and Shift promotes to the mergeable cell range exactly as before, so the two selection kinds compose instead of colliding. - Edits consume the span: typing (`cell_text_replace_range` from the TextInput path) replaces it, Backspace/Delete remove it, the caret lands on the splice point, and undo restores the prior whole-cell text through the existing SetTableCell compensation. - Style toggles (Ctrl/Cmd+B/I/U and the toolbar) now target the active in-cell selection instead of the whole cell, flowing through the engine span API added with cell style runs; without a span they keep styling the whole cell. Styling keeps the selection armed, matching the text-block behavior. - Rendering: one highlight rect (`cell_text_span_rect`) over the selected chars on the cell's fixed text grid, re-resolved against the layout every frame; stale cells undo-clear like the cell caret. - Collapse rules mirror the existing cell-range discipline: plain arrows, taps (desktop and mobile), cell hops, Return-row insertion, range promotion and staleness all clear the anchor. 8 new tests: replace-range/clamp/unicode helper coverage, span rect geometry, runtime Shift-span, edge promotion to the cell range, type-over, backspace-over, selection-scoped Ctrl+B, and plain-move collapse. nigig-build 690 -> 698.	2026-07-31 22:27:52 +00:00
nigig-ci	0ed64c0435	fix(sms): send long messages whole, and confirm before bulk (A5, A7, A8) ... A5 -- long messages were silently truncated. send_text_message() called SmsManager.sendTextMessage unconditionally. That API is only defined for a body that fits one PDU: 160 GSM-7 characters, or 70 once anything forces UCS-2. Past that the behaviour is carrier- and OEM-dependent -- silent truncation, silent failure, or an exception -- and the UI reported "Sent" regardless, because a JNI call returning cleanly only means the call was made. Now uses divideMessage() + sendMultipartTextMessage() when the body needs more than one part, so the recipient's handset reassembles it. Adds segment_count(), which computes encoding and segment count on any host so it is unit-testable and usable by UI. Correct GSM-7 modelling matters here and is not intuitive: - the extended characters ^ { } \ [ ] ~ | € cost TWO septets each - concatenation costs 7 septets per part, so the limit drops from 160 to 153 (and 70 to 67 for UCS-2) - non-BMP characters such as emoji are surrogate pairs and cost two UTF-16 units - e/a/o/n/u with diacritics ARE in GSM-7. My first version of the boundary test assumed é forced UCS-2 and failed; Swahili, French and German text still bills at the 160-char rate. Arabic and emoji do not. A7 -- bulk send had no confirmation. One tap on "Send SMS to Selected", one tap on Send, and N real, billed, irreversible messages went out. For a feature whose purpose is mass-messaging a scraped business directory, that is a financial-harm defect rather than a UX gap. Send now arms a confirmation quoting SEGMENTS, not messages, because segments are what the user pays for and the number is surprising: one emoji in the body forces UCS-2 and can turn "200 messages" into 800 paid segments. Editing the body or the recipient list re-arms the prompt, so a confirmation cannot be inherited by different content. A8 -- SCHEDULE_EXACT_ALARM was neither requested nor documented. Android 12+ refuses exact alarms without it, and it is a special-access permission: a runtime prompt cannot grant it, the user must enable "Alarms & reminders" in Settings. Without it scheduled sends are subject to Doze batching. Documented in the crate docs and README, along with two things that were not written down anywhere: Ok from send_sms means "handed to the platform", NOT delivered (both PendingIntents are null, so nothing can report back); and callers are billed per segment. Verified: robius-sms 15 tests pass (8 new for segmentation), nigig-sms 15 pass, clippy -D warnings clean on host and aarch64-linux-android, nigig-sms clippy ratchet holds at 50, gates and supply-chain green.	2026-07-31 22:22:27 +00:00
nigig-ci	6bb135872a	fix(sms): stop the cursor loop aborting the process (A1, A2) ... Three defects in the content-provider read path, all of which abort rather than return an error, and all of which were duplicated because inbox.rs and thread.rs each carried their own byte-identical copy of the column helpers (~75 lines). A1 -- local reference table overflow. Every get_*_column() called env.new_string(name) to resolve the column by name, and getString returned another local ref: ~10 JNI local references per message row. Local refs are not freed when the Rust value drops; they live until the native method returns to the JVM, which here is the end of the whole cursor loop. ART's default local reference capacity is 512, so the table overflowed at roughly 45-50 messages -- and overflow is a hard abort ("local reference table overflow"), not an Err. Any real inbox has hundreds to thousands of messages. I consider this the most likely single source of field crashes in this crate. Fixed twice over: column indices are resolved ONCE per query into a struct instead of per row per column, which removes the new_string churn entirely; and each row is read inside env.with_local_frame(), so whatever a row does allocate is released when that row finishes. A2 -- pending exceptions were never cleared. My assessment said this crate does no exception checking. That was WRONG, and the correction matters: jni-rs 0.21 expands every checked call through check_exception!, which calls ExceptionCheck and returns Err(Error::JavaException). The actual defect is that nothing ever CLEARS it. ExceptionClear appears in exactly one place in jni-rs -- the public exception_clear() -- and this crate never called it. So the Err propagated while the exception stayed pending on the thread, and the next JNI call made on that thread aborted the process. A SecurityException from a revoked READ_SMS, or an IllegalStateException from a stale cursor, therefore produced a tidy Err and then killed the app somewhere unrelated. Every error path out of these functions now runs clear_pending_exception(), which describes the exception to logcat and leaves the thread clean. Cursor leak -- `?` inside the loop skipped the close() at the end of the function, leaking the Cursor and its CursorWindow (typically a 2 MB ashmem region) on every error. CursorGuard closes it on all paths. Also removes the duplicated helpers: both files now share sys/android/cursor.rs, so a fix here cannot land in one copy and miss the other. Verified: check and clippy -D warnings clean on host and aarch64-linux-android. NOT verified on a device. The abort threshold, the frame capacity and the exception paths need an emulator or handset with a populated inbox to confirm, and there is still no CI runner registered on this repo.	2026-07-31 22:22:27 +00:00
andodeki	a994213e8b	feat(pdf): tagged structure tree, and the BMC bug that turned red green ... Phase 8 #7 of REVIEWS/DART_PDF_VS_MAKEPAD_PDF_GAP_ANALYSIS.md ("PDF/UA structure tree"). Design and merge criteria in REVIEWS/adr/0011-pdf-structure-tree.md. Investigating the accessibility gap surfaced four defects in the marked-content operators the structure tree depends on. The first is not an accessibility problem at all. 1. BMC never parsed, and corrupted the colour of everything after it. The dispatcher matched b'B'+b'M' only when the third byte was a delimiter; BMC's third byte is 'C', so the arm never fired. Because the operator was never recognised it never CLEARED ITS OPERAND, and the leftover /Tag shifted the operands of whatever came next: 1 0 0 rg -> RgbFill(1.0, 0.0, 0.0) red /Span BMC 1 0 0 rg -> RgbFill(0.0, 1.0, 0.0) green Tagged documents are precisely the ones containing BMC, so the documents that tried hardest to be accessible rendered wrong colours. This is the fifth instance of the operator-shadowing family already fixed for cm, rg, gs, b/b* and end-of-stream text operators. ADR 0009's every_multi_char_operator_parses_as_itself test exists to stop exactly this - and would have caught it, except BMC was one of two operators excluded from its table as "genuinely unimplemented". Excluding a known-broken operator from the test whose job is finding broken operators is how it survived. The exclusion list is gone. 2. BDC discarded its property list, which carries /MCID - the only link between a run of page content and the structure element describing it. Without it a tree can be parsed but never attached to anything. 3. The op produced by BDC was named MarkContentBmc, and BMC produced nothing. The names were the wrong way round, which is how the missing arm survived review: the enum looked like it had a BMC case. 4. Found while fixing 2: the content lexer had no dictionary support at all. It read `<` as a hex string without checking for a second `<`, so `<</MCID 0>>` parsed as the string "0C0D0". Content streams now parse direct objects properly, bounded at 16 levels; a single `<` is still a hex string and a test pins that. On top of that, new pdf-document/src/structure.rs: /StructTreeRoot, /StructElem trees, /RoleMap resolution, depth-first reading order, /Alt, /ActualText, /E, /Lang, and MCID-to-element lookup. Cycles in /K are cut at the first repeat and reported by object number rather than expanded to the depth bound. Accessibility findings are mechanical checks reported as findings, NOT a conformance verdict: there is no is_pdf_ua and no ComplianceReport, and a mutation-checked tripwire test fails if either appears. Real PDF/UA conformance needs human judgement - whether /Alt text is accurate is not mechanically decidable - so claiming it from six checks would be exactly the overclaim this codebase keeps removing. 7 corpus fixtures, 14 acceptance tests, 22 unit tests, and a parse_content_dict fuzz target for the new object parser. TEST_TARGET=pdf 536 -> 575, TEST_TARGET=pdf-ui 580 -> 619. rustfmt and clippy -D warnings clean.	2026-07-31 22:19:45 +00:00
andodeki	ad74fb7cd2	refactor(spreadsheet-ui): route grid edit reads through shared model	2026-07-31 22:16:57 +00:00
andodeki	1f67c13dcd	refactor(spreadsheet-ui): read grid values from shared model	2026-07-31 22:14:45 +00:00
arena-agent	df2471105b	feat(doc): CRDT-native table cell style runs ... Cell text was plain LWW strings, so style toggles were silently disabled whenever the caret sat in a table. Cells now carry styled runs end to end: - Engine: new `SetTableCellStyle` / `ClearTableCellStyle` / `RestoreTableCellStyle` ops. Ranges are char-offset snapshots replayed over the settled LWW cell text in operation order (newer patches win on overlap, spans clamp when text shrinks but do not stretch when it grows). Undo tombstones the style op exactly like a merge split, keeping overlapping later styles intact and undo/redo convergent across peers. `ProjectedTable::cell_runs` mirrors `cells` — every projected cell has at least one default-styled run — built by the new `apply_style_offset_range` helper, with `TableCellRef` addressing cells in the controller API. - Layout: `ProjectedTableCellLayout.runs` mirrors the projection runs for the renderer. - Renderer: `draw_table_projection` draws cell text run by run through the same regular/bold/italic/bold-italic pens as block text, advancing on the shared fixed char grid. - Widget: `toggle_selection_style` routes by session — a parked cell cursor styles the whole cell (cell text has no selection ranges yet), a text selection styles its range — so Ctrl/Cmd+B/I/U and the toolbar buttons now work in tables. Undo/redo round-trips like any other op. 9 engine tests (split/merge/clamp/overlap/toggle/reject/undo/convergence), 5 widget tests (layout runs, Ctrl+B whole-cell, undo/redo, toolbar path, empty-cell no-op). doc-engine 53 -> 62, nigig-build 685 -> 690. The doc README's "cell text carries no style runs yet" gap is closed and the doc-engine projection invariants document the new semantics.	2026-07-31 22:09:18 +00:00
andodeki	dc5950b65f	refactor(spreadsheet-ui): share workspace model with grid	2026-07-31 22:08:01 +00:00
andodeki	6dc2998275	refactor(spreadsheet-ui): route grid commands through shared model	2026-07-31 21:52:40 +00:00
andodeki	6c3e7683dc	feat(spreadsheet-ui): attach grid to shared workspace model	2026-07-31 21:50:32 +00:00
nigig-ci	d96f8301ef	fix(sms): make scheduling actually work (A4, A9, A10) ... Scheduled SMS could never have sent a single message. Four independent defects in one code path, all in code with no tests. A4 -- every request was rejected before reaching the platform. `ScheduleRequest.interval_ms` was a bare i64 and the validator required `interval_ms > 0`, but "send once" is the only mode the UI offers, so sms_schedule_page.rs passed `interval_ms: 0`. Result: 100% of scheduled messages failed with InvalidInput. The user saw "Scheduled: 0, Failed: N" and no reason. interval_ms is now Option<i64>: None = send once, Some(n>0) = repeat. The validator moves onto ScheduleRequest::validate() so it can be tested on any host -- the old copy was behind #[cfg(target_os = "android")], which is part of why a defect this total went unnoticed. Wrong JNI signature -- found while fixing the above, not in the original audit. setRepeating was invoked with the descriptor "(IJLandroid/app/PendingIntent;)V": three parameters, four arguments. AlarmManager.setRepeating is (int, long, long, PendingIntent), i.e. "(IJJLandroid/app/PendingIntent;)V". Even had A4 not rejected everything first, this would have thrown NoSuchMethodError at the JNI boundary -- and with no exception checking (A2, still open) that is a process abort, not an Err. A9 -- alarms did not wake the device. The type argument was hardcoded to 0 (AlarmManager.RTC). RTC does not fire while the device sleeps, so a 03:00 schedule waited until the user next picked up the phone. Now RTC_WAKEUP (1), as a named constant. A10 -- batches silently destroyed each other. Ids were `1000 + index`, so a second batch reused 1000..1000+n. PendingIntent.getBroadcast matches on request code and the crate passes FLAG_UPDATE_CURRENT, so the new alarm replaced the old one; store_schedule keys SharedPreferences on the same id, so the stored recipient and body went too. next_schedule_id() now allocates from a counter persisted under app_data_dir, because the collision has to be avoided across restarts, not just within a run. Persistence: SharedPreferences has no null long, so None is stored as ONE_SHOT_SENTINEL (0) and mapped back on load. Anything <= 0 reads back as None rather than being trusted as an interval -- a 0 interval would make setRepeating fire in a tight loop. Tests: robius-sms had NO tests. It now has 7, covering the validator's whole contract. accepts_the_one_shot_request_the_app_actually_builds constructs the exact shape sms_schedule_page.rs sends and fails against the old validator. Verified: robius-sms 7 tests pass, nigig-sms 15 pass, clippy -D warnings clean on host AND aarch64-linux-android, gates and supply-chain green. Still open on this path: A2 (no JNI exception checking) and SCHEDULE_EXACT_ALARM is neither requested nor documented, so exact delivery is not guaranteed on Android 12+.	2026-07-31 21:49:43 +00:00
Arena Bot	ee909a977c	fix(ui): restore missing metric_title and metric_value to CostEstimatorMetric instances	2026-07-31 21:48:53 +00:00
andodeki	f529333f88	feat(spreadsheet-ui): add shared workspace model handle	2026-07-31 21:36:53 +00:00
nigig-ci	5cfeec26ff	fix(sms): recover from mutex poisoning instead of panicking (A6) ... Every access to the SMS contact-cache statics used `.lock().unwrap()` -- 25 call sites across four files, 21 of them in conversations_list.rs. `Mutex::lock()` returns Err only when a previous holder panicked while the guard was alive. `.unwrap()` on that converts one transient panic into a permanent one: from then on EVERY later access to the same mutex panics. The cache is written from a spawned worker thread (start_contact_lookup_worker) and read from draw_walk, so a single panic in the worker left contact resolution broken for the rest of the process, surfacing as a panic in the renderer with no connection to the original fault. For this data, aborting is the wrong trade. The protected values are a name cache, a lookup queue and an in-flight flag. None has an invariant that a mid-update panic could break in a way that makes the data unsafe to read; the worst case is a half-populated cache, which self-corrects on the next lookup. Adds sms_frame/lock_ext.rs with LockRecover::lock_recover(), which recovers the guard via PoisonError::into_inner(). All 25 sites now use it. Note this crate already knew the answer and applied it inconsistently: companies_list.rs used `if let Ok(mut s) = ..lock()` in two places, which is poison-safe but silently DROPS the write. lock_recover() keeps the update. Tests: three, including stays_usable_across_repeated_access_once_poisoned, which poisons a mutex from a panicking thread and then performs 100 further accesses -- the exact failure mode described above, and one the old code could not survive past the first. CI: the .lock().unwrap() step goes from a ratchet at 19 to a HARD gate, since production code is now at zero. lock_ext.rs is excluded: its tests must poison a mutex to observe the Err, which needs a real .lock().unwrap(). Verified: 15 tests pass (was 12), clippy 50/50, hard gate passes.	2026-07-31 21:33:34 +00:00
nigig-ci	00290ad682	fix(sms): stop truncate_preview panicking on multi-byte text (A3) ... truncate_preview() compared `trimmed.len()` -- BYTES -- against PREVIEW_MAX_CHARS, then sliced the string at that byte offset: if trimmed.len() <= PREVIEW_MAX_CHARS { .. } else { let mut end = PREVIEW_MAX_CHARS; // 120, bytes if let Some(pos) = trimmed[..end].rfind(..) { .. } // panics format!("{}…", &trimmed[..end]) // panics } Slicing a &str at a byte offset that is not a character boundary panics. This function runs inside draw_walk, once per visible row per frame, over message bodies that arrive from anyone who knows the device's number -- so a single such message took down the conversation list on every frame until it was deleted. Why it survived review, and why my own first repro was wrong: it does NOT fire on uniform multi-byte text. 120 is divisible by 2, 3 and 4, so a body of pure emoji or pure Arabic happens to land exactly on a boundary. I initially "confirmed" the bug with 40 emoji and got a clean pass. It needs MIXED text -- any misaligning run of ASCII before the multi-byte part -- which is the normal shape of real traffic: "a" + 40 emoji panicked "Hi " + 40 emoji panicked "Confirmed. Ksh1,000 sent to JOHN DOE ..." + 🎂 panicked "x" + 130 é panicked The fix counts characters via char_indices().nth(), and every offset it slices at now comes from char_indices() or rfind() on a &str, both of which return character-start offsets by construction. Two behaviour changes fall out of counting correctly, both fixes: - Bodies under 120 CHARACTERS are no longer truncated. Three of the four cases above are 41-78 chars; they were being cut only because 120 bytes of emoji is 30 characters. A real M-Pesa confirmation with a trailing emoji now displays in full. - A long first word no longer collapses to a bare "…": the whitespace break is only honoured when it leaves something to show. Tests: 10 new unit tests, including never_panics_for_any_prefix_alignment, which sweeps a 0-7 char ASCII prefix across 2-, 3- and 4-byte fillers so the cut offset lands at every possible position inside a character. That sweep fails against the old implementation. Lints: sms_utils.rs moves from #![warn] to #![deny] for clippy::indexing_slicing and clippy::string_slice. The two remaining slices carry a scoped #[allow] with the boundary proof written out -- clippy cannot distinguish a proven-safe offset from an arbitrary one, so the exemption is explicit and argued rather than a blanket mute. CI: the byte-offset gate stays pinned at 2 (those two proven-safe sites) with a comment recording that the real guarantee is now the deny plus the tests, not the grep. The clippy ratchet returns 52 -> 50, since the two string_slice reports Phase 0.7 surfaced are gone. Verified: 12 tests pass (was 2), clippy 50/50, gates 19/19 and 2/2, metadata --locked clean.	2026-07-31 21:29:07 +00:00
andodeki	4b0d44fb47	docs(spreadsheet-ui): describe workbook data boundary	2026-07-31 21:25:20 +00:00
andodeki	d6f232da92	test(spreadsheet-ui): cover invalid workbook payloads	2026-07-31 21:20:31 +00:00
andodeki	6a3d79830b	feat(spreadsheet): report workbook deserialization failures	2026-07-31 21:00:21 +00:00