Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@frontend/src/lib/api.ts`:
- Around line 1050-1055: The TempoEnableRequest type currently makes bpm and
beats_per_bar optional which allows invalid calls to compile; change it to a
discriminated union that matches the server contract: define TempoEnableRequest
as a union of { source: "link"; bpm: number; beats_per_bar: number } and {
source: "midi_clock"; midi_device: string } (or the exact server-required
shapes) so callers must provide the correct fields depending on source; update
any usages of TempoEnableRequest accordingly.

In `@frontend/src/pages/StreamPage.tsx`:
- Around line 1594-1637: The prompt-cycling effect is being double-quantized
because it sends prompt updates via sendParameterUpdate which the quantize logic
will push to the next boundary; change this effect to send the new prompt
immediately by either calling a new helper (e.g., sendParameterUpdateImmediate)
or extending sendParameterUpdate to accept a flag (e.g., { skipQuantize: true })
and set that flag when updating prompts from promptCycleIndexRef/current items;
update the quantize branch in the sendParameterUpdate implementation to honor
the flag so promptCycleBoundaryRef/Index logic produces the prompt on the
current boundary rather than being deferred.
- Around line 473-494: The quantize-detection logic in the isQuantizeActive
block (variables NEVER_QUANTIZE, hasDiscrete, params, _quantized) wrongly infers
discreteness by typeof and misses non-primitive discrete payloads like
transition and denoising_step_list; change hasDiscrete to use a key-based
allowlist instead: create a DISCRETE_PARAM_KEYS set (include prompts,
reset_cache, transition, denoising_step_list, and any other known composite
discrete keys), skip keys in NEVER_QUANTIZE, and mark params._quantized = true
when any key is in DISCRETE_PARAM_KEYS or matches existing boolean/string checks
for backward compatibility. Ensure you reference the same symbols
(isQuantizeActive, NEVER_QUANTIZE, hasDiscrete, params, _quantized) when making
the change.

In `@src/scope/core/pipelines/mod_scope/pipeline.py`:
- Around line 77-79: BEATS_PER_BAR is hardcoded to 4 causing incorrect beat
highlighting; make beats per bar dynamic by replacing the constant with a
configurable variable (e.g., beats_per_bar) sourced from pipeline settings or
the time signature, update any code that computes or wraps bar_position (the
logic currently at the block referenced by lines handling bar_position wrapping
around BEATS_PER_BAR) to use beats_per_bar instead of BEATS_PER_BAR, and ensure
the rendering logic that draws the beat dots uses beats_per_bar to determine
count and placement so 3/4, 5/4, etc. render correctly.
- Around line 105-109: The glow rendering loop is performing per-pixel
host/device syncs by calling Tensor.item() (search for the glow loop that reads
tensor values with .item() in this class), which kills GPU performance; update
the glow accumulation to keep everything on-tensor: remove all .item() usages in
the glow loop, replace Python scalar operations with torch tensor ops (e.g., use
torch.max, torch.clamp, tensor indexing/assignment and tensor-wise arithmetic)
and ensure results are written back as tensors on self.device (the pipeline's
device is set via self.device). Locate the glow loop in this module (the section
that reads tensor values per-sample/pixel and writes glow outputs) and refactor
it to compute glow intensities and color blending entirely with PyTorch tensor
operations without converting to Python scalars.

In `@src/scope/core/pipelines/mod_scope/schema.py`:
- Around line 25-27: The three demo parameters noise_scale, vace_context_scale,
and kv_cache_attention_bias are plain floats so the generated schema lacks the
ui.modulatable metadata; update each field declaration to include the UI
metadata (e.g., use Annotated/Field or the project's Field helper) so they carry
ui.modulatable=True in the schema generation step — change the noise_scale,
vace_context_scale, and kv_cache_attention_bias declarations to use the
project's schema field pattern that attaches ui.modulatable metadata rather than
raw float types.

In `@src/scope/server/frame_processor.py`:
- Around line 58-76: The ParameterScheduler creates live timers but
FrameProcessor.stop() does not cancel them, allowing scheduled callbacks (e.g.
update_parameters / change_applied) to run after shutdown; modify
FrameProcessor.stop() to explicitly cancel/stop any active schedulers and
engines (call the cancellation/cleanup API on ParameterScheduler instance
referenced by self.parameter_scheduler and also on self.modulation_engine if
applicable) before tearing down pipeline or clearing processors so no pending
timers can fire; ensure you use the scheduler/engine methods (e.g.
ParameterScheduler.cancel() or .stop(), and ModulationEngine.stop()/shutdown())
that exist on those classes to cleanly terminate pending work and prevent late
callbacks.

In `@src/scope/server/modulation.py`:
- Around line 130-146: The descending-repair loop can push values outside the
configured bounds (lo/hi); after the existing backward pass that mutates result
(the for loop that checks result[i] <= result[i+1] and increments earlier
entries), re-clamp all entries of result into [lo, hi] (i.e., for each value set
result[i] = max(lo, min(hi, result[i]))), or alternatively perform the clamp
inside the loop after adjusting each element; reference the variables/result
list and the existing backward-loop in modulation.py to locate the change.

In `@src/scope/server/parameter_scheduler.py`:
- Around line 52-68: When changing quantize settings, cancel or recompute any
pending scheduled timer so stale pending updates don't fire: inside the
quantize_mode setter (quantize_mode) and the lookahead_ms setter (lookahead_ms)
ensure you clear any existing pending timer (e.g., cancel_timer(),
self._pending_timer, or similar scheduler handle used elsewhere) before updating
self._quantize_mode or self._lookahead_ms, and if needed reschedule according to
the new mode/lookahead; also log that the pending timer was canceled or
rescheduled to aid debugging.

In `@src/scope/server/tempo_sources/link.py`:
- Around line 14-16: The unconditional import of Link will raise if aalink is
missing and prevents graceful degradation; change the top-level import to a
guarded try/except (e.g., try: from aalink import Link except Exception: Link =
None) so importing this module never raises, and ensure any code that expects
Link (e.g., the LinkTempoSource class or instantiation in tempo_sync.py) checks
for Link is not None before use.

In `@src/scope/server/tempo_sources/midi_clock.py`:
- Around line 137-151: The transport handlers (_on_start, _on_stop,
_on_continue) currently only flip self._is_playing and leave the cached beat
snapshot stale so get_beat_state() returns old data; update these handlers to
refresh/invalidate the cached beat snapshot when the transport state changes
(e.g., set self._cached_beat_snapshot = None or call an existing
self._update_beat_snapshot()/self._invalidate_beat_snapshot() helper) so that
subsequent calls to get_beat_state() reflect the new playing/stopped/continued
state immediately.

In `@src/scope/server/tempo_sync.py`:
- Around line 161-169: The enable() method currently returns silently if source
creation fails; instead detect when _create_link_source(...) or
_create_midi_clock_source(midi_device, beats_per_bar) returns None and raise a
RuntimeError with a clear message (including the requested source_type and any
install/device hint) so callers can surface a 4xx; update the code in enable()
to replace the `if source is None: return` branch with raising RuntimeError and
ensure the exception includes sufficient context for the REST layer to show the
install hint.
- Around line 94-112: get_beat_state currently ignores the _enabled flag and
disable() doesn't clear the cached _client_beat_state, so fresh client-forwarded
beats remain available after tempo sync is disabled; fix by early-returning None
from get_beat_state when self._enabled is False (before reading
_client_beat_state) and, in disable(), acquire self._client_state_lock and set
self._client_beat_state = None (and keep existing logic clearing/locking
_source/_source_lock); apply the same gating and cache-clear change to the
analogous method around lines 191-203 as well.

---

Outside diff comments:
In `@frontend/src/pages/StreamPage.tsx`:
- Around line 519-545: The current fallback in the params sync block is
persisting every non-allowlisted param into settingsUpdate.schemaFieldOverrides,
which causes transient protocol-only fields (e.g., transition,
prompt_interpolation_method, output_sinks sent via sendParameterUpdate) to leak
into future loads; update the logic around overrideUpdates creation to exclude a
small denylist of known transient keys (e.g., "transition",
"prompt_interpolation_method", "output_sinks") or detect runtime-only flags
before copying into settingsUpdate.schemaFieldOverrides, so only true schema
overrides are merged; keep the rest of the merge behavior intact (referencing
settingsRef.current and settingsUpdate.schemaFieldOverrides) and ensure
transient keys are ignored when building overrideUpdates.

In `@src/scope/server/frame_processor.py`:
- Around line 628-660: The FrameProcessor currently only removes tempo-control
keys when helpers exist, causing stale control keys to be forwarded when helpers
are absent; always strip these keys from the incoming parameters before any
pipeline forwarding. Specifically: ensure "quantize_mode" and "lookahead_ms" are
popped from parameters even if self.parameter_scheduler is None; pop
"modulations" from parameters even if self.modulation_engine is None (and call
self.modulation_engine.update(...) only when present); pop
"beat_cache_reset_rate" regardless (and only apply it to
self.pipeline_processors when present); and when self.tempo_sync is None remove
any client beat-state fields (the same keys handled by
tempo_sync.update_client_beat_state) so they are not forwarded to
processor.update_parameters or retained on self.parameters. Use the existing
symbols (parameter_scheduler, modulation_engine, tempo_sync,
pipeline_processors, _update_output_sinks_from_config, _update_input_source) to
locate the logic and implement the unconditional popping before any call that
forwards parameters.

---

Nitpick comments:
In `@docs/tempo-sync-review.md`:
- Around line 258-264: The flow diagram block containing ModulationSection →
modulations state → sendParameterUpdate(...) →
FrameProcessor.update_parameters() → ModulationEngine.update(raw_configs) →
ModulationEngine.apply(beat_state, call_params) → PipelineProcessor should be
fenced as a text code block to satisfy markdown linters; update the diagram to
use a triple-backtick fence with the language tag "text" (i.e., start with
```text and end with ```) so the existing symbols (ModulationSection,
sendParameterUpdate, FrameProcessor.update_parameters, ModulationEngine.update,
ModulationEngine.apply, PipelineProcessor) remain unchanged but the block is
properly annotated.
- Around line 42-78: Add a language tag to the fenced ASCII diagram block (the
triple backticks that begin the diagram starting with
"┌─────────────────────────────────────────────────────────────┐" and containing
headers like "TEMPO SOURCES" and "TEMPOSYNC MANAGER"); change the opening fence
from ``` to ```text so markdown linters recognize it as plain text and stop
flagging the diagram.
- Around line 239-243: Update the flow diagram code blocks that show "Ableton
Link / MIDI device → TempoSource → TempoSync.get_beat_state() →
PipelineProcessor (inject + modulate) → Pipeline → _notification_loop() → WebRTC
data channel → useTempoSync" (and the similar block at the later section) to
include a language specifier by changing the fenced code blocks from ``` to
```text so markdown linters render them consistently; locate the fenced blocks
containing those exact flow lines and prepend "text" after the opening backticks
for both occurrences.

In `@frontend/src/components/DownloadDialog.tsx`:
- Around line 31-32: The props isCloudMode and onOpenLoRAsSettings declared for
the DownloadDialog component are never used; either remove them from the
DownloadDialogProps interface and from the component's destructuring, or
explicitly destructure-and-discard them to document intentional ignoring (e.g.,
isCloudMode: _isCloudMode, onOpenLoRAsSettings: _onOpenLoRAsSettings) inside the
DownloadDialog function to satisfy type compatibility while avoiding unused
variable warnings.

In `@frontend/src/components/settings/ModulationSection.tsx`:
- Around line 114-119: The current useEffect in ModulationSection (useEffect,
targets, selectedTarget, setSelectedTarget) causes a brief render with a stale
selectedTarget when targets change; to avoid flicker, derive an
effectiveSelectedTarget synchronously during render (e.g., compute a fallback
like targets[0].value when selectedTarget is missing) and use that derived value
in the JSX, or setSelectedTarget synchronously at the same place you update
targets/pipeline (the handler that changes pipeline/targets) so the state is
correct before the next render; update references in the component to use the
derived/synchronously-updated selected value instead of relying solely on the
effect.
- Around line 137-149: handleToggle currently deletes the target config when
disabling, losing user settings; change it to preserve the config object and
only toggle an enabled flag. Specifically, in handleToggle use the existing
config from modulations[selectedTarget] (falling back to
defaultConfigFor(currentTarget)) when pressed is true and set enabled: true, and
when pressed is false set modulations[selectedTarget] = {
...(existingOrDefault), enabled: false } instead of deleting the entry; continue
to call onModulationsChange with the updated modulations object. Ensure you
reference handleToggle, defaultConfigFor, onModulationsChange, modulations,
selectedTarget, and currentTarget when making the change.

In `@frontend/src/components/settings/TempoSyncSection.tsx`:
- Around line 270-298: The BPM input currently only validates on submit and
allows invalid intermediate values; update the input's onBlur handler (currently
setting bpmInputFocusedRef) to parse and clamp bpmInput into the 20–300 range,
call setBpmInput with the clamped string, and invoke onSetBpm(clampedValue) so
the final value is normalized; keep onChange as-is to allow free typing, and
optionally add a short debounce around any future calls to onSetBpm if you want
live updates instead of only on blur/submit (referencing bpmInput, setBpmInput,
bpmInputFocusedRef, and onSetBpm).

In `@frontend/src/components/TempoSyncPanel.tsx`:
- Around line 11-32: TempoSyncPanelProps is declared but not exported,
preventing external modules from importing the prop type; fix by adding an
export to the interface declaration (export interface TempoSyncPanelProps) in
the TempoSyncPanel component file and update any places that should import this
type (e.g., other components or tests) to import { TempoSyncPanelProps } from
the component module; ensure any existing default/export patterns in the file
remain correct after adding the export.

In `@frontend/src/hooks/useUnifiedWebRTC.ts`:
- Around line 167-203: The per-message console.log in dataChannel.onmessage is
currently printing every "tempo_update" packet (handled where data.type ===
"tempo_update"), flooding DevTools; modify the handler around the
console.log("[UnifiedWebRTC] Data channel message:", event.data) so it skips or
samples logs for high-frequency messages — e.g., only log when data.type !==
"tempo_update" or apply a simple sampling/throttle for "tempo_update" (log every
Nth packet or once per second) — leaving other branches (stream_stopped,
change_scheduled, change_applied) unchanged; update the logic in the function
handling dataChannel.onmessage to check data.type before logging.

In `@src/scope/core/pipelines/metronome/pipeline.py`:
- Around line 175-181: Remove the unnecessary first draw used to measure width:
replace the call that invokes _draw_number(canvas, beat_display, 0, 0, scale,
text_color) with a non-drawing width calculation (e.g., call the same underlying
measurement routine or add a helper to measure text width) so you only compute
num_w without rendering, then use _draw_number only once at (center_x,
center_y); do the same for bar_num_w (avoid drawing at 0,0 to measure width and
only draw once at its centered position). Reference: _draw_number, beat_display,
num_w, bar_num_w in pipeline.py.
- Around line 100-103: The current pipeline code that simulates latency uses a
blocking call via time.sleep when reading latency_ms from kwargs, which can
block the pipeline thread and cause input-frame drops; update the latency
simulation in the pipeline (the latency_ms handling inside the pipeline
function) to either (a) replace blocking time.sleep with a non-blocking approach
such as scheduling an asyncio.sleep or deferring the delay to a
worker/threadpool so the pipeline thread isn’t blocked, or (b) if blocking is
intentional for testing, add a clear inline comment and docstring on the
pipeline function explaining that latency_ms intentionally blocks the pipeline
thread and warning about potential frame drops so callers know to avoid using
high latency_ms in production. Ensure references to latency_ms and the pipeline
function/method name are preserved when changing the implementation.

In `@src/scope/server/schema.py`:
- Around line 857-869: TempoStatusResponse currently types source and beat_state
as dict | None which weakens type safety; define two nested Pydantic models
(e.g., SourceInfo and BeatState) that capture the stable structure (fields like
type, num_peers for source; bpm, beat_phase, bar_position, beat_count,
is_playing, source for beat_state) and replace the dict annotations on
TempoStatusResponse.source and TempoStatusResponse.beat_state with
Optional[SourceInfo] and Optional[BeatState] respectively, updating any code
that constructs or reads these fields to use the new models.

In `@src/scope/server/tempo_sources/link.py`:
- Around line 109-112: set_tempo currently returns silently when self._link is
None which hides misconfiguration; update set_tempo to detect when self._link is
None and either log a warning or raise an error. Inside the set_tempo method
(referencing set_tempo and attribute _link) add a branch that emits a clear
warning (using the existing logger on the class if available, otherwise the
module logging) stating that tempo change was requested but Link is not
initialized, or raise a RuntimeError with that message—choose logging for
non-fatal flows and raise for fatal flows.

In `@tests/test_parameter_scheduler.py`:
- Around line 359-376: The test test_scheduled_change_fires_after_delay is flaky
because it relies on real timers/sleep; modify the test to avoid real-time
dependence by either increasing the tolerance (e.g., sleep to 0.5s) or,
preferably, mock the timer used by the scheduler (mock threading.Timer or the
scheduler's internal timer creation) so schedule() triggers immediately in
tests; locate references to make_scheduler, FakeBeatState, and the
scheduler.schedule(...) call and patch the Timer creation used by that scheduler
instance to a synchronous stub that calls the callback immediately and assert
applied/notifications as before.