Fixed-scope product/UX sprint

rando.id Theme Editor UX Sprint

A $100 public-safe design packet for the open paid custom-theme-editor issue. It resolves editor surface, palette validation, paid gating, storage, and implementation slices without touching production data or posting externally.

Scope Flow Claim steps Acceptance text Draft response Prepared notes Repo packet CSV Payment activation

Sprint flow

1. Decide surface
In-app editor first, JSON import later unless the buyer accepts a different path.

2. Validate palette
Require light and dark slots, hex values, contrast checks, and stable theme IDs.

3. Gate paid value
Pro users save custom packs; free users can preview without saving.

4. Split implementation
Config validation, storage, web UI, native preview, paid gate, and tests as separate issues.

Open paid lead rows1

Primary sprint price$100

Confirmed money$0

Concrete Deliverable

UX decision record for in-app editor, JSON import, and future Figma/import paths.
User flow and information architecture from theme gallery through preview, save, apply, and export/share later.
Palette validation matrix for required slots, hex format, light/dark parity, contrast, stable IDs, and paid/free behavior.
Storage recommendation for user-owned custom packs and why Vercel Blob should wait for exported/marketplace assets.
Paid-gate recommendation using a new pro feature flag such as custom-theme-editor.
Implementation-ready issue split with acceptance criteria and test coverage locations.

Recommended User Flow

Settings -> Themes -> Create custom theme
-> Pick starting pack
-> Edit light palette
-> Edit dark palette
-> Validate contrast and required slots
-> Preview on contact/list/detail/settings samples
-> Save as private custom theme
-> Apply now

Exact Claim Steps

Open the live offer page, notes, and repo-grounded packet.
Add only your seller-owned payment URL before contacting anyone.
Open the source issue and review the labels and current body.
Use the draft response only after you approve it.
Require the exact acceptance sentence before payment.
Accept only public or buyer-authorized product constraints.
Deliver the design packet only after external payment proof.
Record buyer scope, payment reference, delivery URL, acceptance, payout/payable/cleared status, fees, and date.
Count $0 until the external proof shows posted, released, payable, cleared, credited, or verified net money.

Exact Acceptance Before Payment

The buyer must paste this before any paid work starts:

I accept the rando.id Theme Editor UX Sprint fixed-scope terms at $100. I understand work starts only after seller-owned external payment proof exists; I will provide only public or buyer-authorized product requirements and non-sensitive design constraints; the deliverable is limited to a repo-grounded UX decision packet, IA/user-flow map, palette validation rules, storage and paid-gate recommendation, acceptance criteria, and implementation-ready issue breakdown; and private user data, credentials, payment data, production database access, private analytics, proprietary design files, code implementation, public posting, pull requests, or ongoing revisions are not included unless separately agreed before payment.

Repo-Grounded Facts

File	Finding
specs/apps.md	The spec already names themes, user theme prefs, paid auto-seasonal behavior, and the deferred custom-theme editor decision.
packages/config/src/themes/index.ts	ThemePack has light and dark ThemePalette objects, paid flags, free/pro limits, and seasonal helpers.
packages/config/src/themes/example.theme.ts	The theme-authoring contract requires stable IDs and every palette slot in both light and dark mode.
packages/config/src/feature-flags.ts	The current free/pro flag model can host a new pro-only custom-theme-editor flag.

recent_open_paid_product_design_issue

Decision: theme editor for custom themes

Paid feature issue asks for a real UX design across editor surface, palette constraints, sharing, storage, and runtime theme plumbing.

Draft response not posted

I can turn this into a repo-grounded UX decision packet rather than jumping straight to implementation. I inspected the current theme spec and config: ThemePack already has light/dark palettes, custom kind, paid flags, free/pro limits, and the product spec already names themes and user_theme_prefs. For $100, I can deliver a concrete design that decides the editor surface, validation rules, storage model, paid gate, user flow, and implementation-ready issue split. I would not need private user data, production access, credentials, payment data, or proprietary design files, and I would only post a public follow-up or PR after explicit approval.

Draft response prepared only. External public comments, direct messages, pull requests, or form submissions require explicit send approval.

Prepared Design Notes

https://jaxassistant55.github.io/jax-micro-offer-studio/rando_theme_editor_design_notes.md

Notes excerpt

# rando.id Theme Editor UX Sprint Notes

Generated: 2026-06-20 16:17:20 JST
Public repo: https://github.com/rando-id/rando.id
Paid-feature issue: https://github.com/rando-id/rando.id/issues/53
Related product spec: https://github.com/rando-id/rando.id/blob/main/specs/apps.md
Inspected commit: `8a0ccca`
Fixed first sprint: $100
Confirmed money: $0

## Why this is viable

The issue is recent, open, labeled `paid`, and explicitly says the theme editor is a UX design exercise that should close when a real design exists. This is not a bounty and not a request for private data. The useful first paid deliverable is a repo-grounded product design packet that resolves the open surface decisions before implementation.

## Repo facts

- `specs/apps.md` already defines `themes` and `user_theme_prefs` tables with custom themes, light/dark palettes, paid flags, active theme, and paid auto-seasonal behavior.
- `packages/config/src/themes/index.ts` defines `ThemeMode`, `ThemePalette`, `ThemePack`, `FREE_THEME_LIMIT = 2`, `PAID_THEME_LIMIT = 5`, `getThemePack`, and seasonal window helpers.
- `packages/config/src/themes/example.theme.ts` documents the real theme-pack authoring contract and warns that theme IDs are stable storage keys.
- `packages/config/src/feature-flags.ts` has a simple `free | pro` tier model, but no `custom-theme-editor` flag yet.
- `packages/ui/src/tamagui.config.ts` creates Tamagui config from the default config; runtime custom themes need a design choice before code.
- `apps/web` and `apps/native` both consume the shared UI/config layer, so the design should avoid a web-only surface unless explicitly chosen.

## Decision packet deliverable

1. Product choice: in-app editor first, with JSON import as an advanced option after validation.
2. Editor IA: gallery, duplicate starting theme, edit light palette, edit dark palette, validate, preview, save, apply, share/export later.
3. Palette validation: every `ThemePalette` slot required, hex format only in v1, contrast gate for background/foreground and primary/background, visible border/muted contrast checks.
4. Paid gate: add `custom-theme-editor` as a pro feature while allowing free users to preview/import one sample without saving.
5. Storage: DB JSON for user-owned packs first; Vercel Blob only for exported files or future marketplace assets.
6. Tamagui constraint: generated user themes must be translated into the runtime theme shape without requiring a rebuild.
7. Test plan: pure validation tests in `packages/config`, route/component tests for save/apply flows, and web/native preview smoke tests.

## Suggested user flow

```text
Settings -> Themes -> Create custom theme
  -> Pick starting pack
  -> Edit light palette
  -> Edit dark palette
  -> Validate contrast and required slots
  -> Preview on contact/list/detail/settings samples
  -> Save as private custom theme
  -> Apply now
```

## Non-goals

- No production database changes in this first sprint.
- No private user data, credentials, payment data, or production analytics.
- No public comment, issue close, or PR without explicit approval.
- No full implementation promise inside the $100 design sprint.
- No marketplace, revenue share, or paid creator program design unless separately accepted.

## Draft response, still not posted

I can turn this into a repo-grounded UX decision packet rather than jumping straight to implementation. I inspected the current theme spec and config: `ThemePack` already has light/dark palettes, `custom` kind, paid flags, free/pro limits, and the product spec already names `themes` and `user_theme_prefs`. For $100, I can deliver a concrete design that decides the editor surface, validation rules, storage model, paid gate, user flow, and implementation-ready issue split. I would not need private user data, production access, credentials, payment data, or proprietary design files, and I would only post a public follow-up or PR after explicit approval.

Repo-Grounded Handoff Packet

