Command

PePersonal JEJust Electrolyte RTRelease Timer TtTacTile CSClearSource AtAthletic

TacTile›Launch TacTile›DevOps›DevOps Foundation·35 in this wave

Approve: DevOps FoundationTo do · blocker NEEDS MATTHEW: staging STRIPE_WEBHOOK_SIGNING_SECRETBlocked · blocker main is RED — 8 unit tests failing on origin/main, so pnpm verify cannot gate any PRDone · blocker The production account's data is 42 days stale — Analytics renders empty at any default windowBlocked · blocker MATTHEW: add db_url to the 1Password Supabase item — two RLS audits have never been runnableDone · blocker Wire apps/api test suite into CIDone Wire Playwright specs into CIDone Wire verify:swift-parity into CIDone Enable branch protection on mainBlocked Verify the staging environment is actually liveDone Web deploy workflow (manual trigger only)To do API deploy workflow (manual trigger only)To do Add post-deploy smoke test to the deploy workflowsTo do Write the rollback procedureTo do Add Sentry to iOSTo do Add Sentry to AndroidTo do Configure uptime monitoringTo do Set the three missing staging secrets on tactile-api-stagingDone Playwright is failing on main and producing no report — every run that gets a runner failsTo do Playwright job must free port 3000 BEFORE its first suite — a watchdog-killed job leaks its server and fails every later runDone Add CHANGELOG.mdTo do Automate release tagging on mainTo do Fix stale Vercel references in the observability runbookDone Add apps/api typecheck to CIDone Clean the SAST baselineTo do Flip SAST to blockingTo do Edge function deploy workflow (manual trigger only)To do Supabase migration check in CITo do Write the release procedureTo do Configure Supabase log drainTo do Centralize Cloudflare Workers logsTo do Replace console.* with structured logging in apps/apiTo do Two runners share one ~/.gradle — scope it per runner without losing the warm cacheTo do MATTHEW: CI capacity — one Mac, two runners, and a full Xcode build now runs on every pushTo do Auto-cancel queued CI runs whose head branch was deletedTo do

Wave

DevOps Foundation

Unblocked now — nothing waits on the surfaces. Wiring existing tests into CI, deploy automation, base observability.

TacTile › Launch TacTile › DevOps › DevOps Foundation

10/35 done25 open3 open blockers

Selected taskclear

main is RED — 8 unit tests failing on origin/main, so pnpm verify cannot gate any PR

DoneOwner · ait_c86b1105Blocker

8 failures across 3 test files on origin/main itself, not on any feature branch. QR scannability grading appears to have lost colour resolution entirely (contrast 0, method 'n/a'). Every PR's verify gate is red before the author writes a line.

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

**main is RED — 8 unit tests failing on origin/main, so pnpm verify cannot gate any PR** · done · blocker

8 failures across 3 test files on origin/main itself, not on any feature branch. QR scannability grading appears to have lost colour resolution entirely (contrast 0, method 'n/a'). Every PR's verify gate is red before the author writes a line.

Where it sits: TacTile › Launch TacTile › DevOps › DevOps Foundation

## The brief on file

Found 2026-08-05 by the iOS session while trying to satisfy its own "pnpm verify green" gate.

THIS IS ON MAIN, NOT ON A BRANCH. Proof: `git log --oneline origin/main..HEAD` on feature/ios returns
exactly ONE commit (57a1d275), and that commit touches only two .swift files under apps/ios. Swift files
cannot affect a vitest run. Independently confirmed by stashing those two files and re-running — identical
result, 8 failed / 2640 passed / 91 files, before and after. So origin/main is red on its own.

CONSEQUENCE: CLAUDE.md states "CI runs pnpm verify on every PR. If pnpm verify is green locally, CI will be
green." That is currently false in both directions — nobody can get a green gate, so the gate has stopped
discriminating between good and bad PRs. Anyone shipping right now is either waiving it or not looking.

THE THREE FILES
  tests/unit/qr-scannability.test.ts             5 of 21 failed
  tests/unit/scannability-tool.test.ts           2 of 15 failed
  tests/unit/contact-fields-absent-vs-empty.test.ts   1 of 25 failed

DIAGNOSIS — the two QR files share one signature and are almost certainly ONE bug.
The failures are not "grade drifted by a notch", they are "colour stopped resolving at all":
  - "expected +0 to be close to 3.45" — the moduleContrast ratio came back 0, not merely wrong.
  - "expected 'n/a' to be 'ratio'" — the factor reports NO measurement method.
  - "expected 'C' to be 'A+'" and "expected 'C' to be 'B'" — every design collapses to the same low grade,
    which is what you would expect if contrast is uniformly 0.
  - scannability-tool.test.ts:111 is literally named "ships the default design — the token background
    resolves to a measurable colour", and :141 "passes a plain black-on-white design". Plain black on white
    failing is conclusive: this is not a threshold-tuning regression, the colour input is not being parsed.
Look first at packages/qr-renderer/src/scannability/factors.ts and grade-scannability.ts (and
packages/mcp-server/src/tools/scannability.ts, which wraps them) for a changed colour-parsing or
design-token-resolution path — likely a token/hex format that no longer resolves, returning 0/'n/a' instead
of throwing.

contact-fields-absent-vs-empty.test.ts is probably SEPARATE: its failure is "expected 400 to be 200", i.e. a
request the suite considers valid is now rejected. Note the most recent commit touching these files is
5df9d42c "fix(tests): repair the contact-field tests my own #190 broke on main" — so this file has been
broken on main before and was patched once already. Worth checking whether that repair was complete or
whether the route's validation moved again underneath it.

WHY IT IS NOT FIXED HERE: all of it lives in packages/** and apps/api/**, which the iOS session is
explicitly scoped away from. Handing over rather than reaching across.

DONE WHEN: pnpm verify:unit is green on origin/main, and the absent-vs-empty contact semantics have a test
that fails loudly if the route's validation moves again — that file has now regressed twice.

WORTH CONSIDERING SEPARATELY: main was allowed to go red and stay red. Whatever branch protection or
required-check config was supposed to prevent that is either absent or not enforced on this repo.

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

DevOps Foundation

main is RED — 8 unit tests failing on origin/main, so pnpm verify cannot gate any PR