Assign Family — Launch Readiness

2026-07-07 · 5 products evaluated top-down (real code · git · build config · handovers) · one design system, five brands
Readiness ranking
Employees
Near-launch · backend feature-complete (126 tests) + native ~95%
88%
Gift Cards
Near-launch · sell/reload/balance work on-device
87%
Design foundation
Building · library builds + consumed by 3 apps; console = spec
85%
Waivers
Building · native signing works; public endpoints + web console missing
75%
Customers
Building · worker-auth blocker + web backend ~59 endpoints TODO
65%
Family-wide blockers (hit every app — fix once, unblock all)
① 20 Clover subscription IDs not created — 4 tiers × 5 apps. Every app's live tier gating is blocked until these exist in the Clover dashboard. Gating code is built; the wire IDs are missing. Jay + Clover
② Tier scheme drift (3→4) — Employees' shared registry (tiers.ts / app_installs) is the canonical 4-tier Essential/Plus/Pro/Premium. Customers / Waivers / Gift Cards code is still 3-tier (STANDARD/PLUS/PLUS_PLUS or ESSENTIAL/PLUS/PRO) and each defines its own enum instead of reading the registry. Align all to read Employees' registry.
③ Web layer is fragmented — Customers = standalone Nuxt (~59 endpoints TODO), Waivers web console = doesn't exist, umbrella assign-x-web-app = empty (0 LoC, framework undecided). This is the least-aligned surface; pick one strategy.
④ Account/secrets config pending — RAID gateway ID (Gift Cards), release keystores + Bugsnag keys (Waivers, Gift Cards), worker auth token (Customers). All Jay's account actions; each blocks a production build.
⑤ Design-system gaps — 7 of 8 responsive layout-w600dp skeleton variants missing (wide Mini/Station reflow) + no semver tag (submodule pins are opaque commit hashes).
Per-project detail

●Assign Employees Near-launch

Node/TS platform + Cloudflare Workers + D1 · native Android (6 screens) · web owner console · employee self-service (iOS+Android) · hosts the shared entitlement registry
Works
  • Backend feature-complete: 25+ endpoints, 126 unit tests passing
  • 4-tier tiers.ts + app_installs registry — the family's source of truth
  • Native UI ~95% (Home/roster/assign/reports/splits/settings), web console builds
Blockers
  • Clover subscription IDs not wired → tier sync fails
  • Essential/Plus not gated in native (only Pro/Premium); advanced %/$ split math unverified
  • iOS owner app not built (v1.1); realtime re-gating not implemented
Next
  • Wire Clover IDs → tiers.ts · add Essential/Plus gating · E2E validation → ship Android+web v1 in ~2–3 days

●Assign Gift Cards Near-launch

Native Kotlin (Clover SDK, targetSdk-25) · Redeemables Worker API · web (marketing live) · consumes design-system submodule
Works
  • Sell / reload / check-balance verified on-device; integer-cents money math
  • Emerald rebrand + design-system components; PINs never shown
Blockers
  • Redeem → Clover tender integration is a stub — order won't show the gift-card payment line
  • RAID gateway ID blank → live card charges fail
  • Offline sync deleted on align/family-nucleus branch — intent unclear; messy tree
  • Web balance page blocked on backend contract; domain/zone setup incomplete
Next
  • Reconcile the branch · verify/implement tender · set RAID + tier IDs → ~1–2 dev-weeks

●Assign Waivers Building

Native Kotlin signing app (Views, targetSdk-25, no GMS) + Cloudflare Worker (D1/R2/KV) · consumes design-system
Works
  • On-device signing, signature capture, DL-prefill, minors/guardian, offline queue, checkout gate
  • Template CRUD + immutable versioning; PDF→R2; indigo design-system chrome
Blockers
  • Public signing endpoints not implemented — QR / SMS-link / embed / web-kiosk all depend on them
  • Web console repo doesn't exist (merchant dashboard, template builder, compliance)
  • Clover product IDs / keystore / Bugsnag placeholders; AI + compliance backend not built
