Skip to content

feat(core): working-tuning lifecycle — launch default, verified decay, idempotent re-injection + tests (working-tuning PR 9a)#669

Merged
byrongamatos merged 1 commit into
mainfrom
feat/v3-working-tuning-lifecycle
Jul 1, 2026
Merged

feat(core): working-tuning lifecycle — launch default, verified decay, idempotent re-injection + tests (working-tuning PR 9a)#669
byrongamatos merged 1 commit into
mainfrom
feat/v3-working-tuning-lifecycle

Conversation

@ChrisBeWithYou

Copy link
Copy Markdown
Contributor

Working-tuning PR 9a (Phase E — polish & safety, capability half). Stacked on #658 → base feat/host-working-tuning.

What

Hardens the host workingTuning capability with the lifecycle pieces from the design's PR 9, plus the state-machine test suite the capability was missing.

How

  • Idempotent re-injection — the module early-returns if workingTuning.version === 1 already exists. Previously the Object.freeze(...) assignment was unguarded, so re-running the source replaced the live state with a fresh (empty) one.
  • Opt-in launch defaultsetLaunchDefault / getLaunchDefault / clearLaunchDefault (per-instrument, localStorage-backed). _seedFromSettings seeds from the launch default when one is set for the booting instrument, else /api/settings. Off by default — a SEED only; the live working tuning still resets on restart.
  • Verified decay — on song:loading, the current instrument's verified provenance decays to assumed (offsets kept). A choreographed per-string mic check is only trustworthy for the context it was done in, so a stale verified must never suppress a needed prompt (fail toward re-checking).

Test

tests/js/working_tuning_capability.test.js12/12 (node --test): defaults / per-instrument isolation / both-directions / verified-invalidation-on-retune / decay-on-song-load / resetToDefault / launch-default set+seed+clear / idempotent re-injection / the change event.

Follow-up (PR 9b)

The opt-in UI (calling setLaunchDefault) and the mic-verify writer (the choreographed per-string check that promotes assumedverified) land with the tuner, on #660.

🤖 Generated with Claude Code
https://claude.ai/code/session_01QbexxfTt8q2tAn436MqGWF

…, idempotent re-injection + tests (working-tuning PR 9a)

Hardens the host workingTuning capability (PR 1) with the "polish & safety"
lifecycle:

- Idempotent re-injection: a second load of the module no longer replaces the live
  state with a fresh (empty) one — it early-returns once registered.
- Opt-in "launch tuning" default (setLaunchDefault/getLaunchDefault/clearLaunchDefault):
  a per-instrument, localStorage-backed seed the player can opt into ("start me in
  THIS tuning on app open"). Boot seeds from it when set, else /api/settings as before.
  Off by default — a SEED only; the live tuning still resets on restart.
- Verified decay: on song:loading the current instrument's 'verified' provenance
  decays to 'assumed' (offsets kept) — a per-string mic check is only trustworthy for
  the context it was done in, so a stale 'verified' can never suppress a needed prompt.

Adds a state-machine smoke suite (tests/js/working_tuning_capability.test.js, 12/12):
defaults, per-instrument isolation, both-directions, verified-invalidation-on-retune,
decay-on-song-load, resetToDefault, launch-default set/seed/clear, idempotent
re-injection, the change event.

The opt-in UI + the mic-verify writer land with the tuner (PR 9b).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QbexxfTt8q2tAn436MqGWF
@byrongamatos
byrongamatos force-pushed the feat/v3-working-tuning-lifecycle branch from 40bea32 to 38f7e83 Compare July 1, 2026 09:07
@byrongamatos
byrongamatos changed the base branch from feat/host-working-tuning to main July 1, 2026 09:07
@byrongamatos
byrongamatos merged commit 48f4354 into main Jul 1, 2026
@byrongamatos
byrongamatos deleted the feat/v3-working-tuning-lifecycle branch July 1, 2026 09:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants