nigig-org/REVIEWS/PAY_CAD_IMPLEMENTATION_STATUS.md

# Pay + CAD implementation status

## Scope selected

The requested implementation scope was **Nigig Pay + CAD**, with broad refactoring authorised. This document records the first safe implementation tranche and the blockers that prevent falsely claiming the remaining review phases are complete.

## Tranche 1: containment, domain and storage foundation

### Nigig Pay phases 1–4: implemented foundation

- Added a `nigig-pay-storage` workspace crate with transactional SQLite persistence for payment intents and append-only intent state snapshots.
- Added `PaymentStorageWorker`, a single-writer worker that owns its SQLite connection off the UI thread. `save_durable` waits for commit acknowledgement and is the required call before any future gateway dispatch; it is intentionally not fire-and-forget.
- Storage tests cover intent round-trip, state-event audit count, missing-intent error behavior, and cross-thread durable worker acknowledgement.
- This is the Phase-3/4 foundation only. It is not SQLCipher/Keystore encryption and it is not yet wired into the legacy Makepad pay flow.
- Removed the silent `unwrap_or(0)` fee fallback from the shared PaySheet single-payment and bulk-payment start paths. Unknown fees now block the action with a visible status instead of creating a false free quote.

### Nigig Pay domain foundation

- Added `nigig-pay-domain` to the workspace so the pure payment domain is a build target rather than an orphan directory.
- Completed the missing domain module surface declared by `lib.rs`:
  - `fee.rs`: exact, checked fee/amount quote calculation; unknown fees can no longer become zero implicitly inside the domain function.
  - `validation.rs`: canonical Kenyan mobile-number validation, exact amount bounds, PIN shape validation that does not retain a PIN, and recipient-label validation.
- Added checked `Money::checked_add` / `checked_sub` to prevent quote arithmetic overflow or a silently clamped fee deduction.
- Changed the state-machine contract so a `Submitted` payment cannot transition to `Failed` merely because local confirmation did not arrive. It must use `UnknownNeedsReconciliation`.
- Added unit tests to the new fee/validation modules for unknown fee, excessive fee deduction, withdrawal fee, phone forms, amount bounds and PIN shape.

### Existing Pay work discovered during review

The repository already contains partial Phase-0 containment work that the review documents had described as future work:

- `nigig-pay-ui` has a default-off `demo` feature; USSD dispatch, auto retry and bulk pay are disabled without it.
- The fail-open biometric branch in `pay_flow_handler.rs` has been changed to fail closed when the biometric prompt cannot start.

This is not a declaration that Pay is safe. The thread-local coordinator, plaintext/persistent pending store, duplicate implementations, PIN/Accessibility-service work, uncorrelated events and SMS-as-evidence problems remain unresolved.

### CAD assessment correction

CAD's `PROGRESS.md` is stale in places:

- `arch_gltf.rs` already has a parallel mesh-build path above a threshold.
- `send_sync_audit.rs` exists and is wired in `cad/mod.rs` to compile-check `Solid`, `TriMesh` and related Send/Sync requirements.
- `profile_benchmarks.rs` exists.

Therefore it would be dishonest to “implement parallel mesh generation” again merely because the progress markdown still labels it deferred. The remaining CAD blocker is evidence: no benchmark output is checked in, and no Cargo toolchain is available in this execution environment to run the required tests/profiles.

## Tranche 2: evidence, correlation and reconciliation

The previous tranche left Phase-2 items 2.7/2.8/2.9, Phase-3 items 3.2/3.3/3.4,
Phase-7 item 7.8 and Phase-8 item 8.2 open. They are implemented here in the
two pure crates, with tests, and validated by the isolated runner.

### `nigig-pay-domain`

- **`evidence.rs` (new)** — review items 0.4, B2, S-SMS. `ObservedEvidence`
  makes untrusted observation a type. `EvidenceLog::record` de-duplicates by a
  deterministic FNV-1a body digest, so a replayed or spoofed re-send changes
  nothing, and returns `ConflictRequiresReconciliation` when observations
  contradict each other or the amount disagrees with the intent. The log
  exposes `suggests_completion`/`suggests_rejection` hints and deliberately
  exposes no API that returns a settled state. Raw SMS bodies are not carried:
  only the digest is retained (review item 0.6).
- **`reconciliation.rs` (new)** — review items 2.8, 6.3, U4. An explicit
  queue with typed `ReconciliationReason`, and `ResolutionDecision` /
  `ResolutionAuthority` so every closure is attributed to a provider API, a
  support agent or the account owner. `SafeToRecreate` clears the case without
  mutating the original intent, so nothing can re-dispatch it.
  `ReconciliationItem::user_message` is asserted by test to say "do not retry"
  and never the word "failed".
- **`coordinator.rs`** — review items 2.7, 2.9, B3.
  - A reverse `operation_id → intent` index replaces the previous
    "whatever is current" correlation. `intent_for_operation` and
    `record_observed_evidence_for_operation` return `None` for an unknown
    correlation id, so an unmatched callback changes nothing.
  - A hard duplicate-dispatch guard: an intent that has reached the provider
    once can never call the gateway again, even if a caller walks the state
    machine back. `TemporarilyUnavailable`/`Fatal` are the only errors that
    refund the dispatch budget, because only they assert the dispatch never
    started; a timeout keeps it spent.
  - `expire_local_confirmation_window` replaces the 5-minute
    `Submitted → Failed` behaviour. It queues the intent for reconciliation
    and is a no-op against an already-settled payment, so no timer can disturb
    a confirmed transaction.

### `nigig-pay-storage`

- **Schema migration 2** — `payment_intent_evidence` with a
  `UNIQUE(intent_id, body_digest)` constraint so replay protection also holds
  at the storage layer, and `payment_reconciliation_queue` so the backlog is
  durable rather than an in-memory UI concern. `schema_version()` is exposed
  for startup checks.
- Evidence is stored separately from the normalized intent record with only a
  digest of the original message (review item 3.3), and a foreign key refuses
  evidence for an unknown intent.
- Legacy import now also enqueues unprovable records durably and reports
  `queued_for_reconciliation`, so an imported record is not left in a state
  nothing revisits.
- The worker gained durable evidence/queue commands with the same
  commit-before-acknowledge contract as `save_durable`.
- **Fault-injection tests (review item 3.4)**: unwritable path, corrupt
  database file, worker over an unusable path, and a rollback test proving a
  failed audit insert leaves no partially written intent row.
- **Restart-equivalence tests (review item 8.2)**: intent state, amount,
  correlation id, timestamps and the audit trail are reproduced after reopen,
  and the reconciliation queue survives a restart.

### Quality ratchet (review item 7.8)

Both crates now carry
`#![cfg_attr(not(test), deny(clippy::unwrap_used, clippy::expect_used, clippy::panic, clippy::indexing_slicing))]`.

The ratchet immediately caught a real defect: `PaymentStorageWorker::spawn`
used `.expect()` and would have aborted the process if the OS refused a
thread. It is now fallible and returns `StorageError`, so a
resource-exhausted device reports an error instead of losing durability
silently.

### Validation actually run for this tranche

Run in an isolated toolchain against a copy of the two pure crates, outside
the incomplete workspace dependency graph:

```
cargo fmt --all --check          # clean
cargo clippy --workspace --all-targets -- -D warnings   # clean
cargo test -p nigig-pay-domain   # 43 passed
cargo test -p nigig-pay-storage  # 17 passed
```

All 49 workspace `Cargo.toml` manifests still parse. The full workspace is
still **not** asserted buildable here: the external Makepad and remaining
Robius sibling path dependencies are absent, so `nigig-pay-ui` and
`nigig-pay` were not compiled.

### Still not claimed complete after this tranche

