docs(engagement): the in-app channel on Android, as built (Phase 8) #190

wtclaude · 2026-08-31T14:29:35Z

wtclaude commented

2026-08-31 14:29:35 +00:00

Documentation for engagement Phase 8 (Android-app#42), and the answer to §7.1 Q8.

`website/ENGAGEMENT.md`

Phase 8 marked ✅ with its as-built section: the four decisions settled before any code, the relative-url finding, the ref-not-stream routing rule, the snapshot scoping, the on-device walk, and the one thing the phase deliberately did not fix.
§7.1 Q8 answered in place — the trigger now runs on PRs into edge; sonarqube.yml was left alone on purpose (a push-on-main analysis is not a PR gate). Q9 is now the only open question.
The Status paragraph was six phases stale — it claimed "everything from Phase 5 on is still design" while 5a, 5b, 6 and 7 had all landed. It now names every phase that has landed with its PRs.
The documentation matrix row for Phase 8 names what actually landed.

`android/PLAN.md`

§7's "no offline caching, no Room in v1" decision STANDS, and now names its one exception plus the limit that comes with it: the snapshot serves a running app, not a cold start, because MainActivity gates the whole shell on loading the site's appearance. Changing that is a change to the shell's startup model and was left for the org lead rather than widened into this phase.
§11 gains the inbox and the per-channel screen as built, replacing the forward-looking "Phase 8 is where the app grows the inbox" paragraph — including the two things the app has to do that the backend contract does not state (resolve the relative url; route the tickle on its ref).

Why the `url` note matters beyond this phase

Phase 7's acceptance specifies url is relative-only and validates it as such. That is right for a browser already on the site and a dead link on a phone — the live rig found every link in the app's inbox doing nothing. The contract is unchanged; what was missing was anyone writing down the client's half of it, which is now in both documents.

AI-assisted: written with Claude Code (Claude Opus).

🤖 Generated with Claude Code

Documentation for **engagement Phase 8** (Android-app#42), and the answer to §7.1 **Q8**. ## `website/ENGAGEMENT.md` - **Phase 8 marked ✅ with its as-built section**: the four decisions settled before any code, the relative-`url` finding, the ref-not-stream routing rule, the snapshot scoping, the on-device walk, and the one thing the phase deliberately did not fix. - **§7.1 Q8 answered in place** — the trigger now runs on PRs into `edge`; `sonarqube.yml` was left alone on purpose (a push-on-`main` analysis is not a PR gate). **Q9 is now the only open question.** - **The Status paragraph was six phases stale** — it claimed "everything from Phase 5 on is still design" while 5a, 5b, 6 and 7 had all landed. It now names every phase that has landed with its PRs. - The documentation matrix row for Phase 8 names what actually landed. ## `android/PLAN.md` - **§7's "no offline caching, no Room in v1" decision STANDS**, and now names its one exception plus the limit that comes with it: the snapshot serves a running app, **not a cold start**, because `MainActivity` gates the whole shell on loading the site's appearance. Changing that is a change to the shell's startup model and was left for the org lead rather than widened into this phase. - **§11 gains the inbox and the per-channel screen as built**, replacing the forward-looking "Phase 8 is where the app grows the inbox" paragraph — including the two things the app has to do that the backend contract does not state (resolve the relative `url`; route the tickle on its `ref`). ## Why the `url` note matters beyond this phase Phase 7's acceptance specifies `url` is **relative-only** and validates it as such. That is right for a browser already on the site and a dead link on a phone — the live rig found every link in the app's inbox doing nothing. The contract is unchanged; what was missing was anyone writing down the client's half of it, which is now in both documents. --- - [x] AI-assisted: written with Claude Code (Claude Opus). 🤖 Generated with [Claude Code](https://claude.com/claude-code)

wtclaude added 1 commit 2026-08-31 14:29:36 +00:00

docs(engagement): the in-app channel on Android, as built (Phase 8) b1851ad8c1

Records Phase 8 and answers §7.1 Q8, leaving Q9 as the only open question.

ENGAGEMENT.md gains the phase's as-built section: the four decisions settled
first, the relative-url finding the live rig caught (Phase 7's contract is
relative-only, and the client half of that contract was never written down), the
ref-not-stream routing rule, the (base URL, user id) snapshot scoping that is the
actual security property, and the on-device walk. Its Status paragraph was six
phases stale and now names every phase that has landed.

android/PLAN.md §7's "no offline caching, no Room in v1" decision STANDS and now
names its one exception, with the limit it comes with: the snapshot serves a
running app, not a cold start, because the shell gates the whole app on loading
the site's appearance. Widening Phase 8 into the shell's startup model is the
org lead's call, so it is written up rather than done. §11 gains the inbox and
the per-channel screen as built.

Co-Authored-By: Claude <noreply@anthropic.com>

whitlocktech merged commit 400873b83a into edge

2026-08-31 14:36:36 +00:00

whitlocktech deleted branch docs/engagement-inapp-android

2026-08-31 14:36:36 +00:00

whitlocktech referenced this issue from a commit

2026-08-31 14:36:37 +00:00

Merge pull request 'docs(engagement): the in-app channel on Android, as built (Phase 8)' (#190) from docs/engagement-inapp-android into edge

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: RunicGateway/docs#190

docs(engagement): the in-app channel on Android, as built (Phase 8) #190

website/ENGAGEMENT.md

android/PLAN.md

Why the url note matters beyond this phase

`website/ENGAGEMENT.md`

`android/PLAN.md`

Why the `url` note matters beyond this phase