ADFA-514: Update contact dialog with send email button and new email address by Daniel-ADFA · Pull Request #91 · appdevforall/CodeOnTheGo

Daniel-ADFA · 2025-04-16T18:37:34Z

Ticket: https://appdevforall.atlassian.net/browse/ADFA-515

Update contact dialog with send email button and new email address

…address

…ity and maintainability

Decision input for the release conversation: what a user actually experiences, the mechanism with file:line, the device evidence, severity and frequency, and the options with their tradeoffs. Tasks #87-#91. None is fixed. None of the five is in the README's "Known limitations (v1)" list, and that is the point: the documented limitations are boundaries the design chose, while these are cases where the feature behaves worse than its own design intends. The never-stale invariant holds in all five - the gap is reliability and honesty of feedback, not speed or correctness. Ship-blocking for v1: the install-confirm fast-fail (180 s of silence ending in a message that says the user failed to confirm something never shown to them), launch-and-retry after a rebaseline reinstall (deterministic today; the fast path is dead until the user guesses), and the daemon-death reclassification (a one-line body edit becomes a ~200 s rebaseline in any Room/KSP project, 3/3 on the A56). Three corrections to the framing this doc started from, all substantiated: - shrinkDaemonForMemory() does not no-op during a mid-start respawn. Its guard is on Building, so in Degraded it runs, and its daemonEpoch++ is a CAUSE of the respawn being discarded. A memory trim during a respawn can strand the session permanently with only a log.info. - "Android never delivers PENDING_USER_ACTION to a backgrounded app" is wrong, and five places in the tree assert it. The broadcast is explicit to our own manifest receiver and is delivered (deferred at worst - our own run-2 findings say so). What is lost is the lifecycle-bound EventBus subscriber that owns the dialog, plus the Android 10+ background startActivity block. Fixing the platform theory points at the wrong repair. - The Degraded session is not entirely silent - the toolbar icon does go to the ATTENTION shape and colour. What is missing is any text, and any feedback that the tap was swallowed. Defect 3 has no device reproduction; the doc says so rather than implying one. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MkdFG7t9oNJtiayQzUQf89

The page proposed that #87, #89, #91 and the relink-crash gap go to v1.1, then left the table's "Blocks v1?" column reading TBD on all four rows. A proposal in a title and a TBD in a table say different things to a reader, and CodeRabbit flagged the pair as an internal inconsistency. Decision confirmed 2026-08-25: none of the four block v1. The four cells now read "No - v1.1", the title states the answer rather than asking it, and the prose no longer describes itself as awaiting confirmation. No change to any gap's evidence, root cause, or fix. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FstXxJ5cwWPcvmhZ9vJgJ7

…by a planning-doc number The backgrounded-deploy comment in QuickBuildRuntime deferred to "gap #91", a number from quickbuild/docs/reliability-gaps.md that a reader of the comment cannot follow. State the gap in words and cite ADFA-5466, filed for it today; the gaps table carries the same key. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017o3nPrBbGi2XYkMUGavG2A