1. Wiring the coordinator, evidence log and reconciliation queue into the
   Makepad `nigig-pay-ui` flow, and deleting the legacy thread-local
   `PayFlowHandler`. That is an application-wide migration that cannot be
   honestly done without compiling the UI crate.
2. SQLCipher/Android Keystore encryption at rest (Phase 3.1). The schema and
   single-writer boundary are ready for it; the key hierarchy is not chosen.
3. Phase 4 (draw_walk/blocking I/O), Phase 5 (platform gateway traits and the
   AccessibilityService legal review), and Phase 6 (UI rebuild) — all live in
   crates that cannot be built or tested in this environment.
4. Removing PIN capture and scrubbing `KEY_PIN` from SharedPreferences
   (item 0.3). This is Java/JNI work in `robius-ussd`, untestable here.
5. CAD items, unchanged from the previous tranche.

## Tranche 3: closing every partial phase

This tranche deliberately started no new phase. It finished the items that
tranches 1 and 2 had left partially done, so that Phases 1, 3, 7 and 8 are
either complete for the two pure crates or explicitly blocked on the UI/Android
crates that cannot be built here.

### Phase 1 — build governance, now complete for the owned crates

- **1.1 lockfiles.** `crates/nigig-pay-domain/Cargo.lock` (49 packages) and
  `crates/nigig-pay-storage/Cargo.lock` (66 packages) are checked in and every
  build now runs `--locked`. The runner fails outright on a missing lockfile
  rather than silently generating one, and CI fails if a build mutates one.
- **Toolchain drift fixed.** `tools/test-rust-clean.sh` hardcoded `1.97.1` as a
  default that could silently diverge from `rust-toolchain.toml`. It now parses
  the channel out of `rust-toolchain.toml`, so the runner cannot drift.
  All results below are from the declared toolchain, rustc 1.97.1.
- **1.2 gates.** The runner and CI now run tests, `fmt --check`,
  `clippy -D warnings`, the SQLCipher feature build, and the benchmarks.
- **1.4 boundary enforced in CI.** A job fails the build if either payment
  crate declares or imports Makepad. It inspects manifests and `use`/`extern
  crate` lines, not prose, so doc comments that merely mention Makepad do not
  produce a false failure.

Moving to 1.97.1 surfaced five real lints that 1.85 had not: two
`manual_is_multiple_of` in `money.rs`, a dead field, a `repeat().take()`, and
two derivable `Default` impls. The two `Default` impls are now explicitly
annotated rather than derived, because in both cases the default is a
security or state-machine decision that should stay visible at the site.

### Phase 3 — secure repository, now complete except key provisioning

- **3.1 encryption at rest.** New `encryption.rs` plus an opt-in `sqlcipher`
  feature. `open_encrypted`/`spawn_encrypted` apply `PRAGMA key` as the first
  statement on the connection and then force a read, so a wrong key fails
  immediately as `KeyRejected` rather than later as "file is not a database".
  `DatabaseKey` redacts itself in `Debug` and zeroes its buffer on drop. The
  crate never derives, generates or persists a key: the host supplies a
  `DatabaseKeyProvider` backed by Keystore/Keychain. There is no unencrypted
  fallback path.
  A test reads the raw database file and asserts the recipient MSISDN does not
  appear in it, so the claim is measured rather than assumed.
- **3.5 secure preferences.** New `preferences.rs` replaces the
  `ANDROID_DATA`-derived marker file whose mere existence was the value. Every
  field defaults to the safe value and `load_or_safe_default` returns the safe
  default plus a diagnostic, so an unavailable or tampered store can never
  enable biometric pay.
- **3.6 redaction.** New `redact.rs`. `PaymentIntent`'s derived `Debug` was a
  standing PII leak — any `log!("{intent:?}")` would have written a customer
  MSISDN to the device log. It now has a manual `Debug` that masks phone, name
  and identifiers, with a regression test asserting the raw values cannot
  appear. `StorageError::MissingIntent` no longer prints a full intent id.

### Phase 7 — test strategy, now complete for the owned crates

- **7.1/7.2 already satisfied.** `tests/mpesa_workflow.rs` does not exist in
  this checkout and there are no trivial enum-equality tests to delete. The
  review text is stale here.
- **7.3 not applicable.** No `NIGIG_TEST_PAY` gate exists any more.
- **7.7 benchmarks.** `benches/payment_benchmarks.rs` covers money formatting,
  phone validation, fee quoting, the intent lifecycle, evidence digesting and
  evidence de-duplication. It uses the stable harness, so it runs on the pinned
  toolchain with no nightly and no extra dependency. `benches/BASELINE.md`
  records real measured output, because a benchmark with no checked-in result
  is not evidence.

### Phase 8 — verification

- **8.1 simulator.** New `simulator.rs` provides `ScriptedGateway` (per-call
  scripted responses via interior mutability) and `ScriptedBiometric`, with no
  clock, thread or I/O.
- **8.2 property tests.** The simulator enumerates *every permutation* of a
  representative event set and asserts the review's invariants hold under all
  of them: no ordering causes a second dispatch; untrusted events alone never
  reach `Confirmed` or `Rejected`; an ambiguous sequence never becomes
  `Failed`; `Confirmed` is terminal under any later event; a duplicate
  provider confirmation is idempotent; a replayed SMS cannot accumulate into a
  false conflict; and a failed dispatch never reaches the provider twice.

### Validation actually run for this tranche

Executed against copies of the two crates on the declared toolchain
(rustc 1.97.1), outside the incomplete workspace graph:

```
domain : test --all-targets --locked   66 passed
         fmt --check                   clean
         clippy --all-targets -D warnings   clean
         bench --locked                ran, output recorded in BASELINE.md
storage: test --all-targets --locked   20 passed
         fmt --check                   clean
         clippy --all-targets -D warnings   clean
         test --features sqlcipher     25 passed
         clippy --features sqlcipher -D warnings   clean
```

All 49 workspace manifests parse; `git diff --check` is clean; the Makepad
boundary check passes.

## Tranche 4: Phase 1 complete

Phase 1 is now closed. Every item is either done or has an accepted ADR
recording the decision.

### 1.1 Build governance — done

Lockfiles were already checked in last tranche. Added here: `license = "MIT"`
on both payment crates (cargo-deny correctly reported them as unlicensed,
which would have blocked any distribution review), and a version pin on the
`nigig-pay-domain` path dependency, since a bare path dependency is a
wildcard requirement.

### 1.2 Quality gates — done

Added `deny.toml` and a CI job running `cargo-deny check` over both payment
crates. All four checks pass: **advisories, bans, licences, sources**.

The configuration bans the `makepad-*` crates from the payment dependency
graph outright, so review item 1.4 is now enforced by tooling rather than by
a grep. Sources are restricted to crates.io: a git dependency would bypass the
lockfile guarantee.

### 1.3 Canonical ownership — done, and the review here was stale

`REVIEWS/adr/0002-payment-crate-ownership.md` records the layering. Re-checked
the A5 "fork farm" claim: the duplicates are already gone. One copy each of
`parser.rs`, `store.rs`, `pending_store.rs`, `pay_flow_handler.rs`, not the
three the review's table lists.

**Two of the three `nigig-core` defects are now fixed and tested**, which the
previous tranche had recorded as blocked:

- **B1 — classification silently discarded.** `store.rs` parsed `category`,
  `sub_category`, `status` and `confidence` from disk and then overwrote them
  with `Default::default()`. Every user categorisation was lost on reload.
  Fixed by reassembling the `ClassifiedTransaction`. This also required stable
  storage tokens: the old code wrote *display names* like `"Till / Buy Goods"`,
  which are not reversible. `category_storage_token`/`category_from_storage`
  and the status equivalents now handle this, with a legacy fallback so rows
  written before the fix still load.
- **B4 — lossy PSV escaping.** `clean`/`restore` mapped `|` to `~` and
  reversed every `~`, so `"JOHN~DOE"` loaded as `"JOHN|DOE"`. Replaced with
  bijective backslash escaping that also handles newlines and carriage
  returns, proven by a round-trip test over awkward inputs.
- **B6 — `f64` money.** Not fixed. It is a type change across the observation
  path and its UI consumers, so it belongs with Phase 6 rather than being
  rushed here.

The claim that these could not be tested was wrong, and worth correcting:
`nigig-core` is unbuildable only because of git-hosted Makepad and Robius
dependencies. The three files holding these defects need just `serde`,
`chrono`, one `log!` macro and one `app_data_dir()` helper.
`tools/test-mpesa-store-clean.sh` supplies those two shims in a temporary
crate and runs the tests under the declared toolchain. **9 tests pass**,
including two that reproduced the original defects before the fix.

### 1.4 Boundary enforcement — done

Enforced twice: a CI check on manifests and `use`/`extern crate` lines, and
the `deny.toml` ban list.

### 1.5 Migration shims — done

`nigig-pay/src/lib.rs` carried seven re-export shims. Three (`dir`,
`tile_service`, `location`) had **zero callers** anywhere and are deleted. The
remaining four carry a caller count and a named migration target each, so they
have a deletion plan rather than an open-ended lifetime.

### 1.6 Payment scope ADR — done

`REVIEWS/adr/0001-payment-scope.md`, accepted: **Nigig Pay is a read-only
tracker and launcher, not a payment processor**, until an authorised provider
integration exists. This is the decision the review said had to be made before
further UI investment, and it makes the remaining phases coherent — a tracker
does not need Phase 5's payment gateway, but it does need Phase 6's truthful
states.

### Security finding raised during this work

A **live Cloudflare API token** was found committed in `README.md`, present
since the initial commit and pushed to a public remote. Removed from the file
and recorded as **R-SEC-001** in `PAYMENT_RISK_REGISTER.md`. Redaction does not
revoke it: it remains in git history and **must be rotated**.

### Validation actually run

```
domain : test --locked, fmt, clippy -D warnings, cargo-deny, bench   all pass
storage: test --locked, fmt, clippy -D warnings, cargo-deny,
         test --features sqlcipher                                   all pass
mpesa  : 9 tests via tools/test-mpesa-store-clean.sh                 all pass
```

49 manifests parse; `git diff --check` clean.

## Tranche 5: Phase 3 complete, Phase 4 started

### Phase 3 — now complete

**3.3 retention and erasure.** New `retention.rs`. The hard part here is that
two obligations pull opposite ways: data minimisation says delete, financial
record keeping says retain. The policy resolves them explicitly —

- untrusted evidence expires 90 days after the payment settles;
- settled records are held for a five-year floor;
- intents that never reached the provider expire in 30 days;
- **anything awaiting reconciliation is never swept**, because deleting it
  destroys the only record of money that may have left the account.

`erase_payment_on_request` honours a user deletion request the same way. It
almost always returns `EvidenceErasedRecordRetained`: the parsed copy of the
user's inbox goes, the accounting record stays. Full erasure only once the
record is settled and past the floor; refused outright while in flight. Each
refusal carries a reason string that explains rather than just denies.

**3.4 backup, restore and corruption reporting.** `integrity_check` and
`foreign_key_check` surface damage as `StorageError::Corrupt` instead of
letting a damaged ledger be trusted silently. `backup_to` uses SQLite's online
backup API rather than copying the file, so a concurrent writer cannot produce
a torn copy, and it refuses to back up a database that fails its integrity
check — a backup of corruption can overwrite a good one. `restore_from`
validates the candidate in a separate connection *before* touching the live
database, so a failed restore cannot destroy a working ledger. Tests prove
that with a missing backup and with a corrupt one.

Storage tests: **20 → 36**.

### Phase 4 — started, 4.1–4.3 done

The confirmed defects are fixed:

- **4.1** `expenses/mod.rs` called `reload()` — a full parse of the transaction
  store from disk — as the *first statement* of `draw_walk`. Scrolling that
  page re-read the entire ledger continuously. Data now loads once in
  `on_after_new`; an `invalidate()`/`reload_if_stale()` pair handles refreshes
  on the event path.
- **4.2** The SMS inbox scan was driven by a wall-clock check inside
  `draw_walk`. A "once per 8 seconds" test there is still evaluated every
  frame, and the scan lands mid-paint. It now runs on a real
  `cx.start_interval` timer on the event path, with the interval named
  (`AUTO_SCAN_INTERVAL_SECONDS`) rather than inline.
- **4.3** `update_summary` walked the whole filtered list and rewrote label
  text every frame. It is now invalidated only in `refresh_filtered` — the
  single place the list can change — and applied in `handle_event`. It is
  fully out of the draw path, not merely guarded inside it.
- **4.4** already satisfied: `PaymentStorageWorker` has owned the single
  off-thread writer since tranche 1.

A scan across every `draw_walk` in `nigig-pay` now reports no store I/O and no
recomputation.

**Supporting work in the domain crate.** Phase 4 asks the UI to stop computing
during draw, and Phase 6 asks it to receive a view state. Both need the
arithmetic to exist somewhere pure first, so `view_state.rs` adds
`PeriodSummary` and `TransactionsViewState`. This is testable in a way the
inlined widget code was not, and the tests immediately pin two behaviours the
original code got wrong:

- totals use checked arithmetic and report `overflowed` instead of wrapping;
- a net outflow returns `None` rather than a clamped zero, so spending more
  than was received cannot display as a balanced period.

`Money` also gained a `Default` (zero), written out rather than derived
because an unset amount being nothing is a deliberate statement.

Domain tests: **66 → 75**.

### Validation actually run

```
domain : test --locked, fmt, clippy -D warnings, cargo-deny, bench   pass (75)
storage: test --locked, fmt, clippy -D warnings, cargo-deny,
         test --features sqlcipher                                   pass (36)
mpesa  : 7 tests via tools/test-mpesa-store-clean.sh                 pass
```

49 manifests parse; `git diff --check` clean.

**Not verified:** the `nigig-pay` widget changes for 4.1–4.3 are not compiled.
That crate needs the git-hosted Makepad fork, which is not available here. The
edits are small and local — a moved call, a dirty flag, a timer — but they are
**unbuilt**, and a `cargo check -p nigig-pay` on a full developer checkout is
required before they should be trusted.

## Not falsely marked complete

After three tranches, the following remain open. Each is blocked on a crate
that cannot be compiled in this environment, not on unwritten design.

1. **Phase 1 is complete.** What remains of the old 1.3 item is pointing the
   surviving `pay_flow_handler.rs` at `PaymentCoordinator` and deleting the
   thread-local, which is Phase 6 work and requires compiling `nigig-pay-ui`.
2. **Phase 2.5 / 6.x wiring.** The coordinator, evidence log and reconciliation
   queue are complete and tested, but no Makepad widget consumes them yet.
3. **Phase 3.1 key provisioning.** SQLCipher works and is tested; the Android
   Keystore `DatabaseKeyProvider` implementation is Android-side work.
4. **Phase 4 — remaining work.** 4.1-4.4 are implemented but the `nigig-pay`
   edits are uncompiled. Phase 4 cannot be called complete until
   `cargo check -p nigig-pay` passes on a full checkout.
5. **Phase 5 — platform adapters and the AccessibilityService legal review.**
   The traits exist; the Android adapters and the Play-policy review do not.
6. **Phase 7.3/7.5 — UI tests in CI and an adversarial SMS corpus.** Both need
   the UI crate and a consent-safe corpus that does not exist in this
   repository.
7. **Item 0.3 — PIN capture removal and `KEY_PIN` scrubbing.** Java/JNI work in
   `robius-ussd`.
