Command

PePersonal JEJust Electrolyte RTRelease Timer TtTacTile CSClearSource AtAthletic

TacTile›Inbox — on deck·49 in this wave

Wave

Inbox — on deck

Briefs Nova has teed up and are ready to run — each task's prompt is a complete, self-contained brief.

TacTile › Inbox — on deck

39/49 done10 open3 open blockers

Selected taskclear

Decide the triggers for the 6 system error screens — all are unreachable

To doOwner · met_85513078

All six system sheets (loading, no internet, server error, scan failed, scan permissions, action not found) are built and wired into RootView but nothing ever triggers them. Needs a product decision on what each should respond to before anyone wires them.

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

**Decide the triggers for the 6 system error screens — all are unreachable** · to do

All six system sheets (loading, no internet, server error, scan failed, scan permissions, action not found) are built and wired into RootView but nothing ever triggers them. Needs a product decision on what each should respond to before anyone wires them.

Where it sits: TacTile › Inbox — on deck

## The brief on file

Matthew — raised by Caitlin during the iOS Core-surfaces QA pass, 2026-09-01. Needs your call before any code is written; the work itself is small, the decision is not.

WHAT WAS FOUND. Caitlin went offline expecting the no-internet screen and got nothing. It is not the demo data masking it — the six system screens CANNOT APPEAR AT ALL.

Proven by grep rather than inferred. `systemSheet` appears exactly five times in the entire app:
  · System/Navigation/RootView.swift:54  — @State private var systemSheet: SystemSheet?
  · System/Navigation/RootView.swift:89  — .sheet(item: $systemSheet)
  · System/Navigation/RootView.swift:137 — .sheet(item: $systemSheet)
  · Screens/UIVCatalog.swift:104, 902 — the internal dev catalog
There is NO assignment anywhere in the codebase. The state is declared, read by two presenters, and never written, so it stays nil for the life of the app. AppLoadingView, NoInternetView, ServerErrorView, ScanFailedView, ScanPermissionsView and ActionNotFoundView (System/Sheets/SystemSheetViews.swift) are complete, styled, wired into RootView.sheetView(for:) — and reachable only from the dev catalog.

WHY IT MATTERS AT LAUNCH. With no connectivity the app explains nothing: each screen falls back to its own behaviour, which is stale cache or silence. AnalyticsAPIClient caches GETs for 120s, so an offline user can be shown data that looks live. A customer whose scan fails, whose camera permission is denied, or whose destination 404s gets no dedicated screen for any of it.

WHAT IS NEEDED FROM YOU — four decisions, each of which changes the wiring:
  1. What counts as "no internet"? A reachability check up front, or the first failed request? The first is proactive and can be wrong; the second only fires after a user waits.
  2. Which HTTP statuses justify a full-screen serverError versus a quiet retry or an inline message? A 500 on one analytics widget should probably not take over the screen.
  3. Does actionNotFound belong here, or on the destination viewer where the 404 actually happens?
  4. Should these be SHEETS at all? Several read better as inline states on the screen that failed — a sheet over a working screen implies the whole app is broken.

They were deliberately NOT wired during QA: attaching them to arbitrary conditions would be guessing at product behaviour, and wrong error handling is worse than none.

WIDER PATTERN, worth one look rather than three tickets: this is the THIRD complete-but-unreachable screen found in a single session. The others are t_3d9d5b6b (Help Center Quick tutorial — full screen, no entry point, only referenced by UIVCatalog) and t_378d48ce (Android QrListScreen — built, dead-ended by MainShell wiring). In each case the code compiles, the screen looks finished in the catalog, and nothing flags that no user can reach it. A cheap guard would be a test asserting every screen in UIVCatalog has at least one non-catalog reference.

Full QA detail on t_d563d8a8.

## 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

Inbox — on deck

Decide the triggers for the 6 system error screens — all are unreachable