Skip to content

ADFA-514: Update contact dialog with send email button and new email address - #91

Closed
Daniel-ADFA wants to merge 2 commits into
stagefrom
bugfix/ADFA-514
Closed

ADFA-514: Update contact dialog with send email button and new email address#91
Daniel-ADFA wants to merge 2 commits into
stagefrom
bugfix/ADFA-514

Conversation

@Daniel-ADFA

Copy link
Copy Markdown
Contributor

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

Update contact dialog with send email button and new email address

@Daniel-ADFA
Daniel-ADFA marked this pull request as draft April 16, 2025 19:04
fryanpan added a commit that referenced this pull request Jul 30, 2026
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
fryanpan added a commit that referenced this pull request Aug 27, 2026
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
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

@Daniel-ADFA@alome007