8. **B6 in `nigig-core`.** B1 and B4 are fixed and tested (tranche 4). B6, the
   nine `f64` money sites, is a type change that ripples into the UI consumers
   and belongs with Phase 6.
9. **CAD items**, unchanged from tranche 1.

## Repository path repair after upstream crate import

After pulling upstream commit `e9616c328816eb9fcae44880e589a5b10fe9245c`, the newly vendored Robius crates lived under `crates/`, while consumers still pointed four directories upward to sibling repositories. The workspace member list also lacked commas and duplicated `robius-trigger`.

This tranche repairs every `Cargo.toml` dependency path for the newly local:

- `robius-sms`
- `robius-ussd`
- `robius-fingerprinting`
- `robius-contacts`
- `robius-trigger`

and makes all five workspace members explicit exactly once. A manifest parser check covers all 48 manifests, and a path-resolution check confirms every dependency on those five local Robius crates resolves to an in-repository `Cargo.toml`.

The full workspace is still not asserted buildable in this isolated checkout: it retains intentionally external `makepad` and `robius/crates/{location,file-picker,directories,...}` path dependencies. Those need to be vendored or provided by the documented super-workspace before a full `cargo check --workspace` claim is honest.

## Tranche 6: Phase 4 verified, Phase 5 implemented

### Phase 4 — now actually verified, not just written

Tranche 5 implemented 4.1–4.3 and then said plainly that the `nigig-pay`
widget edits were **unbuilt**, because the crate needs the git-hosted Makepad
fork and the Linux GUI system libraries.

That blocker was environmental, not architectural. Installing the packages
`tools/makepad-native-libs.sh` already lists (`libwayland-dev`,
`libxkbcommon-dev`, `libx11-dev`, `libxi-dev`, `libxcursor-dev`,
`libxrandr-dev`, `libgl1-mesa-dev`, `libpolkit-gobject-1-dev`) makes the whole
UI graph compile. Both commands the previous tranche listed as required now
pass:

```
cargo check -p nigig-pay      pass (1m 00s, warnings only)
cargo check -p nigig-pay-ui   pass (8.97s, warnings only)
```

**Phase 4 is therefore complete and verified**, including the `draw_walk`
changes. Nothing about the code changed in this tranche; what changed is that
the claim is now evidence rather than assertion.

A note for whoever runs this next: the `--check` mode of
`tools/makepad-native-libs.sh` is the fastest way to find out whether a
checkout can build the UI crates at all.

### Phase 5 — implemented in a new `nigig-pay-platform` crate

ADR 0002 reserved this crate and marked it "not yet created". It exists now,
and ADR 0007 records the design and the one item that engineering cannot
close.

**5.1 traits and adapters.** The crate is the only place in the payment stack
that may name a platform SDK. CI enforces the boundary in both directions:
the payment crates may not import Makepad, and domain/storage may not import
`jni`, `robius_ussd`, `robius_sms` or `robius_fingerprinting`.

**5.3 correlated events.** `SessionRegistry` is single-flight. Every event is
`Accepted`, `Duplicate` or `Ignored`, and `PlatformEvent` cannot be built
without a `CorrelationId`. Closed session ids are retired permanently, so the
scenario that motivated the module — an abandoned session's confirmation
arriving while a different payment is on screen — is refused by construction.
There is a test named after exactly that.

**2.8 / 5.3 fail-closed classification.** This is the part worth reading
closely. `classify_failure` takes the failure *and* the `DispatchProgress`
reached before it, and progress is the authority. The same
`TemporarilyUnavailable` is safely retryable before the dial and ambiguous
once the menu is being driven. The old code could not tell those apart, which
is defect B3's mechanism. A property test asserts the invariant across the
whole failure space: nothing that may have reached the provider ever
authorises a fresh attempt.

**5.4 no fakes in production.** `MockGateway` is `cfg`-gated, is a
`compile_error!` in a release build unless `allow-mock-in-release` is named
explicitly, and stamps every session id with `MOCK-`. CI asserts the release
build genuinely fails rather than trusting the comment.

**5.5 unsafe and threading.** The crate is `#![forbid(unsafe_code)]`.
`UssdGateway` is `!Send`/`!Sync` by construction, so the JNI main-thread
requirement is a compile error rather than a comment. The adapter leaves the
`pin` field empty and a test asserts it.

**5.6 the web claim is withdrawn.** `WebGateway` refuses every call and maps
to `Fatal` — "never sent" — which is accurate and owes no reconciliation. The
alternative in the review was to implement real web adapters; there is no
browser API that can drive USSD, so the claim goes instead.

**7.5 adversarial SMS corpus.** `StrictMpesaSms` is the payment-boundary
reader, separate from `nigig-core`'s permissive tracker parser on purpose —
ADR 0007 explains why that is not the duplication ADR 0002 forbids. The
corpus covers sender spoofing (`MPESA-REFUNDS`, `FAKE-MPESA`, `MPESA.INFO`,
bare MSISDNs), forged code shapes, fractional and out-of-range amounts,
oversized bodies, unicode and NUL injection, and replay. The closing test
asserts the honest limit of all of it: a well-crafted forgery is still
admitted as *evidence*, because the output type has no settled state to
reach.

### 5.2 — not done, and not closeable here

The AccessibilityService legal/policy review is a business decision. ADR 0007
records it as **blocking**, states the Play-policy exposure and the
termination risk, and names what has to happen before the rail is enabled: a
human accepts the risk in writing, or the rail is replaced by an authorised
provider API. USSD dispatch stays behind the default-off `demo` feature
meanwhile.

If the review fails, ADR 0001's tracker/launcher position applies and the
domain, storage and platform work all survive it. Only the dispatch adapter
is discarded.

### Validation actually run for this tranche

```
platform: test --locked (56), test --features ussd (64), fmt,
          clippy -D warnings (default and ussd), cargo-deny,
          mock-in-release guard asserted to fail                 pass
domain  : test --locked                                          pass (75)
storage : test --locked                                          pass (36)
nigig-pay / nigig-pay-ui : cargo check                           pass
```

`cargo-deny` on the platform crate reports `advisories ok, bans ok, licenses
ok, sources ok`; the remaining output is duplicate-version warnings from the
transitive Android/Windows dependency tree, which the other payment crates
also carry.

The isolated runner gained a `platform` target, so this is reproducible with
`TEST_TARGET=platform ./tools/test-rust-clean.sh` and runs in CI on every
push that touches the crate.

### Still not claimed complete after this tranche

1. **Phase 5.2** — the legal review. Blocking, recorded in ADR 0007.
2. **Phase 6** — the UI rebuild. The coordinator, evidence log, reconciliation
   queue and now the platform adapters all exist, but no Makepad widget
   consumes them yet and `pay_flow_handler.rs` still owns a `thread_local!`.
   This is the next phase, and it is the invasive one.
3. **Phase 3.1 key provisioning** — SQLCipher works and is tested; the Android
   Keystore `DatabaseKeyProvider` is Android-side work.
4. **Item 0.3** — PIN capture removal and `KEY_PIN` scrubbing in the Java
   AccessibilityService. The Rust adapter now refuses to carry a PIN, which
   narrows but does not close it.
5. **B6 in `nigig-core`** — the nine `f64` money sites. Belongs with Phase 6
   because the type change ripples into the UI consumers.
6. **Phase 7.3** — UI tests in CI. Needs a headless Makepad harness.
7. **CAD items**, unchanged.

## Tranche 7: Phase 6 truthful states, and Phase 7.3

### The rule, made into a type

Phase 6's exit criterion is a sentence:

> The UI cannot describe a transaction as successful absent trusted
> confirmation, or failed absent known rejection.

Prose cannot enforce that, and the previous code is the proof: the sheet
decided its own status inline, in about a dozen places, from whatever local
signal was nearest. That is how "no SMS within five minutes" became a red
**✗ Payment failed** for transfers that had actually settled (review item U4).

