Skip to content

release: v0.1.4 — CLI config bridge + multi-profile support - #8

Merged
JRemitz merged 4 commits into
mainfrom
release/v0.1.4
Jun 9, 2026
Merged

release: v0.1.4 — CLI config bridge + multi-profile support#8
JRemitz merged 4 commits into
mainfrom
release/v0.1.4

Conversation

@JRemitz

@JRemitz JRemitz commented Jun 8, 2026

Copy link
Copy Markdown
Contributor

Summary

Fixes a class of silent failures where the dock invoked the CLI but auxiliary lookups (teams, rosters, plugin settings) resolved against the wrong config. Symptoms users saw:

  • "Team profile not found" errors when the dock was launched from Finder / the macOS Dock
  • Publish targets reporting their flags as disabled even though the chosen config had them enabled (cloudflare upload_video=False, tiktok upload_shorts=False, etc.)
  • Multi-profile queue items rendering only the last profile (player-overlay dropped, only slowmo survived)

Three plumbing fixes get the dock and CLI on the same page:

1. CLI subprocess env

Every CLI subprocess (render_via_cli, hook_executor::execute_hook, queue::run_queue_cli_with_profile, hooks::run_auth_command) now exports REELN_CONFIG=<path> alongside --config <path>. The CLI's _config_base_dir() falls back to REELN_CONFIG when --config isn't set, so without this fix Finder-launched dock instances resolved teams against ~/Library/Application Support/reeln/ instead of ~/.config/reeln/config/.

2. Profile name flows end-to-end

CliRenderParams.config_profile carries the plugin profile NAME ("production"). The dock passes --profile <name> alongside --config <path>. Without this, add_to_queue stored config_profile="" on the queue item, and reeln queue publish later fell through to defaults — every plugin saw its enable flag as off.

Tauri commands render_short / render_iteration accept the new parameter; the frontend's renderQueue store passes item.pluginProfile through to the IPC layer.

3. Publish-time recovery

queue_publish / queue_publish_all now derive a concrete config.<profile>.json path from the queue item's stored profile via state.effective_config_dir() when the frontend didn't supply one. Fixes the (common) case where the frontend's in-memory queue cache is stale and _autoResolveItemConfigPath returns undefined, but the queue file on disk has the right profile recorded.

Test plan

  • cargo test312 tests pass (12 new)
    • test_cli_config_profile_passes_profile_flag — explicit profile → --profile production
    • test_cli_empty_or_missing_config_profile_omits_flag — None / "" both suppress the flag
    • test_derive_config_resolves_existing_profile_file — recovers when frontend omits config
    • test_derive_config_returns_none_when_file_missing — falls back to --profile for CLI error reporting
    • test_cli_config_path_also_exports_reeln_config_env — REELN_CONFIG env exported
    • Same for queue / hook_executor / hooks
  • npx vitest run112 tests pass (2 new IPC round-trip tests)
  • Manual: render a goal in dock with a plugin profile selected, restart dock, click Retry — confirm all enabled targets actually fire instead of skipping

Companion PRs

🤖 Generated with Claude Code

JRemitz and others added 3 commits June 7, 2026 22:17
Fixes a class of silent failures where the dock invoked the CLI but
auxiliary lookups (teams, rosters, plugin settings) resolved against
the wrong config. Symptom on macOS: "Team profile not found" errors
when launched from Finder; publish targets all reporting their
flags as disabled even though the chosen config had them enabled.

CLI subprocess env
- render_via_cli, hook_executor::execute_hook,
  queue::run_queue_cli_with_profile, and hooks::run_auth_command now
  export REELN_CONFIG=<path> alongside --config <path>. Auxiliary CLI
  lookups (team profiles, rosters, secrets) resolve against the
  chosen config regardless of how the dock was launched.

Profile name end-to-end
- CliRenderParams.config_profile carries the plugin profile NAME
  (e.g. "production") so the CLI's --profile flag is set. Without
  it, add_to_queue stored config_profile="" on the queue item and
  publish later fell through to defaults.
- Tauri commands render_short / render_iteration accept the new
  parameter; the frontend's renderQueue store passes
  item.pluginProfile through to the IPC layer.

Publish-time recovery
- queue_publish / queue_publish_all derive a concrete
  config.<profile>.json path from the queue item's stored profile
  via state.effective_config_dir() when the frontend didn't supply
  one. Fixes Finder-launched instances where REELN_CONFIG isn't
  inherited from the shell.

Tests
- 312 cargo tests pass (12 new). Helper derive_config_path_from_profile
  is exported via super for unit testing without spinning up Tauri
  State. IPC tests assert configProfile round-trips end-to-end.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Refactor log store from module-scope ``$state`` + reassign-on-push to a
``LogStore`` class instance with in-place ``entries.push()`` mutation.
The previous pattern broke cross-module Svelte 5 reactivity: when
``push()`` reassigned ``entries = [...]``, the LogViewer's $derived
that read entries via ``getLogEntries()`` from another module never
saw the updates, and on mount the component appeared to render
nothing.

Class instance pattern is the Svelte 5 docs' recommended approach for
shareable reactive state. Property reads on the instance (e.g.
``logStore.visible``) wire up reactivity reliably across module
boundaries.

Old function exports (getLogEntries, setLogLevel, clearLogs, log.info,
etc.) are preserved as thin wrappers so the ~10 existing call sites
don't need to change. LogViewer rewritten to read ``logStore.visible``
and ``logStore.minLevel`` directly — the simplest, most reactive form.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@JRemitz JRemitz self-assigned this Jun 9, 2026
@JRemitz
JRemitz merged commit 3c59d06 into main Jun 9, 2026
10 checks passed
@JRemitz
JRemitz deleted the release/v0.1.4 branch June 9, 2026 15:58
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.

1 participant