Tasks

Overview

I split the request into four task-board-ready tasks because the work naturally has two separate tracks:

Design system track
- First create/adapt a Music Study design system from the existing design-system repo.
- Then integrate those primitives into music-study.
Mobile release track
- First research the current iOS/Android release path and clarify Expo Go, TestFlight, EAS, App Store, and Play Store.
- Then implement an Expo/React Native mobile version.

This keeps the work agent-friendly: research stays separate from implementation, and the design-system work is not mixed with App Store release work.

What I found in the existing repos

`tasks`

The task board expects Markdown tasks in content/tasks, with YAML frontmatter, Original request, and Structured task. The structured task needs Problem, Context, Expected, and Notes. Research tasks use area: "research" and go to the research board automatically.

`music-study`

The app is already organized in a good way:

src/theory/ contains the music-theory engine.
src/hooks/ handles orchestration/state.
src/components/ is grouped by feature.
src/i18n/ centralizes strings.
src/index.css currently contains a large visual token/style layer.

This is good because the design-system work can be mostly visual. The music theory engine does not need to be rewritten just to improve the UI.

`design-system`

The existing design-system repo is a strong source to copy structurally:

shadcn/ui base layer in src/components/ui/*.
Product primitive layer in src/components/rp/*.
Token source of truth in src/style.css.
Vite showcase app.
DialKit live controls.
Interface Kit.
Agentation.
shadcn-compatible registry.json.
build:registry script.
Agent skills mirrored across .claude, .agents, and .gemini.
A cloning guide at docs/cloning-this-system.md.

The main thing not to copy is the Regular Punks identity: orange accent, dark industrial HUD language, NFT/game components, wallet components, fighter cards, challenge cards, etc.

Recommended design-system approach

For Music Study, I would not start with a huge external package immediately.

The best practical path is:

Clone/adapt the existing design-system as a Music Study design-system foundation.
- Keep the structure, skills, showcases, registry, DialKit, Agentation, and shadcn layer.
- Replace Regular Punks-specific identity and components.
Create only Music Study primitives at first.
- MsButton
- MsCard
- MsPanel
- MsTabs
- MsSegmentedControl
- MsNoteButton
- MsEnharmonicNoteSelector
- MsDegreeCell
- MsScaleCard
- MsChordCard
- MsModeCard
- MsTheoryCallout
Sync into music-study explicitly.
- Use either a shadcn-compatible registry pull or a small script that copies selected primitive source files into the app.
- This is less magical, but much safer for agents.
Only later consider package/monorepo sync.
- A package gives a more “edit in design system, instantly consume in app” feeling.
- But it adds dependency/build/watch complexity.
- For a small app, registry/source sync is easier to reason about.

How synchronization should work

There are three realistic options.

Option A — Local primitives only

Put everything directly in music-study/src/components/ms.

Best for speed.
Worst for reusable design-system workflow.

Option B — Separate design-system with explicit sync

Keep a Music Study design-system repo/folder and sync selected primitive files into music-study.

Best starting choice.
It matches shadcn philosophy: components become source files in the consuming app, so agents can edit them easily.

The flow:

music-design-system
  src/components/ui/*
  src/components/ms/*
  registry.json
  public/r/*

music-study
  src/components/ui/*
  src/components/ms/*

When a component is ready:

design-system showcase / DialKit tuning
        ↓
bake values into source
        ↓
build registry or run sync script
        ↓
copy/install component into music-study
        ↓
refactor app screen to use it

Option C — Package or monorepo

Use @music-study/design-system as a dependency.

Best for true shared source.
More complex with Vite, Tailwind content scanning, local linking, and versioning.

This is good later, after the primitive API stabilizes.

My recommendation

Use Option B first.

It gives you the thing you like from the existing design-system — showcase, components, skills, live tooling — without making the small music app dependent on a complicated package workflow too early.

Mobile path summary

The icon in your screenshot looks like TestFlight. That is Apple’s beta testing app for iOS apps before App Store release.

Important distinction:

Expo Go: fast development/testing app for running an Expo project on your phone.
TestFlight: beta distribution for real iOS builds through App Store Connect.
App Store: final public release.
Google Play internal/closed testing: Android equivalent testing path before public release.

A likely path for Music Study:

React web app today
    ↓
Extract/share pure theory logic
    ↓
Create Expo React Native app
    ↓
Test with Expo Go
    ↓
Use EAS Build for real iOS/Android builds
    ↓
Use TestFlight for iOS beta testing
    ↓
Use Google Play internal/closed testing for Android
    ↓
Submit to App Store / Play Store

Important limitation

I could not do live web research in this environment, so the mobile release task explicitly asks the future agent to verify current Apple, Google, and Expo requirements before making final submission decisions. App Store and Play Store rules can change.

Files generated

fork-music-study-design-system-from-existing-design-system-task.md
integrate-music-design-primitives-into-music-study-task.md
research-ios-android-release-path-for-music-study-task.md
prepare-expo-react-native-version-of-music-study-task.md

Recommended execution order

Run the research task about Expo/TestFlight/App Store/Play Store.
Fork/adapt the design system for Music Study.
Integrate the first Music Study primitives into the web app.
Create the Expo mobile proof of concept.
After the app is polished and stable, prepare real builds and beta testing.