`payment_view_state.rs` makes the rule a type. `PaymentPresentation` has
seven variants and **no** `Success` that untrusted evidence can reach, and
**no** `Failed` that a missing SMS can reach:

| Durable state | Presented as | May show success | May offer retry |
|---|---|---|---|
| `Confirmed` + provider code | `Confirmed` | yes | — |
| `Rejected` | `Rejected` | no | yes |
| `Failed{DispatchNotStarted}` | `NotSent` | no | yes |
| `Failed{UserCancelled}` | `NotSent` | no | yes |
| `Failed{VerificationExpired}` | **`PendingConfirmation`** | no | **no** |
| `Failed{Unknown}` | **`PendingConfirmation`** | no | **no** |
| `UnknownNeedsReconciliation` | `PendingConfirmation` | no | **no** |

The last three are the interesting rows. A widget now has to go through
`may_show_as_success()` / `may_show_as_failure()`, so a dishonest label would
have to be introduced in that one file, in front of its tests, rather than
anywhere in 2,300 lines of widget code.

Two defence-in-depth cases are covered because they are cheap: a `Confirmed`
intent carrying no provider reference reads as *unknown* rather than settled,
and `PaymentFailureReason::Unknown` reads as *pending* rather than failed —
an unclassified error is not evidence that nothing was sent.

**6.2 confirmation.** `ConfirmationSummary` makes every term the review lists
a mandatory field, so a confirmation cannot be constructed with the fee or
the total missing. It is built from the same `compute_adjusted_amount` quote
that will be dispatched, so the screen cannot disagree with what is sent. The
modal previously showed only recipient and amount; it now shows the rail,
transaction fee, withdrawal fee where charged, what the recipient receives,
what the payer pays, and how the payment is authorised.

`material_digest()` implements the re-display requirement. Consent is
recorded against the exact terms shown, and re-checked when the user taps OK:
if anything material moved in between, the authorisation is void and the
screen is shown again rather than dispatched on. Cancelling clears it.

**6.3 no auto-close.** `must_stay_open()` is true for anything in flight or
pending. The status line for a pending payment begins with the exact required
wording, which a test asserts:
`Pending confirmation — do not retry.`

**6.5 receipt and user rights.** `PaymentViewState::evidence` exposes stored
observations, each labelled untrusted, and the action set for a pending
payment offers `ViewReceipt`, `ReportProblem` and `RequestDataDeletion`
(the storage side of deletion already exists in `retention.rs`).

### Three real defects found and fixed while wiring this

These were not on the review's list. They were found by writing the tests.

1. **Bulk quotes silently under-charged.** `compute_bulk_costs` used
   `filter_map` over the fee lookup, so any contact whose amount falls
   outside the published tariff was *dropped from the fee total* — the user
   saw a total missing that fee. It now reports them in
   `contacts_without_a_fee`, and `is_complete()` gates the quote.
2. **The batch total could overflow.** `contacts.iter().map(..).sum()` panics
   in debug and wraps in release. A wrapped total is a quote for the wrong
   amount. It now saturates and reports `amounts_overflowed`.
3. **The cost preview showed unknown fees as free.** Two `unwrap_or(0)` calls
   in `refresh_cost_preview` rendered an unpriceable amount as a zero-fee
   one. Both now propagate `None` to the label, which reads
   `— (no published fee for this amount)`.

Item 3 is review defect B5 resurfacing in the preview path after tranche 1
fixed it in the dispatch path. Worth noting for whoever audits next: fixing a
defect at one call site is not the same as fixing the defect.

### A pre-existing test failure, diagnosed rather than deleted

`money::tests::ksh_rounds_to_nearest_cent` asserted
`format_ksh(1.005) == "1.01"` and had been failing on every run. Confirmed
pre-existing by stashing this tranche's changes and re-running against a
clean tree.

The expectation is impossible, not the formatter wrong. `1.005` is not
representable in binary floating point; the nearest `f64` is
`1.00499999999999989…`, so the correctly rounded result really is `1.00`.

This is review defect **B6** (`f64` for money) in miniature: the type cannot
hold the value the caller meant, and no rounding logic recovers it. The test
is rewritten to state that, alongside a companion test showing
`nigig_pay_domain::Money` handling the same case exactly. Deleting the test
would have hidden a live argument for finishing B6.

### Phase 7.3 — UI tests now run in CI

The review asked for UI tests in CI and the removal of the `NIGIG_TEST_PAY`
gate. The gate is already gone. What blocked CI was the Makepad link step,
and the cause turned out to be a gap in `tools/makepad-native-libs.sh`: it
listed the libraries needed to *compile*, but not `libasound2-dev`,
`libpulse-dev` and `libssl-dev`, which are needed to *link* a test binary.
The failure mode is confusing — `cargo check` succeeds and then
`unable to find library -lasound` appears much later.

The helper now installs and checks all of them, and a new `payment-ui-tests`
CI job runs `cargo test -p nigig-pay-ui --lib` plus `cargo check` on
`nigig-pay-ui`, `nigig-pay` and `nigig-mpesa`. Every step was run locally
before being committed.

### Validation actually run for this tranche

```
domain  : test --locked (95), fmt, clippy -D warnings, bench     pass
storage : test --locked (36 + 41 sqlcipher), fmt, clippy         pass
platform: test --locked (56), --features ussd (64), fmt, clippy,
          mock-in-release guard                                  pass
nigig-pay-ui : cargo test --lib                                  pass (61)
nigig-pay-ui / nigig-pay / nigig-mpesa : cargo check             pass
```

Domain tests 75 → 95. UI tests 55 → 61, with the long-standing failure fixed.

### Still not claimed complete after this tranche

1. **Phase 5.2** — the AccessibilityService legal review. Blocking, ADR 0007.
2. **Phase 6 wiring is partial.** `PaymentViewState` exists, is tested, and
   the confirmation path uses `ConfirmationSummary`. What is *not* done is
   deleting the `thread_local!` `PayFlowHandler` and routing the sheet's
   status text through `PaymentViewState` end to end. The type now exists to
   make that mechanical, but it is a large edit and claiming it here would be
   the kind of overstatement this document exists to avoid.
3. **6.6 bulk** — still demo-gated. It needs an idempotent rail first, which
   is Phase 5.2's outcome.
4. **Phase 3.1 key provisioning** — Android Keystore work.
5. **Item 0.3** — `KEY_PIN` scrubbing in the Java service.
6. **B6 in `nigig-core`** — the nine `f64` money sites. This tranche
   documented one of its symptoms rather than fixing the cause.
7. **CAD items**, unchanged.

## Tranche 8: the last false-success labels, and B6 where it matters

### Two labels that still claimed settlement

Tranche 7 built `PaymentViewState` and said plainly that the sheet's
remaining status strings were still composed inline. Two of them were not
merely untidy — they were the Phase 6 violation itself, still shipping:

```rust
PayFlowEvent::ObservedEvidence  => "✓ SMS received — ref: {code} …"
PayFlowEvent::BulkItemObserved  => "✓ {current}/{total} sent"
```

A tick is a settlement claim. The first put one next to an SMS, which proves
nothing and can be forged. The second counted *dispatches* as though they
were confirmations, so a batch of five unknown outcomes rendered as
`✓ 5/5 sent`.

The vocabulary now lives in `FlowStage`, beside the presentation types, with
one rule: **a tick requires a provider confirmation.** Untrusted evidence
gets `"Message received (ref X) — not yet confirmed. Do not send again until
this is resolved."` A finished batch reads `"Batch finished — N sent,
awaiting confirmation"`, because that is what actually happened.