https://jaxassistant55.github.io/jax-micro-offer-studio/rando_theme_editor_repo_grounded_packet.md

Packet excerpt

# rando.id Theme Editor Repo-Grounded Handoff Packet

Generated: 2026-06-20 16:17:20 JST
Offer page: https://jaxassistant55.github.io/jax-micro-offer-studio/rando-theme-editor-ux-sprint.html
Public repo: https://github.com/rando-id/rando.id
Local public clone: `/Users/jax/autonomous_earning_run_2026-06-09/non_bounty/rando.id`
Inspected commit: `8a0ccca`
Paid-feature issue: https://github.com/rando-id/rando.id/issues/53
Fixed first sprint: $100
Confirmed money: $0

## Current issue state

The issue asks for a paid theme editor UX design. It is open, labeled `paid`, and explicitly says to close it when a real design exists. The first paid unit should be a design packet, not a public PR or implementation promise.

## Files inspected

1. `specs/apps.md`
   - Defines `themes` with `id`, `name`, `kind`, `light_palette`, `dark_palette`, `active_from`, `active_to`, and `is_paid`.
   - Defines `user_theme_prefs` with `mode`, `active_theme_id`, and paid `auto_seasonal`.
   - Places multiple themes in v0.2 and paid auto-theme/random/avatar/list features in v0.3+.
   - Lists custom theme editor as a deferred paid design question.

2. `packages/config/src/themes/index.ts`
   - Defines `ThemeMode = light | dark | system`.
   - Defines `ThemePalette` slots: `background`, `foreground`, `primary`, `secondary`, `accent`, `muted`, and `border`.
   - Defines `ThemePack` with `default | seasonal | custom`, light/dark palettes, optional seasonal windows, and `isPaid`.
   - Exposes `FREE_THEME_LIMIT = 2` and `PAID_THEME_LIMIT = 5`.

3. `packages/config/src/themes/example.theme.ts`
   - Documents the pack-authoring contract.
   - Warns that theme IDs are storage and URL keys, so rename/migration behavior must be designed.
   - Keeps every palette slot required in both light and dark mode.

4. `packages/config/src/__tests__/themes.test.ts`
   - Current test coverage validates limit constants, default lookup, and seasonal windows.
   - New custom-theme validation should live near this package before UI work.

5. `packages/config/src/feature-flags.ts`
   - Existing flags use `free | pro` tiers.
   - Suggested new flag: `custom-theme-editor: pro`.

6. `packages/ui/src/tamagui.config.ts`
   - Tamagui config is created from the default config.
   - Runtime custom themes require an implementation design before the UI is built.

## Recommended scope

Deliver in the first $100 sprint:

1. UX decision record for in-app editor versus Figma/JSON import.
2. End-to-end flow and information architecture.
3. Palette validation rules and error copy.
4. Preview-state checklist across contact list, contact detail, list detail, settings, and empty states.
5. Storage recommendation for user-owned custom packs.
6. Paid-gate and free-preview behavior.
7. Implementation-ready issue split with acceptance criteria.

Defer:

1. Full implementation.
2. Theme marketplace.
3. Creator revenue share.
4. Production database migration.
5. Public PR or issue comment without explicit approval.

## Exact user steps to claim this lane

1. Open the live offer page: https://jaxassistant55.github.io/jax-micro-offer-studio/rando-theme-editor-ux-sprint.html
2. Open this packet: https://jaxassistant55.github.io/jax-micro-offer-studio/rando_theme_editor_repo_grounded_packet.md

Money And Posting Boundary

Signal	Counted as money?
This page, CSV, prepared notes, lead search, draft response, metadata, or IndexNow result	No. Counts $0.
The issue is labeled paid or a maintainer likes the design idea	No. Requires exact accepted scope and external payment proof.
External payment posted, released, payable, or cleared after delivery proof and any platform acceptance	Yes. Count only verified net amount after fees/refunds.

No public GitHub comments, pull requests, direct messages, payment requests, production access, or private data handling were made by this script. External sending requires explicit approval.