Command

PePersonal JEJust Electrolyte RTRelease Timer TtTacTile CSClearSource AtAthletic

TacTile›Launch TacTile›Android›Android — Build & release·15 in this wave

Submit Android build for reviewTo do · blocker Approve: Android releaseTo do · blocker Seed a demo account — it blocks BOTH the Play screenshots and Caitlin's QA passBlocked · blocker Produce phone + tablet Play screenshotsBlocked Complete the Play Data Safety formIn progress Full device test pass on a physical Android phoneTo do Full device test pass on a physical Android tabletTo do Play Store review pre-flightIn progress Android CI + release automation (the wave goal had no task for it)Done Play feature graphic (1024x500) — hard submission requirement, nobody has filed itDone Public data-deletion page — Play requires it reachable WITHOUT sign-in (verified 307 today)Done The Android tier can be GREEN on a tree that does not clean-build — Hilt errors hide behind stale codegenTo do Write Play Store listing copyIn progress Play 7"/10" tablet screenshots — after the tablet adaptation landsTo do AssetsViewModelFailureTest flakes ~3% — cause not identified, symptom guarded not fixedTo do

Wave

Android — Build & release

No CI, no Play metadata, no release automation exist today. iOS has working Fastlane; Android has nothing.

TacTile › Launch TacTile › Android › Android — Build & release

3/15 done12 open3 open blockers

Selected taskclear

The Android tier can be GREEN on a tree that does not clean-build — Hilt errors hide behind stale codegen

To doOwner · ait_f31d41e6

No dependencies in this wave — nothing gates it, and nothing waits on it.

Show the prompt

You are Viv, the agent for the TacTile lane of Command.

Open the lane and work there:

```bash
cd ~/Command/tactile && claude
```

Read that lane's CLAUDE.md and lane.json before you touch anything — they
carry your identity, your scope, and the hazards specific to this lane.
Read state from the hub (https://internal.tactile.to) or ask. Never guess at it.

## The task

**The Android tier can be GREEN on a tree that does not clean-build — Hilt errors hide behind stale codegen** · to do

Where it sits: TacTile › Launch TacTile › Android › Android — Build & release

## The brief on file

OBSERVED 2026-08-09 by the round-19 Android session, and it is the most dangerous kind of gate hole: the check reports success on a tree that cannot build.

WHAT HAPPENED, in its words: `@Singleton` was added to `@IntoSet` set elements. `:app:compileDebugKotlin` passed. The full unit tier passed. Everything was green. A later `:app:clean` then failed with

    [Hilt] @HiltAndroidApp base class must extend Application

naming `Hilt_TacTileApp` — a GENERATED class with nothing to do with the change. **Every green before that clean had been reusing pre-existing codegen**: the annotation processor never re-ran, so it never re-validated the graph.

WHY THIS MATTERS MORE HERE THAN IT WOULD ELSEWHERE. `scripts/verify/android-unit-tests.sh` is the ONLY thing in this project that runs Kotlin — `gate.sh` has no Android check, and `.github/workflows/android.yml` is dead behind the Actions billing wall. So "green on a tree that cannot clean-build" is a state nothing else can detect, and it would merge.

I TRIED TO FIX THIS AND COULD NOT PROVE THE FIX. Recording the attempt so the next person does not repeat it:
 • Adding `./gradlew :app:hiltJavaCompileDebug --rerun-tasks` before the test run costs ~30s measured (vs ~4 minutes for clean + rebuild), which is an acceptable price.
 • **But I could not construct a mutation it catches.** I reproduced the session's described change — `@Singleton` on an `@IntoSet` provider in `di/SessionScopeModule.kt` — and the tree compiled and the tier passed. That scoping is evidently legal there, so my mutation was not their bug.
 • Shipping a gate step with no demonstrated failure it catches is the thing this project keeps catching in review. I reverted it rather than land an unproven check.

WHAT WOULD ACTUALLY SETTLE IT — do this before writing any gate code:
 1. **Get a reproduction.** Ask the round-19 Android session (or read its branch history) for the exact diff that produced the `Hilt_TacTileApp` error. Without it there is nothing to prove a fix against.
 2. With a reproduction in hand, establish WHICH task re-run detects it: `hiltJavaCompileDebug --rerun-tasks`, `kaptDebugKotlin --rerun-tasks`, or only a genuine `:app:clean`. They are not equivalent and the cost differs by an order of magnitude.
 3. Only then add it to the runner, with the mutation recorded in the script header the way its other guards are.

If no reproduction can be obtained, the honest fallback is a DOCUMENTED periodic clean — e.g. the runner prints a reminder, or the release path cleans — rather than a check that might detect nothing. Say which you chose and why.

RELATED, from the same session and worth reading first: its batch mutation harness twice reported mutations as GREEN that were genuinely RED when run by hand. It only noticed because the pattern was implausible (M4 and M5 reddened while M1/M2/M4 did not). Whatever harness you use here, verify a known-red case by hand before trusting a green.

## How to work this

- Do the work, don't just plan it. If the fix is obvious and safe, make it.
- Surface anything needing Matthew's sign-off instead of deciding it yourself.
- Short replies. Lead with the answer, then stop.
- Finish by saying what changed, what you verified, and what you'd do next.

To doIn progressDoneBlockedPick a wave on the left · tap a task to expand it

Lanes

Android — Build & release

The Android tier can be GREEN on a tree that does not clean-build — Hilt errors hide behind stale codegen