Nine call sites in `shared_pay_sheet.rs` now derive their text instead of
composing it. The two remaining `✓` in that file are fingerprint-sensor
feedback, which is a real local event and not a settlement claim.

**A CI guard backs this**, and it was tested against the old code to confirm
it fails when the regression is reintroduced — a guard that cannot fail is
decoration.

### B6, scoped to where it is real

The review lists nine `f64` money sites. Before changing them all, each was
measured, because "replace f64 everywhere" is easy to claim and easy to get
wrong.

- **`format_amount`** was checked exhaustively across every value from
  `0.00` to `2000.00` against an exact integer reference: **zero
  mismatches**. It also rounds `1234.567` and `2.675` correctly. This
  function is not the defect, and rewriting it would have been churn.
- **Accumulation** is the defect. Summing 10,000 realistic amounts showed no
  visible drift, so the everyday risk is low — but `f64` silently discards
  additions past 2^53 and offers *no overflow signal at all*. A corrupt or
  hostile record therefore produces a confident wrong total with nothing to
  indicate it.

So the fix went to the accumulators, not the formatter.
`update_summary` in both `nigig-mpesa` and `nigig-pay` — an exact duplicate
of each other, review item A5 — now builds a
`nigig_pay_domain::PeriodSummary` from exact minor units, with checked
arithmetic, and renders `—` rather than a wrapped figure when
`overflowed` is set. Conversion from the stored `f64` is explicit and
validated; a non-finite or negative stored amount is skipped rather than
allowed to poison the total.

`store.rs::totals()` returns `(f64, f64, usize)` and has **no callers**. It
is now `#[deprecated]` with the reason, rather than deleted, because
`nigig-core` has no dependency on the domain crate and that is a separate
change.

Two regression tests state the case executably: one asserts that `f64`
silently swallows `2^53 + 1` while the exact path keeps both entries, and
one asserts that a genuinely impossible total is *reported* rather than
shown.

### Validation actually run for this tranche

```
domain  : test --locked (104), fmt, clippy -D warnings, bench    pass
storage : test --locked (36 + 41 sqlcipher), fmt, clippy         pass
platform: test --locked (56 + 64 ussd), fmt, clippy, mock guard  pass
nigig-pay-ui : cargo test --lib                                  pass (61)
nigig-pay-ui / nigig-pay / nigig-mpesa / nigig-core : cargo check pass
settlement-tick CI guard : verified to fail on the old code      pass
```

Domain tests 95 → 104.

### Still not claimed complete

1. **Phase 5.2** — the AccessibilityService legal review. Blocking, ADR 0007.
2. **The `thread_local!` `PayFlowHandler` still exists.** The status
   vocabulary is now domain-owned, which was the part that carried the
   correctness risk, but `PayFlowHandler` still holds flow state in a
   thread-local and `PaymentCoordinator` is still not what the widgets talk
   to. That remains the Phase 6 architectural item.
3. **B6 elsewhere.** The parser's `MpesaTransaction::amount`, `balance` and
   `cost` are still `f64` on disk. Changing the stored representation is a
   migration, not an edit, and belongs with the SQLite move.
4. **6.6 bulk** — demo-gated pending an idempotent rail.
5. **Phase 3.1 key provisioning**, **item 0.3 `KEY_PIN`**, **CAD** —
   unchanged.

## Tranche 9: batch accounting made bounded

### A progress bar that could read `3/2`

While working toward retiring the `thread_local!` handler, the bulk
accounting turned out to hold a defect worth fixing on its own merits.

`bulk_done` was a bare `usize` incremented at **eight independent match
arms**, none of them bounded, and `bulk_current_idx` added one more while an
item was in flight. Nothing tied the counter to the batch's actual contents.

The USSD event pump does not guarantee one terminal event per item: an
`Error` can be followed by a `SessionEnded` for the same session, and each
arm increments separately. Two lines of arithmetic reproduce the result:

```
one item, two terminal events -> bulk_done=2/2
BulkItemDispatched reports        3/2   <-- exceeds total
```

That was reproduced before any code was changed, so the fix is answering a
demonstrated defect rather than a suspected one.

### `PaymentBatch`

The count is now a function of the batch's contents rather than of how many
code paths happened to run. Each item carries exactly one
`BatchItemOutcome`; `settle` **refuses** a second one instead of counting it.
Progress is derived by walking the items, so `finished > total` is
unrepresentable rather than merely unlikely.

Every former `h.bulk_done += 1` now routes through one `settle_bulk_item`
helper. A CI guard rejects direct increments, and was tested against the
reintroduced bug to confirm it fails — the same discipline used for the
settlement-tick guard in tranche 8.

Three further properties came out of putting this in the domain, where it
can be tested at all:

- **`finished` is not `succeeded`.** `BatchProgress::confirmed` counts only
  provider confirmations. A batch that finished with unknown outcomes reports
  `"Batch finished — N confirmed, M awaiting confirmation. Do not re-send:
  check your M-Pesa statement first."` and never carries a tick. Only an
  all-confirmed batch may be ticked. This is review item U7.
- **A pending item is never offered for re-run.** `safe_to_recreate` returns
  only `NotSent` and `Rejected` items. Replaying an item that may already
  have settled is defect B3 at batch scope.
- **Cancelling does not rewrite history.** `cancel_remaining` marks only
  items that never got an outcome. An already-dispatched item keeps its
  pending status, because cancelling a batch does not recall a request the
  provider may already hold.

A stray callback for an unknown item id is refused rather than counted, which
is the batch-level counterpart of the correlation rule in ADR 0007.

### Validation actually run for this tranche

```
domain  : test --locked (117), fmt, clippy -D warnings, bench    pass
storage : test --locked (36 + 41 sqlcipher), fmt, clippy         pass
platform: test --locked (56 + 64 ussd), fmt, clippy, mock guard  pass
nigig-pay-ui : cargo test --lib                                  pass (61)
nigig-pay-ui / nigig-pay / nigig-mpesa / nigig-core : check      pass
batch-counter guard : verified to fail on the reintroduced bug   pass
settlement-tick guard : still passing                            pass
```

Domain tests 104 → 117.

### On the `thread_local!` handler, again

It is still there, and this tranche did not remove it.

What changed is that the state which carried the correctness risk — the batch
accounting — no longer lives in it. `PayFlowHandler` now delegates to
`PaymentBatch` for every outcome, so the thread-local holds queue plumbing
and platform handles rather than the numbers a user is shown.

That is a smaller and more honest claim than "Phase 6 wiring complete". The
remaining work is replacing `PayFlowHandler` itself with
`PaymentCoordinator`, which changes the ownership of the USSD session and the
biometric prompt, not just where a counter lives. It should be done as its
own change with the device matrix in ADR 0007's exit criterion, not folded
into a tranche that also touches accounting.

### Still not claimed complete

1. **Phase 5.2** — the AccessibilityService legal review. Blocking, ADR 0007.
2. **`PayFlowHandler` → `PaymentCoordinator`.** The last Phase 6
   architectural item, scoped above.
3. **6.6 bulk UI** — the accounting is now correct and testable, but per-item
   review, limits, pause/resume and audit export are not built, and bulk
   stays demo-gated pending an idempotent rail.
4. **B6 on disk** — the parser's stored `f64` amount/balance/cost. A
   migration, not an edit.
5. **Phase 3.1 key provisioning**, **item 0.3 `KEY_PIN`**, **CAD** —
   unchanged.

## Tranche 10: the biometric gate the coordinator could not provide

### Attempting the migration found a defect in the plan

The stated next step was replacing `PayFlowHandler` with
`PaymentCoordinator`. Doing that means writing a `BiometricAuthorizer`
adapter for Android. It cannot be written correctly, and finding out why is
the substance of this tranche.

The trait's contract is blocking:

> `authenticate` must be a blocking call that waits for user action.
> Returns Ok(()) on success, Err on failure/cancel.

