Command

PePersonal JEJust Electrolyte RTRelease Timer TtTacTile CSClearSource AtAthletic

TacTile›Launch TacTile›Web›Web — QR management·15 in this wave

Approve: QR managementTo do · blocker BUG: dynamic-QR detection hardcodes tactile.to, so white-label codes render the wrong symbolDone SPEC → backend: move QR render glue into the package, and make program_mode first-classTo do Build the desktop QR creation/design studioTo do Wire desktop 'Edit Design' to the new QR studioDone Make the desktop QR static/dynamic toggle functionalBlocked Bring QR module/eye shape pickers to the full native set on both web surfacesTo do Add gradient design controls to QR codes on both web surfacesDone Add per-eye frame and inner color controls to QR codes on both web surfacesDone Add interactive logo crop to QR logo embedding on both web surfacesDone Add the decorative shape library to QR codes on both web surfacesTo do Add stickers to QR codes on both web surfacesTo do Add QR readability/scannability grading to both web surfacesDone Add pixel randomizer, background image, and lighting effect to QR codes on both web surfacesTo do Sign off: QR management parityTo do

Wave

Web — QR management

New wave, created 2026-07-26 following Matthew's full-parity decision: 'on web, manage all the destinations and QR codes... do everything except physically encode the NFC.' Today apps/web (desktop) has ZERO QR design capability — TriggerLaunchpadPage.tsx explicitly stubs 'Edit Design' with 'QR Studio lives in the mobile apps for now' (line 278) and its Dynamic/Static toggle is decorative, not functional (lines 303-317). apps/web-mobile has a real but shallow QR editor (QREditorPage.tsx) — close to parity on shape picking (19/23 module shapes, 4/5 frames, 14/14 inners) but missing gradients, per-eye color, decorative shapes (58 unused assets), stickers, logo interactive crop, readability/scannability grading, pixel randomizer, lighting, and background image — all of which the native iOS QR studio (QRGeneratorPage.swift, 8,725 lines) has, and all of which the shared @tactile/qr-renderer engine already supports render-side. This wave brings both web surfaces to native QR-management parity.

TacTile › Launch TacTile › Web › Web — QR management

6/15 done9 open1 open blocker

Selected taskclear

Add pixel randomizer, background image, and lighting effect to QR codes on both web surfaces

To doOwner · Vivt_d6c8ef5c

Viv — Add the pixel/module color randomizer, background image overlay, and lighting/sheen effect controls, matching native's QRCodeDesignSnapshot fields. Done when: all three controls are present and apply live to the QR preview on both apps/web and apps/web-mobile. File: apps/web-mobile/features/qr/, apps/web/features/qr/.

Unlocks 1Approve: QR management

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

**Add pixel randomizer, background image, and lighting effect to QR codes on both web surfaces** · to do

Viv — Add the pixel/module color randomizer, background image overlay, and lighting/sheen effect controls, matching native's QRCodeDesignSnapshot fields. Done when: all three controls are present and apply live to the QR preview on both apps/web and apps/web-mobile. File: apps/web-mobile/features/qr/, apps/web/features/qr/.

Where it sits: TacTile › Launch TacTile › Web › Web — QR management

## Unlocks 1

- Approve: QR management

## The brief on file

Viv — QR control parity ledger. Still todo. Round 19 verified the cell counts but did NOT build the scan.

MEASURED AT cf312312 — 1 of 6 cells, not "mostly done":

  randomizer        apps/web YES (features/qr/components/RandomizerGroup.tsx) · web-mobile NO
  sticker           apps/web YES (StickerGroup.tsx)                           · web-mobile NO  [t_814edc23]
  decorative        apps/web YES (DecorativeGroup.tsx)                        · web-mobile NO  [t_ccc3b2df]
  background-IMAGE  NEITHER SURFACE. BackgroundGroup.tsx is background COLOUR /
                    gradient / transparency — an easy misread. There is no
                    background-image control anywhere.
  lighting          NEITHER SURFACE.
  (mobile total)    QREditorPage.tsx:70-76 — ActiveSheet is "module" | "eyeFrame" |
                    "eyeInner" | "fgColor" | "bgColor" | null. Five controls, and
                    that is the entire mobile inventory.

THE SCAN IS THE DELIVERABLE and it is still unwritten. Design notes gathered this round, so the next
session does not re-derive them:

1. DO NOT derive the family set from field-name PREFIXES. It fails both of the check's own mutations:
   moduleColorHex / moduleShape / moduleRandomizerMode share "module", so deleting RandomizerGroup
   leaves family "module" covered by the colour and shape controls; backgroundColorHex /
   backgroundFillMode / backgroundImageData share "background", so web-mobile's bgColor sheet covers
   the family — which is the exact broken instrument that closed the two siblings.
   The comment banners in packages/qr-renderer/src/types/snapshot.ts are the better source, but note
   one banner covers BOTH backgroundImage* and qrImage*, so no family is literally named
   backgroundImage. Pick ONE mechanism, write it in the header, and pin a floor on the family count.

2. DO NOT anchor "exposed" on patch({...}) call sites. apps/web has 28; apps/web-mobile has ZERO — it
   uses setCarried((c) => ({...c, snapshot: {...c.snapshot, moduleShape: v}})) over a state reducer.
   A patch-anchored rule reports web-mobile as covering NOTHING including its five real controls, at
   which point "lighting and backgroundImage missing" is true for the wrong reason. Use a
   surface-agnostic rule (a snapshot field as an object key in non-comment code) and make sure it is
   not fooled by moduleShape: state.moduleShape, which is save-artifact assembly, not a control.

3. EXCLUDE pending-design.ts AND record-design.ts BY EXACT PATH and assert the excluded set. They are
   deserializers; pending-design.ts writes every snapshot field and renders nothing, and that is what
   closed t_814edc23 and t_ccc3b2df.

4. POSITIVE CONTROL IS REQUIRED: assert the ledger reports web-mobile as COVERING its five real
   controls. A broken exposure parser and a genuinely empty surface look identical, and "everything
   missing on web-mobile" would otherwise pass vacuously.

5. State in the header that a presence-ledger is the same class of instrument as the field-mention
   check that closed the siblings, one level up: a control that is present but INERT still counts as
   exposed. The render-diff proof this row already prescribes is complementary, not an alternative.

Do NOT weaken tests/unit/qr-studio-shape-coverage.test.ts to make a picker pass — an earlier round
nearly did.

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

Web — QR management

Add pixel randomizer, background image, and lighting effect to QR codes on both web surfaces