698 commits

This branch

This branch

All branches

Author	SHA1	Message	Date
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
andodeki	52f7358f51	test(spreadsheet-ui): cover batched adapter mutations	2026-07-31 20:53:26 +00:00
nigig-ci	486fa5f168	ci(sms): finish Phase 0.7 and close a false negative in the slice gate ... Two defects in my own Phase 0 work, both found by re-checking the plan's task list against what actually shipped. 1. Task 0.7 was never done. The previous commit's subject line claimed "Phase 0.2-0.7" but no lint attribute was ever added. sms_utils.rs now carries module-level #![warn(clippy::indexing_slicing)] #![warn(clippy::string_slice)] This module formats untrusted text -- SMS bodies straight off the wire -- and every function in it runs inside draw_walk, once per visible row per frame. warn rather than deny: the two known sites are still present and deny would make the crate fail to build. The point is that a THIRD site cannot appear silently. Raise to deny when A3 lands. 2. The byte-offset slice gate had a false negative. It required a leading `&`: &[A-Za-z_][A-Za-z0-9_]*\[\.\.[A-Za-z0-9_]+\] truncate_preview() contains two slices one line apart: 193: if let Some(pos) = trimmed[..end].rfind(..) <- MISSED 196: format!("{}…", &trimmed[..end]) <- caught Line 193 is autoref'd, panics identically, and being first is the one that actually fires. The gate reported "1" and looked audited while missing the instance that runs. Pattern no longer requires the `&` and also covers `[n..]` and `[..=n]`; baseline 1 -> 2. The clippy ratchet moves 50 -> 52: the two new diagnostics are exactly the clippy::string_slice reports for those two lines, which is the intended effect of 0.7 -- A3 is now visible in CI instead of only in a markdown file. Verified with the pinned toolchain (1.97.1): gates: lock().unwrap() 19/19 PASS, byte-slice 2/2 PASS robius-sms: clippy -D warnings PASS, test PASS nigig-sms: check PASS, test 2 passed, clippy ratchet 52/52 PASS supply-chain: metadata --locked PASS, lock unchanged, whitespace PASS repo-hygiene: markers PASS, workflow YAML PASS, 40-char SHA PASS	2026-07-31 20:50:58 +00:00
nigig-ci	76e4d0c391	ci(sms): add the SMS workflow (Phase 0.2-0.7) ... The SMS stack had no CI of any kind. crates/robius-sms (2,019 LOC) and crates/apps/nigig-sms (5,706 LOC) shipped with two tests, both of which assert derived trait impls (BulkSubTab::default() and a PartialEq) and neither of which touches SMS. That is 7,725 lines with no automated signal, for a feature whose job is to send real, billable messages. Five jobs: gates Two source scans, both for defect classes already present here and both invisible in review. robius-sms check + clippy -D warnings + test, host. android The job that matters. Everything in sys/android/ -- all ~600 lines of JNI, every function this crate actually performs on a device -- is behind #[cfg(target_os = "android")] and is not compiled by any host job. The three clippy errors fixed in the preceding commit were invisible until this job existed. nigig-sms check + test + a scoped clippy ratchet. supply-chain --locked lockfile, whitespace. Only enforceable because the preceding commit tracked Cargo.lock. The android job pins JDK 17 via setup-java. build.rs compiles two .java files and dexes them with d8, and d8 (build-tools 34) rejects class file major version > 61. A runner defaulting to JDK 21 fails inside d8 with "Unsupported class file major version 65", which reads like a toolchain bug rather than a JDK mismatch. Reproduced locally on 21, green on 17. Three steps are RATCHETS against a recorded baseline rather than hard gates, because each has pre-existing violations whose fixes belong to later phases: .lock().unwrap() 19 lines. Poisoning one mutex bricks contact resolution for the process lifetime. byte-offset slicing 1. truncate_preview() panics on any inbound SMS containing emoji or non-Latin text, per visible row per frame. nigig-sms clippy 50. All mechanical, but `clippy --fix` cannot apply them through Makepad's script_mod! proc macro, so they need hand edits. 34 of the 50 are dead-code reports for the duplicated contact subsystem in inbox/sms_screen.rs. A ratchet fails if the count RISES, and also if it FALLS without the baseline being lowered, so progress cannot be silently undone. The alternative -- a hard gate red on its first run -- gets switched off, which is the reasoning already recorded in doc-engine.yml for not gating cargo fmt. Clippy for nigig-sms is filtered by package id: a plain -D warnings would also fail on ~89 pre-existing warnings in nigig-core, nigig-uikit and matrix_client, which are out of scope here. --no-deps does not help, since those are workspace members rather than registry deps. Every job was executed locally against this tree before commit: toolchain 1.97.1 per rust-toolchain.toml, JDK 17, SDK platform 34 / build-tools 34.0.0. gates PASS, robius-sms PASS (0 tests), android PASS, nigig-sms PASS (2 tests), supply-chain PASS.	2026-07-31 20:06:15 +00:00
nigig-ci	7db530b374	fix(sms): clear the three clippy errors on the Android target ... These are only visible when cross-compiling: a host build of robius-sms compiles sys/linux.rs, a stub whose every function returns PermanentlyUnavailable, so none of sys/android/ is type-checked at all. Host clippy was already clean; the Android target was not. receivers.rs unnecessary `unsafe` block. The block wrapped nothing that needs it -- taking `&mut env` and calling a safe Rust fn -- inside an already-`extern "C"` function. Removing it does not change what the JNI entry point does; it stops the block from implying the body has been audited for an invariant it does not have. schedule.rs redundant closure |env, activity| load_schedules(env, thread.rs activity) -> load_schedules. All three are mechanical. No behaviour change. Verified with the pinned toolchain (1.97.1), JDK 17, SDK 34: cargo clippy -p robius-sms --all-targets -- -D warnings OK cargo clippy -p robius-sms --target aarch64-linux-android -- -D warnings OK	2026-07-31 20:06:15 +00:00
nigig-ci	c0143a3af8	build: track the workspace root Cargo.lock (Phase 0.1) ... CI already runs with --locked: nigig-build.yml asserts `cargo metadata --locked` and `git diff --exit-code -- Cargo.lock`, and doc-engine.yml builds every target with --locked. None of that can hold while the root lockfile is gitignored -- `--locked` fails outright with no lockfile to check against, so in practice every build re-resolved and a transitive dependency could change under CI without any commit recording it. The nigig-build workflow comment already claimed this was done ("Blocked until Cargo.lock was committed in Phase 0.2"); it was not. This commits it. The ignore rule becomes `**/Cargo.lock` + `!/Cargo.lock` so the root lock is tracked while incidental nested locks stay ignored. The three payment-crate locks keep their existing negations and stay tracked. Generated with the pinned toolchain from rust-toolchain.toml (1.97.1) against makepad rev a79f0dce; 566 packages. Verified `cargo metadata --locked` exits 0.	2026-07-31 20:06:15 +00:00
andodeki	e45a717ce7	fix(pdf-ui): enable the makepad-widgets test feature so ui.rs compiles ... 456cfa5 rewrote tests/ui.rs to import makepad_test through the makepad-widgets re-export, but did not add the `test` feature that gates that re-export, so the pdf-ui target stopped compiling: error[E0432]: unresolved import `makepad_widgets::makepad_test` note: the item is gated behind the `test` feature Enabling the feature alone is not sufficient. The `#[makepad_test]` attribute expands to an absolute `::makepad_test::` path, which resolves only if the crate is also a direct dependency: error[E0433]: cannot find `makepad_test` in the crate root So both are needed, and the manifest now says why - the direct dev-dependency looks redundant next to the re-export and would otherwise be an obvious thing for someone to delete. crates/apps/map keeps the same pair for the same reason. TEST_TARGET=pdf-ui 580 passing (was: failed to compile).	2026-07-31 20:02:29 +00:00
andodeki	e4a0c0a79e	feat(pdf): read signatures, and fix a third ObjRef-destroying resolve ... Phase 8 #6 of REVIEWS/DART_PDF_VS_MAKEPAD_PDF_GAP_ANALYSIS.md ("Signatures"). Design and merge criteria in REVIEWS/adr/0010-pdf-signatures.md. Two defects, and the first is not about signatures at all. 1. acroform() dereferenced /AcroForm with self.resolve(), which recurses. That replaced every /Fields [5 0 R] entry with an inline dictionary, so AcroForm::walk saw node.as_ref() == None, decided the field had no identity to key an edit on, and dropped it. The form came back EMPTY rather than wrong, which is indistinguishable from a document with no fields, so nothing announced the loss. This is the third appearance of one mistake: page_annotations once destroyed every annotation's obj_ref the same way, and extract_xobjects resolved a reference then asked the resolved object for as_ref(), leaving every page's XObject map empty. It was invisible because both existing fixtures declare /AcroForm as an INDIRECT reference, where only one level is dereferenced and the refs survive. A direct /AcroForm dictionary - equally legal - hits it. The new fixture uses one deliberately; reverting the one-line fix fails 9 of the 12 new acceptance tests. 2. Nothing read signatures. FieldType::Signature was classified and then ignored; /ByteRange, /Contents, /SubFilter and /DocMDP appear nowhere in the codebase. A signed contract was presented exactly like an unsigned one. New pdf-document/src/signature.rs reads the signature dictionary and checks BYTE-RANGE INTEGRITY, which needs no cryptography and catches the common real-world tampering: whether the signed range reaches the end of the file. A signature that stops short leaves appended bytes uncovered, which is exactly how an incremental-update attack hides content behind a signature that still verifies. Cryptographic verification is NOT implemented and cannot be faked: VerificationStatus has no Valid variant. That is enforced by the type, not by convention, because the failure mode for a signature feature is not "it doesn't work" - it is a green tick beside a document nobody checked. A test asserts the capability's absence so adding Valid without the cryptography breaks the build rather than shipping a false tick. Signing is out of scope entirely: no private keys in this crate. Also verified ADR 0003's claim that an append-only save preserves a signed byte range, byte for byte, rather than leaving it asserted. Implementation bug worth recording: /Contents was initially hex-decoded, but the COS lexer already decodes <...>. Running it twice on the common 128-zero-byte placeholder - which contains no hex digits - produced an EMPTY vector, silently discarding the signature blob while every other field looked right. Caught by asserting the blob is non-empty rather than asserting the parse returned Ok. 6 corpus fixtures, 12 acceptance tests, 28 unit tests, and a parse_signature fuzz target because /ByteRange is four attacker-controlled integers used to index the file. TEST_TARGET=pdf 497 -> 536 passing. rustfmt and clippy -D warnings clean.	2026-07-31 20:02:29 +00:00
andodeki	d6b35d7989	test(spreadsheet-ui): add headless unit target	2026-07-31 19:57:04 +00:00
Arena Agent	5e714577fb	ci: require full 40-character SHAs for git dependency revs ... Upstream adopted the makepad fork fix (8fdff3f) but pinned it as `rev = "a79f0dc"` -- a 7-character abbreviation. The pinning gate passed, because it only checked that `rev = ` was present at all. Its own error message has said "Add rev = \"<full-40-char-sha>\"" since it was written, without ever enforcing it. An abbreviated rev resolves only while no other object in the repository shares its prefix. That is a property of the current object count, not a guarantee -- it is why git's own auto-abbreviation length grows with a repo. A short pin therefore degrades on its own over time, and someone who can push to the fork can attempt to manufacture a colliding prefix. For a dependency that executes at build time, that is a supply-chain weakness rather than a style preference. Checked before assuming: a79f0dc currently resolves uniquely in the fork (exactly one matching object), so nothing is broken today. This closes it while it is still cheap. - All 34 manifests expanded to the full SHA a79f0dce4d477e2232344facca0798d3f25043ec. Cargo.lock is unchanged by the expansion, confirming it is the same commit and purely notational. - The gate now also rejects any rev that is not exactly 40 hex chars. Negative-tested: restoring the 7-char form makes it fire. 685 lib tests pass; all nine gates pass.	2026-07-31 19:53:49 +00:00
andodeki	456cfa5a68	fix: use re-exported makepad-test from makepad-widgets ... Remove direct dependencies on makepad-test and use the re-exported version from makepad-widgets instead. This avoids path dependency issues and follows the correct pattern for using Makepad crates. Changes: - Add 'test' feature to makepad-widgets dependencies - Remove direct makepad-test dependencies - Update imports to use makepad_widgets::makepad_test Affected crates: - crates/apps/map - crates/apps/pdf/pdf-makepad - crates/apps/spreadsheet/spreadsheet-ui	2026-07-31 19:49:54 +00:00
andodeki	470913b7bf	fix(spreadsheet-ui): pin working Makepad fork revision	2026-07-31 19:46:07 +00:00
andodeki	8fdff3ff55	Update makepad fork to a79f0dc (remove duplicate dependencies) ... Commit a79f0dc fixes the duplicate dependency declarations that were causing TOML parsing errors. This is the correct commit to use after the parallel fixes in 5eda8056 and 11375214. All 34 Cargo.toml files updated to reference the correct commit.	2026-07-31 19:43:08 +00:00
Arena Agent	a0dbd192c1	ci: add an unfiltered repo-hygiene workflow ... Every workflow in .forgejo/workflows is scoped with `paths:`. That is right for build and test jobs -- no reason to compile the CAD module because a payment file moved -- but it leaves a structural hole: a commit touching only unfiltered paths runs no checks at all. Commit 8c9ccb9 fell straight through it, pushing 30 unresolved conflict-marker lines across five files. The worst of them was .forgejo/workflows/nigig-build.yml itself: with markers in it the file is not valid YAML, so all seven CAD gates silently stopped running. A workflow that does not parse does not fail -- it does not run, which is strictly worse than a red build because nothing announces it. `git diff --check` would have caught this and was already a step. It was in the file the same commit broke, and only ran for that workflow's filtered paths. So this workflow has no path filter, no toolchain dependency and no network dependency -- it cannot be knocked out by an unrelated build break -- and it validates the CI configuration itself: 1. No conflict markers anywhere in the tree. 2. Every workflow file parses as YAML and has a top-level `jobs:`. 3. Whitespace errors. Verified against the real failure, not a synthetic one: checked out 8c9ccb9 and confirmed check 1 reports all 30 marker lines and check 2 names both unparseable workflows. Also probed for false positives -- `>>`/`<<` shift operators, `// =======` comments and a "=======" string literal do not trip it, because the patterns are anchored to column 0 and the closing marker requires the trailing space git writes. Also fixes the fifth file from that commit, which I missed while repairing the others because I only grepped .rs and .yml: ARCHITECTURE.md still had two live conflicts on main. Both were stale-vs-current versions of my own lines; kept the current text. While there, refreshed every LOC figure in the file table from the actual files -- 14 of them were stale, workspace.rs by 64 lines.	2026-07-31 19:41:10 +00:00
Arena Agent	80425bbfb8	fix: repair the makepad fork and unblock the build ... The repository has been uncompilable since the d6d1f99c fork bump. Root cause was in gitdab.com/andodeki/makepad, not here, so the fix went there first: commit 5eda8056 on portallist_flow_adaptive_view. TWO defects, both introduced by the "Update fork to upstream dev 5d4483f" merge, both pure losses rather than intentional changes: 1. widgets/Cargo.toml: the makepad-gltf / makepad-csg / makepad-test dependency lines were relocated from [dependencies] to below [features]. Cargo then parses each as a feature whose value should be an array, giving "invalid type: map, expected a sequence", and the gltf/csg/test/maps features cease to exist. 2. widgets/src/lib.rs: the feature-gated re-export block for those same crates (plus makepad_fast_inflate and makepad_mbtile_reader) was deleted outright. Fixing only the manifest surfaced this as "no `makepad_csg` in the root". Both restored verbatim from 2c5cd97, the last rev that resolved. Neither is a judgement call: the moved lines are byte-identical and the deleted block is copied back unchanged. This repo is then repinned from d6d1f99c to the fixed rev, full 40-char SHA per the pinning convention CI enforces. Verified end to end after removing the local git redirect used during development, so this resolves against the real remote: cargo metadata resolves nigig-build --lib 685 passed cad_integration 154 passed spreadsheet-engine 225 passed doc-engine 53 passed nigig-map (maps feature) compiles Cargo.lock unchanged, --locked passes Also resolved committed conflict markers in two workflow files, which had made nigig-build.yml invalid YAML -- the CI config could not be parsed at all: - nigig-build.yml: kept --include='*.rs' on the by-value-getter gate. Without it the gate scans ARCHITECTURE.md and fails on its own documentation, which is the bug fixed in 4f32b1c. - pdf.yml: kept upstream's side. Enumerating targets via `cargo fuzz list` and failing when the list is empty is strictly better than a hardcoded target list that silently passes vacuously if a target is renamed. That makes four files in three commits now carrying committed conflict markers from this merge. Worth checking how they are reaching main -- `git diff --check` catches exactly this and is already a step in the nigig-build workflow, but it only runs on paths under that workflow's filter.	2026-07-31 19:32:08 +00:00
andodeki	6fd4182313	docs(spreadsheet-ui): update workbook model ownership comments	2026-07-31 19:25:21 +00:00
andodeki	4eebae14f2	Update makepad fork to 11375214 (Cargo.toml fix) ... - Fixed TOML parsing error where fork-specific dependencies were in wrong section - Dependencies now correctly placed in [dependencies] before [features] - Maps feature should now be properly recognized	2026-07-31 19:24:22 +00:00
andodeki	d131e310df	refactor(spreadsheet-ui): make WorkspaceModel the state owner	2026-07-31 19:16:41 +00:00
andodeki	32370d84dc	fix: resolve runtime DSL errors in cost_estimator and cad modules ... - Remove invalid property overrides on CostEstimatorMetric child widgets - Remove unsupported 'visible' property from Svg widget - Fix 'align' type mismatch by using Align{} constructor These were runtime errors that didn't prevent compilation but caused warnings in the Makepad script system.	2026-07-31 19:08:34 +00:00
Arena Agent	b4f22d33e1	fix: restore CadWorkspace and resolve committed conflict markers ... origin/main (8c9ccb9) shipped an unfinished merge. Two problems, both in files it merged from my recent commits. 1. COMMITTED CONFLICT MARKERS. Eleven `<<<<<<< / ======= / >>>>>>>` lines were committed in workspace.rs and formula2.rs, so neither file parses. The markers are literally in the pushed tree, not a local artifact -- `git show origin/main:<file>` contains them. 2. ~3,000 LINES OF CadWorkspace DELETED. workspace.rs went from 3,908 lines to 883. Every method of `impl CadWorkspace` is gone -- handle_actions, draw_walk, all five export entry points, bake_parts, with_viewport, export_scene_source. The impl block opens at line 185 and never closes, which is the "unclosed delimiter" the compiler reports. Resolution: - workspace.rs restored from 36c9c0b, my last verified commit. Checked first that upstream's truncated version added nothing: the set of function names in it is a strict subset of mine, so nothing of theirs is lost by restoring. Both helpers from the conflicting merge -- save_status_message and ExportBlocked/export_blocked_message -- are present and were what the markers were fighting over. Both are kept. - formula2.rs conflicts were resolved by hand. Two were whitespace-only. The other two were the same test data formatted two ways; I kept upstream's rustfmt output since they had just run a formatter over the crate. Deliberately NOT changed: the makepad rev stays at d6d1f99c and Cargo.lock is untouched. The repo still does not resolve, for a separate reason in the fork (see below), and quietly pinning back to 2c5cd97 would hide their bump rather than fix it. I verified this commit by temporarily repinning locally, then reverted the manifests -- 685 lib tests and 225 spreadsheet-engine tests pass against the restored source. STILL BLOCKED, and it needs a fix in gitdab.com/andodeki/makepad, not here: at rev d6d1f99c, widgets/Cargo.toml has three dependency lines makepad-gltf = { path = "../libs/gltf", optional = true } makepad-csg = { path = "../libs/csg/csg", optional = true } makepad-test = { path = "../libs/makepad_test", optional = true } sitting BELOW the `[features]` header instead of inside `[dependencies]`. Cargo parses them as feature definitions, hence "invalid type: map, expected a sequence", and the gltf/csg/test/maps features then do not exist. The block was relocated by the "Update fork to upstream dev 5d4483f" merge; at 2c5cd97 the same three lines are inside [dependencies]. Confirmed the one-block move is the whole fix: with those lines returned to [dependencies] in a local clone, `cargo metadata --features maps,csg,gltf,test` on makepad-widgets resolves cleanly. A [patch] override is not a workaround here -- cargo rejects patching a source with itself, and pointing at a corrected path clone makes the patched and unpatched copies coexist, producing E0659 ambiguity across makepad-ai and makepad-xr.	2026-07-31 19:02:14 +00:00
andodeki	d8d29c226d	feat(pdf): transparency, and four operator-parsing bugs it exposed ... Phase 8 #5 of REVIEWS/DART_PDF_VS_MAKEPAD_PDF_GAP_ANALYSIS.md ("Advanced transparency"). Design and merge criteria in REVIEWS/adr/0009-pdf-transparency.md. The headline defect was not that transparency was missing. `gs` was MIS-PARSED as CloseStroke: /GS0 gs 1 0 0 rg 100 100 200 200 re f -> [CloseStroke, RgbFill, Rectangle, FillWinding] so every page setting a graphics state gained a stroked path the document never asked for, and lost its alpha, blend mode and soft mask silently. Downstream everything was dead: StrokeExtGState/FillExtGState were never constructed, set_fill_opacity was never called and emitted no command when it was, and PdfPage::ext_gstate was read by no code at all. New pdf-graphics/src/transparency.rs: full /ExtGState (ca, CA, BM, SMask, LW, LC, LJ, ML, D, AIS, TK), all sixteen blend modes including the four non-separable ones, soft masks with /S, /G, /BC and a /TR evaluated through ADR 0006's PdfFunction, and /Group parsing. Wired end to end: parser -> PdfOp::SetExtGState -> device -> RenderCommand -> Makepad renderer. Compositing is NOT claimed. Backdrop blending needs render-to-texture, which an engine-neutral crate has no framebuffer for. Constant alpha is applied because it needs no backdrop; blend modes and soft masks are reported through TransparencyError::Unsupported rather than dropped, because a silently ignored /Multiply looks exactly like a correct /Normal. The ADR required a test enumerating every multi-character operator, on the grounds that fixing the third instance of a shadowing bug (after cm and rg) without preventing the fourth is not a fix. It immediately found three more live bugs, none of them transparency-related: - `b` and `b*` dropped their close-path, mapping to FillStroke* instead of CloseFillStroke*, so every closed-and-stroked path drew with a gap. - Text operators within three bytes of the end of a content stream were mis-parsed: the b'T' arm guarded `*i + 3 < len` while reading only two bytes, so a stream ending in `/F1 12 Tf` parsed as FillWinding. And the transparency-group fixture found a fourth: - PdfPage::xobjects was empty for every page of every document. extract_xobjects called doc.resolve(), which follows the reference, then asked the resolved object for as_ref() - always None - and only accepted a bare dict when every XObject is a stream. No `Do` operator could be resolved through the page model. Same defect as the one that once destroyed annotation object references; it now has its own regression test. T* and BMC are genuinely unimplemented and are deliberately excluded from the guard's table rather than papered over. 7 corpus fixtures, 12 acceptance tests, 32 unit tests asserting the §11.3.5 formulas (not our own output), and a parse_ext_gstate fuzz target. TEST_TARGET=pdf 451 -> 497, TEST_TARGET=pdf-ui 495 -> 541. rustfmt and clippy -D warnings clean.	2026-07-31 18:58:31 +00:00
andodeki	8c9ccb92cc	Update makepad fork to latest dev branch (d6d1f99c) ... - Sync with upstream commit 5d4483f (latest map improvements + platform updates) - Include location API, audio echo cancellation, bridge-dz overlay - Add new libraries: geodata, map_nav, i_float, i_shape, i_tree, converse, llama vision - Preserve all fork-specific re-exports (gltf, csg, test) - All 102+ map improvements now available: 2D/3D toggle, shadows, labels, overlays, pattern fills	2026-07-31 18:47:37 +00:00
andodeki	7deb5fe9f6	chore(spreadsheet): remove unused test imports	2026-07-31 18:44:58 +00:00