`robius_fingerprinting::authenticate` issues a JNI call that shows the prompt
and returns `Ok(())` **immediately**. Verified by reading through
`sys/android/prompt.rs`: it calls the Java `authenticate` static method and
returns; the user's answer arrives later via `next_event()` as an
`AuthResult`.

So an adapter can either:

- return `Ok(())` because the prompt opened — and
  `authorize_and_dispatch` then sends money **before the user has touched the
  sensor**. That is defect **S2**, the fail-open biometric, reintroduced
  through the type system; or
- block, and deadlock the thread that must pump the callback.

Had the migration been done without noticing this, the result would have been
a correct-looking refactor that silently reopened the review's most serious
security finding.

### `AuthorizationAttempt`

Authorization is a state machine, not a function call:
`Requested → Prompting → Granted | Denied`, advanced by inbound signals.
One rule, enforced by the type: **only an explicit success grants dispatch.**

- A displayed prompt does not authorise. A touched sensor does not authorise.
  A non-match keeps the prompt up and stays retryable rather than denying.
- A grant is bound to one intent, so a callback for an abandoned payment
  cannot authorise the current one.
- A grant is **spent on use**, so one fingerprint cannot authorise two
  dispatches (defect B3), and a replayed success cannot re-arm it.
- A late success arriving after a cancel is ignored rather than resurrecting
  the payment.
- Backgrounding mid-prompt denies; it never silently allows.

`dispatch_ussd` now consumes a grant before dispatching and refuses without
one. `auth == None` means no biometric gate was configured, which is
deliberately distinct from an ungranted one.

A CI guard asserts the gate exists, and was tested against a version with the
check disabled to confirm it fails.

The trait keeps its blocking contract for synchronous authorizers and test
doubles, and now documents that Android must not use it. ADR 0007 carries the
amendment.

### Validation actually run for this tranche

```
domain  : test --locked (129), fmt, clippy -D warnings, bench    pass
storage : test --locked (36 + 41 sqlcipher), fmt, clippy         pass
platform: test --locked (56 + 64 ussd), fmt, clippy, mock guard  pass
nigig-pay-ui : cargo test --lib                                  pass (61)
nigig-pay-ui / nigig-pay / nigig-mpesa / nigig-core : check      pass
authorization guard : verified to fail with the gate removed     pass
batch-counter and settlement-tick guards : still passing         pass
```

Domain tests 117 → 129.

### Where the coordinator migration now stands

The blocker is no longer unknown. `PaymentCoordinator` needs an
authorization path that does not assume a blocking authorizer;
`AuthorizationAttempt` is that path, and it is built and tested. What remains
is a coordinator entry point that takes an already-granted attempt instead of
calling `biometric.authenticate()` itself, and then moving the USSD session
ownership across.

That is a coordinator API change. It should be designed against ADR 0007's
device matrix — permission denial, cancellation, backgrounding, app restart,
out-of-order callbacks — and none of that can be exercised here. Doing the
API change blind and calling Phase 6 complete would be exactly the
overstatement this document exists to prevent.

### Still not claimed complete

1. **Phase 5.2** — the AccessibilityService legal review. Blocking, ADR 0007.
2. **`PayFlowHandler` → `PaymentCoordinator`.** Unblocked in design, pending
   a coordinator API change and device testing.
3. **6.6 bulk UI** — accounting is correct; per-item review, limits,
   pause/resume and audit export are not built.
4. **B6 on disk** — the parser's stored `f64` fields. A migration.
5. **Phase 3.1 key provisioning**, **item 0.3 `KEY_PIN`**, **CAD** —
   unchanged.

## Tranche 11: the coordinator accepts an external grant

### The API change tranche 10 scoped

Tranche 10 established that Android cannot implement `BiometricAuthorizer`
without reopening defect S2, and built `AuthorizationAttempt` as the
replacement. It named the remaining work precisely:

> a coordinator entry point that takes an already-granted attempt instead of
> calling `biometric.authenticate()` itself

That entry point now exists:

```rust
coordinator.dispatch_with_authorization(&id, &mut attempt)
```

It does not prompt, does not wait, and **does not consult the injected
`BiometricAuthorizer` at all**. That last point is asserted rather than
assumed: one test injects an authorizer that reports no hardware *and*
returns an error, and shows that a granted attempt still dispatches. If the
coordinator ever fell back to the injected authorizer, that test fails.

Three refusals are enforced, each with a test that fails when the gate is
removed:

- **An unanswered prompt does not dispatch.** `PromptShown` plus
  `SensorEngaged` is not consent. This is the exact shape the Android adapter
  would have produced.
- **A grant belongs to one payment.** A grant naming a different intent is
  refused *before* anything else, so a stray callback cannot even fail the
  payment on screen — the victim intent is left untouched in
  `AwaitingUserAuthorization` rather than transitioned to `Failed`.
- **A grant is spent on use.** One authorization, one dispatch (defect B3).

Denied, still-prompting and already-spent attempts all fail the intent closed
and never reach the gateway.

### Verifying the tests can fail

The gate was removed (`if !attempt.consume()` → `if false`) and the suite
re-run: **5 tests failed**. That is the check that matters — a fail-closed
test that passes against fail-open code is worthless.

Worth recording: `a_grant_cannot_dispatch_twice` **still passed** with the
gate removed, because the coordinator's existing duplicate-dispatch budget
caught it independently. Two unrelated mechanisms both refuse the second
dispatch. That is defence in depth working as intended, and it is the reason
that particular test is not sufficient evidence on its own.

### Validation actually run for this tranche

```
domain  : test --locked (137), fmt, clippy -D warnings, bench    pass
storage : test --locked (36 + 41 sqlcipher), fmt, clippy         pass
platform: test --locked (56 + 64 ussd), fmt, clippy, mock guard  pass
nigig-pay-ui : cargo test --lib                                  pass (61)
nigig-pay-ui / nigig-pay / nigig-mpesa / nigig-core : check      pass
authorization / batch / settlement-tick guards                   pass
fail-open injection: 5 tests fail with the gate removed          pass
```

Domain tests 129 → 137.

### What remains of the migration, precisely

The authorization half is done and verified. `PayFlowHandler` still owns:

- the USSD session lifecycle (`begin_transaction`, `cancel_session`, and the
  `next_event` pump);
- the pending-store writes that shadow the coordinator's repository;
- the bulk queue plumbing.

Moving those means the coordinator owns the gateway session, which changes
who cancels on teardown and who observes an out-of-order callback. ADR 0007's
exit criterion asks for a device matrix — permission denial, cancellation,
backgrounding, app restart, out-of-order callbacks — before that can be
called done, and none of it can be exercised here.

The honest position: the part that could be built and proven without a device
has been. The part that cannot is still open, and is smaller and better
specified than it was two tranches ago.

### Still not claimed complete

1. **Phase 5.2** — the AccessibilityService legal review. Blocking, ADR 0007.
2. **USSD session ownership** — the remaining half of the coordinator
   migration, scoped above. Needs device testing.
3. **6.6 bulk UI** — accounting is correct; per-item review, limits,
   pause/resume and audit export are not built.
4. **B6 on disk** — the parser's stored `f64` fields. A migration.
5. **Phase 3.1 key provisioning**, **item 0.3 `KEY_PIN`**, **CAD** —
   unchanged.

## Tranche 12: B6 at the persistence boundary

### Why this and not the migration

B6 is the last unfinished **P0** on the review's priority table. The obvious
reading is "change `f64` to `Money` on disk", which is a data migration and
belongs with the SQLite move — it cannot be done safely here.

But the stored *representation* is not where the damage is. Measuring first,
as in tranche 8:

- **The `f64` round trip is exact.** Every value tested — `1500.0`,
  `1500.5`, `0.1 + 0.2`, `1e20`, `12345678.995` — writes and re-reads
  bit-identically. The format is not losing money.
