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

QR parity: 15 snapshot fields have no control on either web surface, and none are documented as deliberate

To doOwner · ait_ea41bace

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

**QR parity: 15 snapshot fields have no control on either web surface, and none are documented as deliberate** · to do

Where it sits: TacTile › Inbox — on deck

## The brief on file

Found while auditing "what remains of QR depth" (round-9 web session, 2026-08-07). This is the honest remainder after the logo-crop and shape-vocabulary work landed.

QRCodeDesignSnapshot (packages/qr-renderer/src/types/snapshot.ts) carries fields that NO web surface can edit — not the desktop studio (apps/web/features/qr), not the mobile editor (apps/web-mobile/features/qr):

  · lighting (5): lightingEnabled, lightingColorHex, lightingOpacity,
    lightingDepth, lightingSoftness
  · background image overlay (4): backgroundImageData, backgroundImageOpacity,
    backgroundImageTransform, backgroundImageFadeHex
  · QR image overlay (4): qrImageData, qrImageOpacity, qrImageTransform,
    qrImageFadeHex
  · logoShape, logoSliderValue (logoCornerRoundingPercent is now written by
    web-mobile via the crop work; these two are still unwritten by any TS client)

WHY THIS IS REAL WORK AND NOT A DOCUMENTED DECISION: the resolver actively READS
all of them — buildLighting, buildBackgroundImage and buildQRImage exist in
packages/qr-renderer/src/snapshot/resolve-options.ts and are wired into
resolveRenderOptions. So they render if set; there is simply no way to set them
from web. Contrast decorativeOutlineColorLocked, which IS documented as
deliberately unexposed (apps/web/features/qr/components/DecorativeGroup.tsx:25-32)
precisely because nothing in the TS renderer reads it. These fifteen have no such
note anywhere.

ALSO WORTH KNOWING — the mobile editor has no control at all for: decorative
frame, sticker frame, randomized palette, background/marker gradients,
background transparency, finder eye colour overrides. It carries them through
unchanged for a loaded carried design but cannot edit them. Desktop has all of
those. That desktop/mobile asymmetry may be intentional (small screen), but it
is not written down anywhere either.

SUGGESTED SHAPE OF THE WORK: decide per group whether it ships or is explicitly
declared out of scope in the AGENTS.md / a context decision — the point is that
"reads but cannot be set" stops being an undocumented accident. If a group
ships, follow the established correct-by-construction pattern: derive what the
UI offers from the resolver rather than hardcoding a list (see
apps/web/features/qr/lib/honoured-shapes.ts and its new web-mobile mirror).

NOT BLOCKED. No dependency; this is scoping plus build.

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

QR parity: 15 snapshot fields have no control on either web surface, and none are documented as deliberate