Next
  • Build the cfworker public /v1/signings/* endpoints · stand up assign-waivers-web · account config

●Assign Customers Building

Native Kotlin + companion Worker · web = Nuxt 2 + Worker + D1 · consumes design-system (native); web is a separate stack
Works
  • Native search / assign-to-order / barcode-DL / discount groups; worker+web tests pass (20/20, 39/39)
  • Web UI built (list/detail/merge/reconcile/activity-log), builds green
Blockers
  • Worker auth 401 on dev hardware — blocks barcodes, discounts, profiles (P1)
  • Tier 3→4 migration incomplete; Premium features not stubbed in native
  • Web: ~59 backend endpoints TODO (loyalty, campaigns, analytics, import/export, cross-app)
  • OTA not wired (no R2 bucket); web on dev branch, not promoted
Next
  • Fix worker auth · migrate tiers · add Home + Premium stubs · wire critical web endpoints → ~2–3 weeks

●Design Foundation Building

assign-design-system Android library (37 components, 95 Iconic-Pro icons) + assign-brand console/source-of-truth + assign-x-web-app (empty)
Works
  • Library builds; accent-attr mechanism; actively consumed via submodule by 3 native apps
  • Console assembles; source-of-truth deployed (assign-ds.pages.dev); handovers distributed
Blockers
  • 7 of 8 responsive layout-w600dp skeleton variants missing (wide form factors)
  • No semver version tag; assign-x-web-app umbrella empty (framework undecided)
  • Tier matrix (ASSIGN-FAMILY-TIERS.md) proposed, not ratified
Next
  • Ratify tiers · build the 7 skeleton variants · tag v1.0.0 · decide web-console stack
Recommended setup — one session conducts, the fleet executes

The "Conductor" model reuses your existing claude-dev-team fleet

You stop maintaining 5 chat sessions. You talk to one conductor; it fans work out to ephemeral per-repo executors through the work queue, and reviews the results. Consistency is guaranteed structurally — every app builds from the same design-system submodule and reads the same entitlement registry, so they can't drift.

Youone chat
→
Conductor sessionassign-brand · owns design-system,
tiers, the plan, review
→
Work queueteam.greyskymedia.com
/api/work
→
Argus (cron) / per-repo
executor sessionsephemeral · build from
the shared submodule
↺
Design-review gateback to conductor
Why this is the best use of resources
  1. One brain, many hands. The conductor holds the whole-family plan; executors are spun up per job and die — no five idle, context-heavy sessions burning tokens. Argus already drains the queue hourly on cron.
  2. Consistency is structural, not manual. Apps implementation project(':design-system') the same library (already wired in 3 apps) and read Employees' app_installs registry — same components, same tiers, same behavior by construction.
  3. No context-switching. You steer the conductor in your words ("build the record screen across all apps", "migrate every app to 4-tier") — it enqueues one job per repo, they run, it reviews and reports. One pane of glass.
Setup steps (mostly already in place)
  1. Designate assign-brand as the conductor/director repo; register the 5 apps as fleet project slugs.
  2. Confirm each app repo has: design-system submodule wired ✓, its CLOVER-APP-HANDOVER.md ✓, USING-THE-DESIGN-SYSTEM.md + CLAUDE.md pointer ✓ (done for most).
  3. Standardize tiers once: ratify ASSIGN-FAMILY-TIERS.md, create the 20 Clover IDs, make Employees' tiers.ts/app_installs the single registry, migrate each app's enum to read it.
  4. Drive development in waves (screen-by-screen or blocker-by-blocker) across all apps so the conductor can eyeball consistency before advancing.
  5. Keep one source of truth (assign-ds.pages.dev); retire the dashboard-only viewer.

Considered & rejected: a monorepo (turborepo/nx, design-system as a package). It would also give consistency, but the stacks are too different (Kotlin native · node platform · cfworker · Nuxt) — the migration cost + risk outweigh the benefit. The submodule + work-queue model already delivers the consistency without moving anything.