- **The read path is where the damage is.** `parts[2].parse().unwrap_or(0.0)`
  turned *any* unreadable amount into a confident `KSh 0` row.
- **And `NaN` gets in.** `"NaN"` and `"inf"` both parse successfully as
  `f64`, and the writer emits them back out verbatim, so they survive a round
  trip. One corrupt SMS poisons every total it enters, permanently — once a
  `NaN` is in a sum, every comparison against that sum is false.

So the fix went to the boundary, not the format.

### What changed

`validate_money` refuses three classes of value, on parse, on load **and** on
save:

- **non-finite** — `NaN`/`inf`, for the reason above;
- **negative** — direction is carried by `TransactionType`, so a negative
  amount is a contradiction, not an outflow;
- **beyond 2^53** — past that an `f64` cannot represent consecutive
  shillings, so arithmetic silently loses value.

A row whose amount cannot be trusted is now **skipped with a log line**
rather than zeroed. Dropping a row is visible and recoverable by rescanning
the inbox; a silent `KSh 0` is neither. `balance` and `cost` are optional
context rather than the ledger figure, so they degrade to `None` instead of
discarding the row — but they can no longer be `NaN` either.

The writer refuses to persist an invalid amount at all, which is what stops a
poisoned value becoming permanent.

One smaller parse fix: `Ksh ,5` used to read as `5`. A grouping separator
before any digit means the text is not the expected shape, and guessing is
worse than declining to read it.

### The parser had no tests

Worth stating plainly: `parser.rs` — the file that decides what every
observed amount is — had **zero tests** before this tranche. It now has 13,
covering validation, extraction, end-to-end parsing, and unicode/NUL bodies
that must not panic on a byte-index slice.

M-Pesa harness tests: **7 → 24**.

### Verifying the tests can fail

`validate_money` was reduced to `Some(value)` and the harness re-run:
**4 tests failed**. As in tranches 8 and 11, a guard that cannot fail is
decoration.

### Validation actually run for this tranche

```
mpesa harness : 24 tests via tools/test-mpesa-store-clean.sh       pass
domain  : test --locked (137), fmt, clippy -D warnings, bench      pass
storage : test --locked (36 + 41 sqlcipher), fmt, clippy           pass
platform: test --locked (56 + 64 ussd), fmt, clippy, mock guard    pass
nigig-pay-ui : cargo test --lib                                    pass (61)
nigig-pay-ui / nigig-pay / nigig-mpesa / nigig-core : check        pass
authorization / batch / settlement-tick guards                     pass
defect injection: 4 tests fail with validation removed             pass
```

### What B6 still leaves open

The stored representation is unchanged: `MpesaTransaction::amount` is still
`f64` on disk. That is deliberate and now bounded — nothing untrustworthy can
enter or leave the store, so the remaining exposure is precision within the
validated range, which for whole-shilling M-Pesa amounts under 2^53 is none.

Converting the field to `Money` means rewriting the PSV format and migrating
existing files. ADR 0002 is updated to record B6 as partially addressed
rather than open, with the migration explicitly deferred to the SQLite move.

### Still not claimed complete

1. **Phase 5.2** — the AccessibilityService legal review. Blocking, ADR 0007.
2. **USSD session ownership** — the remaining half of the coordinator
   migration. Needs ADR 0007's device matrix.
3. **6.6 bulk UI** — accounting is correct; per-item review, limits,
   pause/resume and audit export are not built.
4. **B6 stored representation** — a data migration, scoped above.
5. **Phase 3.1 key provisioning**, **item 0.3 `KEY_PIN`**, **CAD** —
   unchanged.

## Tranche 13: item 0.3, PIN capture removed rather than hidden

### Asked in review: "does the latest code have the PIN input field?"

It did. `pin_input`, `form_pin` and the reveal toggle were all present, and
the default build hid them at runtime in `on_after_new`:

```rust
if !cfg!(feature = "demo") {
    self.form_pin.clear();
    self.view.view(cx, ids!(pin_visibility_row)).set_visible(cx, false);
}
```

That is weaker than it looks, and item 0.3 asks for removal rather than
concealment:

1. **The DSL declared the control visible.** Rust hid it *afterwards*.
   Anything that re-applies the UI definition — a hot reload, a
   re-instantiated sheet — brings 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. **The field existed to be filled.** `form_pin` was compiled into every
   build, so any path that reached it could populate it.

### Now: the field does not exist unless `demo` is enabled

`form_pin`, `pin_visible`, the eye-toggle handler, the text-input handler,
both PIN checks, the request construction and the `try_build_ussd_request`
accessor are all `#[cfg(feature = "demo")]`. A default build has no field to
write to, so nothing can populate it — not a stale UI definition, not a hot
reload, not a hidden-but-present widget.

The DSL now also declares `visible: false` on the PIN input and its reveal
button, so hidden is the *default state* rather than a runtime correction;
a `demo` build unhides them on init. That closes the reload path in (1).

The one remaining runtime call is a deliberate belt-and-braces: if a
hot-reloaded definition somehow surfaces the input, the non-demo arm wipes
whatever 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 would pass just as happily against
a field still present behind a runtime `if`. `tools/check-no-pin-capture.sh`
is a compile probe instead: it inserts a reference to the field outside any
`cfg` block and requires the default build to **fail** with
``no field `form_pin` `` while the `demo` build succeeds. The script restores
the file on any exit path.

Verified in both directions: it passes on current code, and re-exposing the
field un-gated makes it exit 1.

### Validation actually run for this tranche

```
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 item 0.3 still leaves open

0.3 has two halves. The Rust-side capture UI is now removed from default
builds, which is this tranche. The Java-side `KEY_PIN` scrubbing in
`UssdAccessibilityService.java` was already done in earlier work
(`remove(KEY_PIN)` on completion, failure and handoff-disabled paths), so
0.3 is complete for the default product.

What remains is that a **`demo` build still captures a PIN**, by design —
that path exists only 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.

### Still not claimed complete

1. **Phase 5.2** — the AccessibilityService legal review. Blocking, ADR 0007.
2. **USSD session ownership** — the remaining half of the coordinator
   migration. Needs ADR 0007's device matrix.
3. **6.6 bulk UI** — accounting is correct; per-item review, limits,
   pause/resume and audit export are not built.
4. **B6 stored representation** — a data migration.
5. **Phase 3.1 key provisioning**, **CAD** — unchanged.

## Required next commands

The two pure crates are fully validated by the isolated runner, which installs
the toolchain declared in `rust-toolchain.toml`, runs `--locked` builds, and
deletes its temporary environment on any exit:

```bash
TEST_TARGET=domain ./tools/test-rust-clean.sh
TEST_TARGET=storage ./tools/test-rust-clean.sh
TEST_TARGET=platform ./tools/test-rust-clean.sh
./tools/test-mpesa-store-clean.sh
```

From a complete developer checkout with all sibling Makepad/Robius
dependencies available, the remaining crates still need:

```bash
cargo test -p nigig-build cad::send_sync_audit -- --nocapture
cargo test -p nigig-build cad::profile_benchmarks -- --nocapture --test-threads=1
```

The two Pay commands that were listed here as blockers — `cargo check -p
nigig-pay` and `cargo check -p nigig-pay-ui` — **now pass** and are recorded
under tranche 6. Reproducing them needs the Makepad native libraries:

```bash
./tools/makepad-native-libs.sh --check     # reports what is missing
./tools/makepad-native-libs.sh --install   # opt-in, apt-based
cargo check -p nigig-pay
cargo check -p nigig-pay-ui
cargo test  -p nigig-pay-ui --lib          # runs in CI as of tranche 7
```

The CAD commands above remain unrun. Phase 6 is the next Pay phase.