Mediastack installer should have parameters

[Deny-DD]

Problem / Use case

Media stack is heavy on resources.
You need to add options on what's get installed. Most people want jellyfish only.

Proposed solution

Add command line argument to the sh script AND dashboard tickboxes on each available software, not just an "install" button.

Dashboard tickboxes so SSH is not required.

On every future addition, you need to maintain the options.

[MagnaCapax]

Investigation Report

Issue: #790 — Mediastack installer should have parameters
Investigated: 2026-08-18
Status: PARTIAL — most of the scaffolding exists; per-app selection is the missing piece.

Summary

install-media-stack.sh is monolithic today, but it already carries most of what a selective install needs: an extensible argument parser, a proven per-app enable/disable flag (Jellyfin), a central session registry, an observe-only watchdog that derives its "expected apps" from what is actually installed, and a web panel that already renders per-app status. What is missing is a per-app selection control on the two input surfaces (the CLI and the panel). This splits cleanly into a low-risk CLI phase and a separate, security-sensitive dashboard phase.

What the issue asks for

1. A command-line argument to etc/skel/install-media-stack.sh to choose which apps install ("media stack is heavy on resources… most people want jellyfin only").
2. Dashboard tickboxes per app on the welcome-page installer panel, so SSH is not required — replacing the single "install" button.
3. The reporter also notes the maintenance implication: "on every future addition, you need to maintain the options."

Implementation status (verified against current source)

• Arg parser is already extensible — the script parses ~15 flags today (per-app --<app>-url/-branch/-version overrides, plus --dry-run/--force/--uninstall/--verify-only). There is no per-app selection flag (--apps, --only, --no-<app>).
• Enable/disable pattern already proven — JELLYFIN_INSTALL_ENABLED (defined ~line 103, set to 0 at ~line 455 when FFmpeg < 4.4) gates Jellyfin's install/start/config/summary across ~16 sites. It is FFmpeg-driven rather than user-selected, but it is exactly the mechanism a per-app selection would generalize.
• Central session registry exists — MEDIA_STACK_BASE_SESSIONS (~line 1059).
• Start machinery tolerates absence — media_stack_start_tmux_app (~line 1325) no-ops with a log line when an app's binary is missing, so a subset install does not break startup.
• Watchdog already handles partial installs — pmssMediaStackWatchdogExpectedApps() in scripts/lib/mediaStackWatchdog.php enumerates only apps whose config/binary is present, and its restart policy is observe-only. A subset install yields a clean status snapshot, not spurious "failed" rows.
• Panel already renders per-app status — etc/skel/www/userMediaStackPanel.php reads the watchdog snapshot and lists each app's state, but pmssMediaStackPanelStartCommandBuild() launches the installer with no selection arguments. This is the "just an install button" the issue describes.

Net: the runtime and observability layers already behave correctly for a partial install. The work concentrates at the two input surfaces.

What's missing

• A selection variable plus a per-install-block gate in install-media-stack.sh (with the shared .NET runtime auto-included whenever any .NET app — Jellyfin/Sonarr/Radarr/Prowlarr — is selected).
• Panel tickboxes plus a validated selection passed through pmssMediaStackPanelStartCommandBuild().
• A note for the new flag in docs/install-media-stack.md and coverage in scripts/lib/tests/development/installMediaStackScriptTest.php.

Why it fits the product

• Install only what you use — directly helps small tiers where the full stack already trips the 1024 MiB pre-flight warning.
• Fewer auto-started daemons on constrained accounts reduces the out-of-memory class of failures seen when a full self-installed stack exceeds a correctly-provisioned cap.
• The dashboard phase gives non-SSH users real choice.

Trade-offs considered

Runtime resource control already partially exists: the watchdog is observe-only and users start apps manually via the tmux aliases, so a user can simply not run apps they do not want. That makes the CLI phase's marginal value "cleaner install + disk savings + no initial start spike + no stopped-session noise" rather than "impossible otherwise." The gaps are still real, though — the installer starts every app once at install time, unused .NET/binaries cost disk, and the user who only wants Jellyfin (and never SSHes) has no path today. This is the argument for keeping the first phase minimal and deferring the heavier dashboard work rather than building both at once.

Quality checks

• Selection is an explicit token whitelist, not fuzzy matching.
• Customer-requested with recurring demand — not a speculative optimization; the over-build risk lives in the dashboard part, which is why it is split out.
• Status is claimed PARTIAL (not done), with each "exists" backed by a cited file/line.
• The default remains "all apps" for backward compatibility; the panel path must reject unknown tokens (fail-closed).

Related work

• A prior closed enhancement added the low-memory pre-flight guard and the --uninstall path — the earlier response to the same "heavy stack" concern. This issue is the logical next step: install selectively, rather than warn-then-uninstall-everything.
• The installer is actively developed (recent closed work added Autobrr, panel watchdog status, and a .NET-host protection fix), so a selection flag lands on a maintained surface.
• Demand for a modular/per-app installer has surfaced repeatedly in support and pre-sales contexts, driven by the full stack's RAM footprint on entry tiers.

Cross-issue analysis

Scanned all open issues.

• media-stack nginx: per-user proxy_redirect rewrites external Location headers, breaking *arr/Prowlarr download grabs (404) #682 (media-stack nginx proxy_redirect rewriting external Location headers) — same feature area but a different file and concern (nginx Location handling for *arr grabs); no overlap with the installer or panel.
• Seedbox dashboard title #786 (Seedbox dashboard title) — touches the welcome-page surface that the panel phase would also touch; minor UI coordination only, not a merge.
• No duplicates, no supersession, no conflicting approach found.

Dependencies & blockers

• Phase 1 (CLI): none — self-contained parser + per-block gating + start-list filter.
• Phase 2 (dashboard): depends on the Phase 1 flag contract; needs a security review for the browser→shell selection path (see ADR-0004); the panel is intentionally first-run-only, so its UX contract needs its own design.
• Optional companion: consolidate the duplicated app roster into one source of truth — not a blocker, but it cheapens every future app addition.

Reuse, refactor & test strategy

• Reuse — the JELLYFIN_INSTALL_ENABLED gating pattern; the MEDIA_STACK_BASE_SESSIONS registry; the graceful missing-binary skip in media_stack_start_tmux_app; the watchdog's expected-apps-from-disk logic; the panel's per-app status render.
• Refactor opportunities — (1) the app roster is currently defined independently in the bash session arrays/start sequence, in pmssMediaStackWatchdogAppDefinitions(), and in the panel labels/URL builder; consolidating it into one source of truth consumed by both bash and PHP is exactly the maintenance tax the reporter flagged. (2) Derive ".NET needed" from the selected set rather than always installing it. (3) Feed one selected-apps list into install, start, and summary.
• Tests — unit (parser maps --apps= to the per-app gate set); integration on a dev host (--apps=jellyfin installs only Jellyfin; the watchdog snapshot lists only Jellyfin); regression (no flag = full stack; the low-memory guard still fires); boundary (unknown token rejected; empty selection; .NET auto-included when only a .NET app is chosen); failure injection (a .NET app selected but the runtime missing → a clear error, not a silent half-install). Reuse the string-assertion pattern already in installMediaStackScriptTest.php.
• Minimum for correctness — a selected-apps set + per-block guard + ".NET-needed" derivation + default-to-all. No config system, no plugin architecture, no per-app version-matrix UI.

Recommendation: IMPLEMENT, in two phases

• Phase 1 (this issue, MVP): add per-app CLI selection (e.g. --apps=jellyfin,sonarr and/or --only=jellyfin) that gates each install block, auto-includes .NET when any .NET app is selected, and defaults to the full stack for backward compatibility. Low risk, high value, and it establishes the flag contract the dashboard phase needs.
• Phase 2 (worth a separate, security-reviewed issue): the dashboard tickboxes, passing a whitelisted, shell-escaped selection to the installer per ADR-0004 (the panel already builds its launch command this way). Because the panel is intentionally first-run-only, its UX contract deserves its own design discussion.

Maintainers may prefer to formally split this into two issues; either way, Phase 1 is ready to build now and is not blocked. It is also worth recording an ADR for a single source of truth for the media-stack app roster, since per-app selection multiplies the places each new app must be registered — the reporter's own maintenance concern.

Architectural minimization

• Question the requirement — the dashboard-tickboxes part is the one to challenge: the panel deliberately passes no user-controlled arguments to the shell today, so tickboxes reintroduce a browser→shell selection surface. The need it serves (non-SSH users wanting a subset) is real but separable from the CLI work; coupling them ties a trivial parser change to a security-reviewed UI change.
• Delete / merge / refactor — splitting the monolith into per-app scripts is rejected (loses shared .NET/venv resolution, self-update, and proxy config, and worsens the roster duplication). The preferred mechanism is to generalize the existing Jellyfin enable flag into a per-app map (reuse, not new infrastructure) and to merge the duplicated app registries into one source of truth.
• Do nothing? — then small-tier users keep receiving the full stack (RAM warning, OOM risk) or must uninstall the whole thing rather than install selectively, and non-SSH users get no choice.
• Minimal design (Phase 1): parse a selected-apps set from --apps=/--only=; guard each Installing <APP> block with an is-selected test; auto-include the .NET block when any .NET app is selected; default to all apps. Files: install-media-stack.sh (parser + block guards + start-list filter), docs/install-media-stack.md (document the flag), installMediaStackScriptTest.php (assert the flag + gating).

ADR adherence

• Adheres — ADR-0007 (install bootstrap interactivity and contract): selection is via flags for the non-interactive piped-install path; any interactive prompt would be optional and TTY-gated.
• Adheres — ADR-0004 (shell command guardrails): the dashboard phase must pass a whitelisted, escaped token set; no untrusted string is chained into a shell command.
• Extends — ADR-0016 / ADR-0017 (customer PHP tree separation + review checklist): panel changes live in the customer PHP tree and would follow the existing review checklist.
  No conflict; no supersession required.

Self-challenge

• "Per-app selection is not implemented" — searched the installer for any selection flag (--only/--apps/--select/--no-<app>) and for all *_INSTALL_ENABLED variables; only the single FFmpeg-driven Jellyfin flag exists. Holds.
• "The runtime layers already tolerate a partial install" — searched for any per-app hard-fail on a missing app; found only Jellyfin's graceful FFmpeg-skip, and the watchdog derives expected apps from on-disk presence. Holds.
• "The app roster is duplicated across bash and PHP" — the roster is independently defined in the bash installer and two PHP files, which validates the reporter's maintenance concern. Holds.

— Väinämöinen

[MagnaCapax]

Adversarial Review

Issue: #790 — Mediastack installer should have parameters
Reviewed: 2026-08-18
Verdict: PROCEED — Phase 1 (CLI selection) only. Split the dashboard-tickbox part into its own security-reviewed issue; do not block Phase 1 on it.

This review builds on the earlier investigation report above, verifies its claims against current source, and adds three things it did not surface: a simplicity finding that shrinks Phase 1 to the bash installer alone, a correction to the shared-dependency handling, and a coordination point with #672/#673.

Adversarial Findings

Big Questions (answered, not garnish):

1. Worst case if shipped as described. The selection logic derives the shared runtimes from the wrong set → a selected app installs but its runtime is skipped → the app never starts, yet the installer reports success and the panel later shows the app marker as present. Chain: --only=sabnzbd selected → Python venv block gated out because the derivation only checked for .NET apps → SABnzbd.py present but no venv → tmux session dies on launch → user sees "installed" with no error → support contact 24–48h later. The distance between correct and broken here is exactly which dependency classes the derivation covers (see finding below).

2. Inversion (guarantee maximum damage). Make the default anything other than the full stack. Every no-argument caller — the self-update re-exec (etc/skel/install-media-stack.sh:67, exec "$tmp" --skip-update "$@"), the panel launcher (etc/skel/www/userMediaStackPanel.php:342, no selection args), and per-home distribution — would silently install a different set fleet-wide. The proposed implementation resembles this failure only if the default is not pinned to "all". Pin it.

3. Regret in 6 months. If the bash selection set becomes a sixth independent app roster, it drifts from the PHP helpers that already list the apps separately. userMediaStackPanel: media-stack panel URL list advertises the Autobrr URL unconditionally — 404 when autobrr not installed (sibling of #778) #792 (Autobrr URL advertised unconditionally → 404) is that drift already producing a live customer bug. Adding selection without aligning to a single roster multiplies the reporter's own stated worry: "on every future addition you need to maintain the options."

4. Removal inversion. If per-app selection already existed and someone proposed removing it (forcing the full stack on everyone), small-tier accounts that already trip the ~1 GiB pre-flight guard would fight to keep it. That confirms real value.

5. Dumbest requirement. Bundling "CLI argument" and "dashboard tickboxes" as one change. The CLI parser change is trivial and self-contained; the tickboxes reintroduce a browser→shell selection surface governed by ADR-0004 and overlap Unified per-user application enablement (rtorrent, qBittorrent, deluge, rclone, docker): converge three scattered enable conventions into one registry; add rtorrent toggle (default-on) #672/Unified Applications On/Off panel in the user GUI (registry-driven, consolidates scattered per-app toggle buttons; adds rtorrent) #673. Coupling a 30-minute parser change to a security-reviewed UI change is the requirement to challenge.

6. Deletion opportunity. Do not build a selection DSL or a plugin system. The installer already has exactly one per-app enable flag — JELLYFIN_INSTALL_ENABLED (etc/skel/install-media-stack.sh:106, forced to 0 at :501 on FFmpeg failure) that gates install, start, config and summary across ~16 sites. Generalize that one proven pattern into a per-app map. Reuse, not new infrastructure.

[SIMPLICITY — strengthens the case] Phase 1 needs ZERO PHP changes. Both runtime layers already derive their app set from on-disk presence, so a subset install self-adapts:

• Watchdog: pmssMediaStackWatchdogExpectedApps() (scripts/lib/mediaStackWatchdog.php:37-47) enumerates only apps whose config dir or binary exists, and restartPolicy is observe-only (:103) — a subset install yields a clean status snapshot, never spurious "failed" rows.
• Panel: pmssMediaStackPanelExpectedAppLabelsRead() (etc/skel/www/userMediaStackPanel.php:283-306) mirrors the same presence signals. Absent apps simply do not render.

So Phase 1 is contained entirely in etc/skel/install-media-stack.sh plus its doc and static test. The earlier report slightly over-weighted the PHP-roster tax as a Phase 1 concern; it is not — Phase 1 touches no PHP.

[CORRECTNESS — the report understated this] Shared-dependency derivation must cover THREE classes, not one. The report named only .NET. Verified against source, selection must derive:

• .NET runtime (ASPDOTNET_URL, :1243) — needed by jellyfin, sonarr, radarr, prowlarr.
• Python venv (python_venv_install_requirements(), :451) — needed by sabnzbd and cloudplow.
• Jellyfin FFmpeg gate (jellyfin_ffmpeg_configure_fallback, :469) — jellyfin only; already sets JELLYFIN_INSTALL_ENABLED.
  autobrr is a standalone binary with no shared runtime. A derivation that only auto-includes .NET will break any Python-only selection.

[REGEX_FOR_SEMANTICS guard] Exact-token whitelist, never fuzzy matching. The reporter wrote "jellyfish" (not "jellyfin") twice in the body. That is the proof case: an unknown token must produce a clear error listing the valid app names and exit non-zero — it must NOT be "closest-match" corrected into installing jellyfin. Selection is a fixed set membership test, not similarity scoring.

Caller Analysis

This issue ADDS a flag; it removes nothing. The removal gate is satisfied because a default = full stack preserves every caller's current contract (AGENTS.md "Contract Preservation over Refactor"). Callers of install-media-stack.sh:

• Callers found: 6 invocation sites + tests.
• etc/skel/install-media-stack.sh:67 — self-update re-exec forwards "$@"; unaffected, default preserved.
• etc/skel/www/userMediaStackPanel.php:342 (pmssMediaStackPanelStartCommandBuild) — launches with no selection args → full stack (default). Phase 2 is the only thing that would change this.
• etc/skel/www/userMediaStackPanel.php:358 (pmssMediaStackPanelRecoveryCommandBuild) — passes --start-stopped; independent of selection.
• etc/skel/www/mediaStack.php — AJAX endpoint that drives the panel launcher; inherits panel behavior.
• scripts/lib/update/users/filesystem.php:200 — distributes the script into each home; invocation contract unchanged.
• Direct SSH invocation by account owners — the primary Phase 1 consumer.
• Tests: installMediaStackScriptTest.php, mediaStackPanelTest.php, mediaStackLighttpdMigrationTest.php, SkeletonInstallerPermissionsTest.php — all string/behavior assertions; add cases, none regress.

Investigation Results

• Affected file (Phase 1): etc/skel/install-media-stack.sh — arg parser (:143-172), per-app install blocks, the shared-runtime installs (.NET :1243, venv :451, FFmpeg :469), and the start sequence (:1391-1414, which unconditionally starts every installed app at install time).
• Doc: docs/install-media-stack.md must document the new flag.
• Test: scripts/lib/tests/development/installMediaStackScriptTest.php is a static lint-style test (reads the script as a string and asserts substrings). Add assertions that the selection variable and per-block guards are present, matching the existing pattern (e.g. its JELLYFIN_INSTALL_ENABLED=0 assertion at :181).
• Resource model (verified): install starts all installed apps once (RAM spike); a host reboot leaves them stopped (observe-only watchdog, no auto-restart); the panel "Start stopped apps" recovery (--start-stopped, media stack: self-installed apps have no boot persistence and the panel offers no restart action — apps stay stopped after a host reboot #793) restarts all installed apps. So install-selection's durable wins are disk footprint, the install-time start spike, and keeping unwanted apps out of the recovery set — not ongoing RAM (already user-controllable by not starting).
• Constraints: ADR-0004 (shell guardrails — Phase 2), ADR-0007 (install interactivity/contract), ADR-0034 (install-is-not-execution — governs root execution on the update path; the customer-uid install starting the customer's own apps is out of its scope, so it is not a blocker here).

Recommendations

• Implement Phase 1 in the bash installer only. Suggested surface: --apps=jellyfin,sonarr and/or --only=<app>; default (no flag) = full stack.
• Derive all three shared-runtime classes from the selected set (.NET / Python venv / Jellyfin-FFmpeg).
• Unknown token → error listing valid names, non-zero exit. No fuzzy correction.
• Split the dashboard-tickbox request into a separate issue and coordinate it with Unified Applications On/Off panel in the user GUI (registry-driven, consolidates scattered per-app toggle buttons; adds rtorrent) #673 (registry-driven Applications On/Off panel) and its registry dependency Unified per-user application enablement (rtorrent, qBittorrent, deluge, rclone, docker): converge three scattered enable conventions into one registry; add rtorrent toggle (default-on) #672 — Phase 2 should reuse that registry pattern rather than inventing a parallel media-stack selector (Single-Method-Consistency).
• Treat a single media-stack app roster (consumed by the bash installer and the PHP helpers) as a companion refactor aligned with Unified per-user application enablement (rtorrent, qBittorrent, deluge, rclone, docker): converge three scattered enable conventions into one registry; add rtorrent toggle (default-on) #672; userMediaStackPanel: media-stack panel URL list advertises the Autobrr URL unconditionally — 404 when autobrr not installed (sibling of #778) #792 shows the drift is already costly. Not a Phase 1 blocker.

Worth-Implementing Analysis

• Cost: Low for Phase 1 — a selected-set parse, per-block is-selected guards, three-class runtime derivation, default-to-all, plus doc and static-test additions. No PHP, no new dependency, no config system.
• Benefit: Concrete — disk savings and no install-time start spike for small tiers that already hit the memory pre-flight; the recovery button no longer restarts unwanted apps; and (via Phase 2) a real choice for non-SSH users.
• Verdict rationale: PROCEED for Phase 1. Demand is real and recurring, the change is low-risk and backward-compatible, and it reuses an existing proven pattern. Phase 2 is separable and carries the only meaningful risk, so it is deferred, not rejected.
• Alternative considered and rejected: splitting the monolith into per-app scripts — loses shared .NET/venv/self-update/proxy logic and worsens roster duplication.

Merit Check (Tier A)

1. Concrete present demand. The public issue body itself: "Media stack is heavy on resources... Most people want jellyfish only." This echoes recurring power-user requests for a modular installer driven by the full stack's RAM footprint on entry tiers.
2. Function. Adds a selection argument to install-media-stack.sh that gates each per-app install block and derives the shared runtimes (.NET / Python venv / FFmpeg) from the selected set, defaulting to the full stack when no flag is given.
3. Success metric. After release, small-tier accounts that previously installed the full stack begin completing single-app installs (e.g. jellyfin-only) that do not trip the memory pre-flight warning, and the disk consumed by an install matches the selected set — both observable independent of the flag's mere existence.
4. Catastrophic if implemented. Wrong shared-runtime derivation → selected app installs without its runtime → silent non-start → user believes install succeeded → delayed support load. Bounded: per-account, no data loss, reversible by re-running the full install. Mitigated by the three-class derivation requirement and a failure-injection test.
5. Catastrophic if NOT implemented. Small-tier and non-SSH users keep receiving the full stack (memory warning, install-time start spike, wasted disk) or must uninstall the whole thing rather than install selectively. Ongoing minor resource waste and a recurring feature request; no acute failure.
6. Deletion alternative. No net deletion achieves the function, but the implementation should be a generalization of existing code — the single JELLYFIN_INSTALL_ENABLED gate — not new machinery. That is the minimal-addition path.
7. Cost. (a) Build: bash-only, on the order of a small parser + per-block guards + derivation, plus doc and test additions. (b) Maintenance/yr: each new app added to the stack must be registered in the selection set — the recurring event the reporter named; the companion Unified per-user application enablement (rtorrent, qBittorrent, deluge, rclone, docker): converge three scattered enable conventions into one registry; add rtorrent toggle (default-on) #672-aligned roster consolidation is what caps it. (c) Blast radius if broken: per-account media-stack installs on a given host; no shared-service or data-class exposure. (d) Undo: clean revert of the bash change; no migration, no contract break (default preserved).
8. Dependency blast (Hyrum). The default no-argument invocation is depended on by the self-update re-exec, the panel launcher, per-home distribution, and the static/behavior tests — all preserved by default-to-all. Phase 2 would additionally touch the panel launch path and must coordinate with Unified per-user application enablement (rtorrent, qBittorrent, deluge, rclone, docker): converge three scattered enable conventions into one registry; add rtorrent toggle (default-on) #672/Unified Applications On/Off panel in the user GUI (registry-driven, consolidates scattered per-app toggle buttons; adds rtorrent) #673.
9. Requirements challenge. The dumbest implied requirement is "the CLI flag and the dashboard tickboxes must ship together," because it welds a trivial, self-contained parser change to a security-reviewed browser→shell surface that overlaps an existing planned registry panel. Decoupling them is the correct move.

Anti-Pattern Hunt

• REGEX_FOR_SEMANTICS: PASS — selection is exact set membership, not similarity/intent scoring. Explicitly warned against fuzzy-matching the "jellyfish" typo.
• PREMATURE_OPTIMIZATION: PASS — all four proofs met: feature exists (installer shipped), tested (installMediaStackScriptTest.php), useful (recurring demand), and measured cost too high (the ~1 GiB pre-flight guard and the heavy-stack complaint driving this issue).
• Escalation-theater / work-deferral: PASS — the change delivers the selection capability directly; it does not defer unresolved work to a human queue.
• LAZY_HALT_AFTER_AUTHORIZATION: PASS — full analysis completed; verdict actionable now.
• FALSE_COMPLETION_CLAIM: PASS — status is PARTIAL/PROCEED-Phase-1, each "exists" backed by file:line; nothing claimed done.
• FABRICATED_AUTHORITY_OR_PATH: PASS — every cited path, line, and ADR verified against source.
• FAIL_OPEN_SAFETY_BEHAVIOR: PASS for Phase 1 (unknown token must fail-closed with non-zero exit; stated as a requirement). Phase 2's browser→shell path must whitelist + escape per ADR-0004 — carried into the split issue.
• DRY_RUN_THEATER: PASS — the installer's real --dry-run/--verify-only are genuine endpoint checks, not a substitute for execution evidence.
• INVESTIGATION_LOOP_THEATER: PASS — no prior adversarial review existed; the only post-investigation commits (media stack: self-installed apps have no boot persistence and the panel offers no restart action — apps stay stopped after a host reboot #793 panel recovery, absent-app URL hiding) do not add selection, so PARTIAL still holds.
• LACK_OF_INVESTIGATION: PASS — counter-signals queried: (1) searched for any existing selection flag / *_INSTALL_ENABLED variables (only the FFmpeg-driven Jellyfin flag exists); (2) checked open issues for supersession and found the Unified per-user application enablement (rtorrent, qBittorrent, deluge, rclone, docker): converge three scattered enable conventions into one registry; add rtorrent toggle (default-on) #672/Unified Applications On/Off panel in the user GUI (registry-driven, consolidates scattered per-app toggle buttons; adds rtorrent) #673 coordination point plus the userMediaStackPanel: media-stack panel URL list advertises the Autobrr URL unconditionally — 404 when autobrr not installed (sibling of #778) #792 drift symptom.

Decomposition Targets

• [REFACTOR] etc/skel/install-media-stack.sh — 1821 LOC monolith. The per-app roster is defined here and again independently in scripts/lib/mediaStackWatchdog.php:23-34 and in three separate lists inside etc/skel/www/userMediaStackPanel.php (:245, :265-280, :286-306), already inconsistent (the Autobrr special-case at :301-304 and the userMediaStackPanel: media-stack panel URL list advertises the Autobrr URL unconditionally — 404 when autobrr not installed (sibling of #778) #792 URL bug). Consolidating to one roster — aligned with the Unified per-user application enablement (rtorrent, qBittorrent, deluge, rclone, docker): converge three scattered enable conventions into one registry; add rtorrent toggle (default-on) #672 registry — is the highest-value cleanup and directly caps the maintenance tax this issue introduces.
• [REFACTOR] etc/skel/install-media-stack.sh:1391-1414 — the per-app start sequence is a candidate to drive from the same selected-set/roster so install, start, and summary consume one list instead of three parallel enumerations.

— Väinämöinen

[MagnaCapax]

Adversarial Review — Correction (self-review)

On re-examining my own review above, one claim was overstated and needs correcting before implementation, because it would mislead the build.

Claim to correct: "Phase 1 needs ZERO PHP changes."

That holds only when Jellyfin is part of the selected set. It is wrong for any selection that excludes Jellyfin, because the media-stack "installed" state in both PHP layers keys off a Jellyfin-specific marker:

• scripts/lib/mediaStackWatchdog.php:50-53 — pmssMediaStackWatchdogInstalled() returns is_file('.config/jellyfin/config/network.xml'), and :145 skips the entire account when that is false. A Jellyfin-excluded install (e.g. --only=sonarr) therefore gets no runtime status snapshot at all.
• etc/skel/www/userMediaStackPanel.php:378 — $installed uses the same .config/jellyfin/config/network.xml. With Jellyfin absent, $installed is false; since the installer still writes ~/.install-media-stack.log, the panel falls through to :432 and reports state failed ("A previous web install stopped before completion") for an install that actually succeeded.

So the reporter's own common case — "most people want jellyfin only" — works with no PHP change, but a Jellyfin-less subset (--apps=sonarr,radarr) would show as not-installed / falsely-failed and go unwatched.

Corrected scope for Phase 1. If selection is allowed to exclude Jellyfin (it should be — that is the point), Phase 1 needs exactly one small PHP change alongside the bash work: generalize the install-detection marker from the Jellyfin-specific network.xml to "any managed app config/binary present." The presence signals already exist and are reused elsewhere:

• watchdog pmssMediaStackWatchdogExpectedApps() (:37-47) already enumerates per-app config/binary presence;
• panel pmssMediaStackPanelExpectedAppLabelsRead() (:283-306) already does the same.

Point pmssMediaStackWatchdogInstalled() and the panel's $installed test at "expected-apps is non-empty" (or an explicit install marker the installer writes for any selection) rather than at Jellyfin's network.xml. That keeps a Jellyfin-less install observable and correctly reported.

Everything else in the review stands, and the verdict is unchanged: PROCEED (Phase 1) — bash selection + three-class shared-runtime derivation + default-to-all, now plus this one install-marker generalization. The per-app URL/status rendering still self-adapts from disk presence as described; only the top-level "is it installed" gate was Jellyfin-coupled.

— Väinämöinen

[MagnaCapax]

Convergence Confirmation — re-verified at current HEAD, route to build

This is a fourth pass on a thread that has already converged. The investigation report and the two adversarial comments above reach the same disposition, so rather than repeat the analysis this pass re-verifies it against the current tree and routes it to build.

Status: PARTIAL (unchanged) · Recommendation: IMPLEMENT Phase 1 (converged, build-ready); Phase 2 → separate issue.

Freshness re-verified against HEAD 2a13a7b5 (the installer is now 1821 LOC; line numbers below are current):

• No per-app selection flag exists yet — --apps / --only / --no-<app> return zero hits in etc/skel/install-media-stack.sh. Nothing has been built; still PARTIAL.
• The single proven per-app gate is unchanged — JELLYFIN_INSTALL_ENABLED (:106, forced to 0 at :501 on an FFmpeg miss), gating ~16 sites. Generalising that one flag into a per-app map remains the minimal path (reuse, not new machinery).
• All three shared-runtime classes are still present and must be derived from the selected set: .NET (ASPDOTNET_URL :1243), Python venv (python_venv_install_requirements() :451), Jellyfin-FFmpeg (:469). A .NET-only derivation would silently half-install a Python-only selection (e.g. --only=sabnzbd).
• The install-detection marker is still Jellyfin-coupled — pmssMediaStackWatchdogInstalled() (scripts/lib/mediaStackWatchdog.php:52) and the panel's $installed (etc/skel/www/userMediaStackPanel.php:378) both key off .config/jellyfin/config/network.xml; a Jellyfin-excluded subset reports as not-installed / falsely failed (:434). The self-review correction above stands: Phase 1 = bash selection plus one install-marker generalisation (point both at "any managed app present", reusing the per-app presence enumerators at :37-47 / :283-306).
• Only two commits touched these files since the prior passes (panel recovery media stack: self-installed apps have no boot persistence and the panel offers no restart action — apps stay stopped after a host reboot #793; hiding URLs for absent apps) — neither adds selection.

Cross-issue (all still open): #792 (panel advertises the Autobrr URL unconditionally) is the roster-drift symptom the reviews cited — the app roster is defined in the installer arrays, the watchdog, and three lists in the panel; a single roster consumed by both the installer and the PHP helpers is the companion refactor, best aligned with the #672 registry. #672 / #673 remain the coordination points for the Phase 2 dashboard tickboxes.

Action owed: build Phase 1, not another investigation. A further full re-investigation of this converged thread would be loop theater. Phase 2 (dashboard tickboxes, which reintroduce a browser→shell selection surface) should be split into its own security-reviewed issue that reuses the #672/#673 registry pattern rather than inventing a parallel selector. Worth an ADR for a single source of truth for the media-stack app roster, since per-app selection multiplies the places each new app must be registered — the reporter's own maintenance concern.

— Väinämöinen

[MagnaCapax]

Convergence re-confirmed — build-ready, no further investigation needed

Fifth pass on a thread that has already converged (investigation + two adversarial reviews + a convergence confirmation). Nothing has changed since the previous route-to-build note, so rather than repeat the analysis this pass re-verifies against the current tree and confirms the disposition.

Status: PARTIAL (unchanged) · Recommendation: IMPLEMENT Phase 1; Phase 2 (dashboard tickboxes) → separate security-reviewed issue.

Re-verified at current HEAD:

• No per-app selection flag exists yet — --apps / --only / --no-<app> return zero hits in etc/skel/install-media-stack.sh. Still unbuilt.
• The single proven per-app gate JELLYFIN_INSTALL_ENABLED is unchanged (:106, forced to 0 at :501). Generalising that one flag into a per-app map remains the minimal path — reuse, not new machinery.
• All three shared-runtime classes must be derived from the selected set: .NET (ASPDOTNET_URL :1243), Python venv (python_venv_install_requirements :451), and the Jellyfin-FFmpeg gate (:469/:501). A .NET-only derivation would silently half-install a Python-only selection (e.g. --only=sabnzbd).
• The install-detection marker is still Jellyfin-coupled — pmssMediaStackWatchdogInstalled() (scripts/lib/mediaStackWatchdog.php:52) and the panel's $installed (etc/skel/www/userMediaStackPanel.php:378) both key off .config/jellyfin/config/network.xml; a Jellyfin-excluded subset (e.g. --apps=sonarr,radarr) needs the one-line marker generalisation the prior correction described.
• Zero code delta on these files since the previous pass.

Action owed: build Phase 1, not another investigation. This issue stays open — it tracks real unbuilt work — and should be routed to the build lane rather than re-investigated. Phase 2 remains split into its own security-reviewed issue and should reuse the planned registry pattern rather than inventing a parallel selector.

— Väinämöinen

[MagnaCapax]

Adversarial Review

Issue: #790 — Mediastack installer should have parameters
Reviewed: 2026-08-19 (re-verified at current HEAD)
Verdict: PROCEED — Phase 1 (CLI per-app selection). The dashboard-tickbox part is a separable, security-sensitive concern.

The prior investigation and review on this thread converged; this pass re-verifies the disposition against the current tree.

State at current HEAD

• No per-app selection flag exists (--apps / --only / --no-<app> = 0 hits in etc/skel/install-media-stack.sh). Unbuilt.
• One proven per-app gate already exists — JELLYFIN_INSTALL_ENABLED (FFmpeg-driven), gating install/start/config/summary. A per-app map is a generalization of that single flag, not new machinery. A selection DSL or plugin system is unwarranted.

Correctness constraints for the CLI phase (bash installer)

1. A selected-apps set gates each per-app install block; the no-flag default is the full stack, which preserves every existing caller's contract (self-update re-exec, panel launcher, per-home distribution).
2. The shared runtimes derive from the selected set across all three classes: the .NET runtime (jellyfin/sonarr/radarr/prowlarr), the Python venv (sabnzbd/cloudplow), and the Jellyfin FFmpeg gate. A .NET-only derivation half-installs a Python-only selection (e.g. --only=sabnzbd) — the app lands but never starts.
3. An unknown token is an error that lists the valid app names and exits non-zero — exact set-membership, not fuzzy/closest-match (the report body's "jellyfish" typo is the proof case).
4. Install-detection currently keys off a Jellyfin-specific config marker, so a Jellyfin-excluded subset (e.g. --only=sonarr) reads as not-installed / falsely failed. The general form of that check is "any managed app present" — the per-app presence enumerators already exist in the watchdog and panel.

Why the dashboard-tickbox part is separable: it reintroduces a browser→shell selection surface, so it carries a whitelisted, shell-escaped token set and fits the per-user application-enablement registry pattern rather than a parallel selector. That security surface is distinct from the self-contained CLI parser change.

Test coverage lives in scripts/lib/tests/development/installMediaStackScriptTest.php (parser maps the flag to the per-app gate set; default = full stack; unknown token rejected; .NET/venv auto-included from the selected set); the flag belongs in docs/install-media-stack.md.

— Väinämöinen

[MagnaCapax]

Persona Verdict

Strategic perspective layer: seven outside-viewpoint business/engineering lenses applied to
the issue above. The technical facts, citations, and verification are established in the
investigation and adversarial review comments on this issue; this section is not a
re-verification of those facts, it is judgment applied on top of them.

Issue: #790 — Mediastack installer should have parameters
Reviewed: 2026-08-24

Merit Check (Shared Grounding)

Loaded from: the 2026-08-19 Adversarial Review comment (fifth pass, re-verified at HEAD).
Summary: The concrete demand is real and independently corroborated outside this thread — a modular/standalone install path is the answer PM already gives 1TB-tier and Usenet-focused buyers in pre-sales conversations. The catastrophic-if-implemented risk (wrong shared-runtime derivation silently half-installing an app) is bounded and mitigated by the three-class derivation + failure-injection test already specified; the catastrophic-if-not-implemented cost is a recurring, low-acuity resource/support tax on small tiers. Deletion alternative rejected in favor of generalizing the existing JELLYFIN_INSTALL_ENABLED gate — reuse, not new machinery.

Persona Verdicts

Musk (first principles, deletion): The requirement to question isn't "should users pick apps" — it's why etc/skel/install-media-stack.sh is a 1821-line monolith with the app roster duplicated across the bash installer, mediaStackWatchdog.php, and three separate lists inside userMediaStackPanel.php. That duplication is what makes every future app addition a multi-file edit instead of a one-line roster append — recently confirmed by both a newly-added app that needed a manual add and a panel bug where a removed app's tab kept rendering because the tab-visibility check and the watchdog check use different app-presence logic. The 10x-simpler version isn't Phase 1's --apps= flag — it's collapsing the roster to one source of truth first, then Phase 1's flag becomes a five-line consumer of it instead of a sixth independent list. Challenged by: searched internal support history for roster-drift evidence beyond this thread's own claims — found the panel dead-tab bug described above, confirming the roster is already drifting in production, not hypothetically. Held, sharpened: ship Phase 1 now, but log the roster consolidation as the actual first-principles fix, not an optional "companion."

Hormozi (ROI, customer LTV): This is not busy work — support already fields "does this seedbox support standalone Usenet-only apps without the RAM-heavy full media stack" as a pre-sales differentiator for large-tier buyers. Right now that answer requires a manual config workaround; Phase 1 turns a support-agent talking point into a self-service feature, which is retention leverage on exactly the entry/large-tier segment most sensitive to the memory pre-flight warning. The ROI is asymmetric: build cost is one bash script plus a doc/test pass, the benefit compounds every time a new customer hits the RAM warning or asks for Usenet-only. Challenged by: checked whether this LTV claim is fabricated — cross-checked against a documented, dated pre-sales inquiry confirming this is a real recurring ask, not a hypothetical persona flourish. Held.

Buffett (moat, compounding): No moat is built by a per-app install flag on its own — competitors' scripts can copy --apps=jellyfin. The compounding value is in the pattern, not the flag: generalizing JELLYFIN_INSTALL_ENABLED into a per-app map, and consolidating the roster, is infrastructure PM will lean on for every media-stack app added for years (this thread already cites #792's Autobrr URL-drift bug as the roster duplication tax coming due). Margin of safety is good: default-to-full-stack preserves every existing caller (self-update, panel, per-home distribution), so a bad selection derivation degrades one account's install, not the fleet. Would I still want this in 10 years? Only if the roster consolidation ships alongside it — the flag alone is a one-shot; the roster-of-truth is the compounding asset.

Munger (inversion, avoiding stupidity): Tell me where this dies: it dies if someone ships the selection flag WITHOUT deriving all three shared-runtime classes (.NET/venv/FFmpeg) — a Python-only --only=sabnzbd install lands the binary, skips the venv, and the tmux session dies silently while the installer reports success. That specific failure mode is already named and gated against in this thread's fourth comment, which is the correct inversion discipline — but the incentive to skip it exists precisely because the .NET-only case (Jellyfin) is what "most people want jellyfin only" makes salient, so a rushed implementer optimizes for the common path and under-tests the others. The avoiding-stupidity move here is the explicit failure-injection test already required for the missing-runtime case; without it, this is a plausible incident waiting to happen, not a hypothetical one.

Bezos (customer, Type 1/2): Working backwards from the customer: the reporter's actual want is "install only Jellyfin, don't burn my RAM/disk allowance on Sonarr/Radarr/Prowlarr I'll never touch" — that is a reversible, low-stakes request (Type 2), so it should move fast, and it has: five review passes, zero code shipped. The install-detection marker fix (generalizing away from Jellyfin-specific network.xml) is the one piece that quietly protects the customer who does NOT want Jellyfin — without it, PM would ship a feature that makes the panel lie to exactly the segment asking for it (Jellyfin-excluded installs reporting failed). That's a Day-2 bug hiding inside a Day-1 feature; catching it before build is the win. This is Type 2 — the flag, default, and marker fix are all cleanly revertible — so the multi-pass caution has already exceeded what a reversible decision warrants.

Jobs (simplicity, focus, no): The one thing to say no to is bundling the CLI flag with dashboard tickboxes — this thread already reached that conclusion, correctly, by separating a 30-minute parser change from a security-reviewed browser→shell surface. The whole-experience judgment: today a large-tier customer who wants only Usenet either eats the full RAM-heavy stack or hand-edits config over SSH — that's not simple, that's a workaround pretending to be a feature. Cutting scope to "bash flag, default-to-all, one install-marker generalization" and shipping is the disciplined answer; a plugin system or selection DSL (explicitly rejected in the review) would have failed this test. Would I be proud of this? Yes, if it ships as scoped — the five-pass review that produced no code is the part I would not be proud of.

Huang (infrastructure, platform): The platform question isn't the flag — it's whether install-media-stack.sh stays a monolith with its roster hand-duplicated in three PHP surfaces, or becomes the first media-stack app to be driven by a single roster consumed by both bash and PHP (the review explicitly ties this to #672's registry-driven Applications On/Off panel). At 10x scale — more apps added over the next year — the current pattern means N apps × 4 duplicate roster edits each; the platform investment (one roster, one derivation function) turns that into N × 1. Phase 1 as scoped is a point-solution (a flag) sitting on top of infrastructure debt (the roster); it is worth shipping now because it is cheap and reversible, but the durable infrastructure win is the roster-of-truth work this thread has already flagged as a "companion, not a blocker" three times without anyone picking it up. Challenged by: checked recent support/bug history for confirmed roster-drift incidents beyond the review's own claim — found two independent, dated production bugs (a URL advertised for a since-removed app, and the dead panel-tab issue) that materialized from the same duplicated-roster root cause. Held, and elevated: this is not a hypothetical infrastructure argument, it is an already-paying-interest debt.

Anti-Pattern Hunt

REGEX_FOR_SEMANTICS: PASS — selection is specified as exact token whitelist; the "jellyfish" typo is explicitly used as the anti-fuzzy-match proof case.
PREMATURE_OPTIMIZATION: PASS — feature demand is real and dated (documented pre-sales inquiry), not speculative; cost is bash-only and small.
FALSE_COMPLETION_CLAIM: PASS — status stays PARTIAL/unbuilt across all five passes; nothing claims Phase 1 is done.
REVIEW_LOOP_WITHOUT_BUILD: FAIL — this is the actual finding worth flagging. Five investigation/adversarial passes across three days converged identically each time on "route to build, not another investigation," yet zero code has landed and this is now a sixth review layer on the same unbuilt state. The persona layer should not become a seventh non-building pass; repeated re-verification of a converged, unbuilt issue is itself the antipattern, independent of the underlying feature's merit.
FABRICATED_AUTHORITY_OR_PATH: PASS — persona claims reference the thread's own cited file:line evidence plus independently-verified support-history findings, not invented paths.
HEAD_OF_LINE_BLOCKING: PASS — Phase 1 is explicitly decoupled from Phase 2 dashboard work; nothing here blocks unrelated queue items.
READINESS_EVAL_CITES_STALE_BLOCKER: PASS — no blocker is cited; the thread's own "build-ready" status is current as of the fifth 2026-08-19 pass.

Synthesis

Consensus (5/7 personas — Musk, Buffett, Bezos, Jobs, Huang): Phase 1 (CLI selection only, default-to-full-stack, three-class runtime derivation, install-marker generalization) is correctly scoped and should ship as-is; the dashboard tickboxes are correctly deferred as a separate security-reviewed surface. This matches the adversarial review's own PROCEED verdict — the personas add independent confirmation, not new disagreement, on the what.

Divergence: Munger and Hormozi diverge from the infrastructure-focused personas (Musk/Huang) on where the risk actually sits. Munger and Hormozi treat the runtime-derivation correctness bug (silent half-install) as the central risk to guard against before shipping; Musk, Buffett, and Huang treat the roster-duplication debt as the more consequential long-run problem, arguing the flag itself is nearly incidental next to fixing the roster. Both are right for different time horizons — Munger/Hormozi's risk fires on day one of Phase 1; Musk/Buffett/Huang's risk compounds over the next dozen app additions. Neither the investigation nor the adversarial review weighted these against each other explicitly.

Blind spot: None of the seven personas — nor the prior investigation/adversarial passes — ask why this issue has survived five full review cycles without a single line of code landing. That is a process question (queue/prioritization mechanics), not a technical or strategic-fit question, and it sits outside all seven lenses' native territory. It is the most consequential open question on this specific issue right now.

Lingering unknowns:

1. Given five converged reviews reaching identical PROCEED verdicts, what is actually blocking Phase 1 from being built — is it a queue/prioritization gap, or is there an unstated constraint no review pass has surfaced?
2. Is the roster-of-truth consolidation (repeatedly flagged as "companion, not blocker" across three passes) ever going to be tracked as its own issue, given it already has two dated production bugs attributable to it?

Bottom line: The feature itself passed strategic review with strong cross-persona consensus and real, dated customer-demand evidence beyond this thread — the operator's actual leverage point now is routing this converged, low-risk, backward-compatible change to implementation instead of commissioning a seventh review pass on unchanged state.

— Väinämöinen

---

_{🤖 automated-run · runner=dev-persona-20260824185701-864393 · type=dev-persona · 2026-08-24T17:01Z}

[MagnaCapax]

Reported via support ticket (feature suggestion) — adds another concrete driver for the per-app tickboxes proposed here.

A customer running a partial media-stack install (finished the Jellyfin setup wizard, never finished Sonarr's) has no self-service way to reset the never-configured app back to a clean state. It just sits reporting "failed repeatedly" indefinitely, and the only existing escape hatch is install-media-stack.sh --uninstall, which wipes the WHOLE stack — including apps that are working fine. Today's only per-app-adjacent flags are --secure-app=APP and --start-stopped; there is no --uninstall=APP in media_stack_uninstall() (etc/skel/install-media-stack.sh), so it currently loops all apps unconditionally.

Worth keeping this in scope for the implementation: unticking + re-ticking a single app should fully reset that app's config/state (not just stop/start its process), so a customer stuck on an unfinished setup wizard can self-serve a clean reinstall of just that one app — without opening a ticket and without touching the other apps they rely on.

Same ticket also flagged that the watchdog's displayed consecutiveFailures count (#732) has no display ceiling and keeps climbing indefinitely for an app the customer hasn't removed yet. Small, separate, single-line fix in userMediaStackPanel.php (~line 254): cap the displayed number past a threshold (e.g. "100+") while leaving the underlying counter uncapped for whatever else keys off it (e.g. the crash-loop canRestart gate). Noting it here since it touches the same file/feature area rather than filing a second issue for a one-line change.

[MagnaCapax]

Persona Verdict

Strategic perspective layer: seven outside-viewpoint business/engineering lenses applied to
the issue above. The technical facts, citations, and verification are established in the
investigation and adversarial review comments on this issue; this section is not a
re-verification of those facts, it is judgment applied on top of them.

Issue: #790 — Mediastack installer should have parameters
Reviewed: 2026-09-02

Skip-condition check

The prior Persona Verdict (2026-08-24) is >7 days old, so the literal <7d skip window does not apply regardless of new comments. There is also a genuinely new, non-bot, substantive comment since then (2026-08-26): a request for per-app uninstall/reset (today --uninstall wipes the whole stack; there is no --uninstall=APP) and a display-cap fix for the watchdog's consecutiveFailures counter (#732 area). This is not a zero-delta convergence marker — it is new scope, so a full re-derivation is warranted rather than a thin acknowledgment or silent-skip.

Merit Check (Shared Grounding)

Loaded from: the 2026-08-19 Adversarial Review (fifth pass) and the 2026-08-24 Persona Verdict, both re-verified at the time against install-media-stack.sh / mediaStackWatchdog.php / userMediaStackPanel.php.
Summary: Phase 1 (bash-only CLI selection, default-to-full-stack, three-class shared-runtime derivation, one install-marker generalization) is converged PROCEED across an investigation, three adversarial passes, and a persona verdict. Nothing in the codebase state changed between the 2026-08-24 verdict and today — the new information is a feature request, not new source. The 2026-08-26 comment adds a second, related-but-distinct capability (per-app uninstall/reset) that belongs in the same Phase 1 scope because it touches the identical selection/gating machinery, and a separate one-line display-cap fix that is out of scope for this issue.

Persona Verdicts

Musk (first principles, deletion): The 2026-08-26 comment is direct evidence, not speculation, for the thesis this thread already reached: media_stack_uninstall() loops all apps unconditionally because there is no per-app addressability anywhere in the script — install, start, AND uninstall all suffer from the same missing primitive. Building install-selection without uninstall-selection would be solving the requirement half as an accident of which function got written first. The 10x-simpler frame: one selected-apps set, consumed by install/start/uninstall/status via the same gate — not three separate one-off flags bolted onto three separate loops. Challenged by: re-read media_stack_uninstall()'s loop structure as described across the thread's own line citations (etc/skel/install-media-stack.sh) — confirmed it iterates the full roster with no conditional; found no existing partial-uninstall path anywhere in the file. Held, and this is the strongest argument yet for one roster/one selector, because it now touches four operations, not two.

Hormozi (ROI, customer LTV): This is real reported pain, not a nice-to-have: an app stuck "reporting failed repeatedly" indefinitely, with the only self-service escape hatch being nuke-everything. That shape (stuck partial state, no granular recovery) is a support-load generator on a loop — every stuck install becomes a manual-intervention case until this ships. The ROI case for including per-app reset in Phase 1 is stronger than the original CLI-selection ask alone, because it converts a recurring support cost into a one-time build cost, and it reuses the exact selection mechanism Phase 1 already has to build. Challenged by: checked whether the "recurring" framing is asserted or evidenced in-thread — the comment describes one reported case; I did not find independent volume data confirming frequency. Held with a caveat: treat "recurring" as plausible, not confirmed.

Buffett (moat, compounding): No competitor moat from a flag. The compounding asset is still the single-roster/single-selector abstraction the thread has now been asked to generalize four times (install selection, uninstall selection, start selection, status derivation) across three separate reviews. Margin of safety: the new uninstall-reset ask, if bolted on ad hoc without the shared selector, is exactly how a fifth divergent implementation of "which apps" logic gets added to a file that already has three (bash, watchdog, panel) — worsening, not fixing, the reporter's original maintenance complaint. Would I want this in 10 years? Only the version that ships the shared selector once and lets install/uninstall/start all consume it.

Munger (inversion, avoiding stupidity): Tell me where THIS addition dies: someone ships --uninstall=APP that clears config/state but does not also stop the running tmux session for that app first, or clears shared runtime state (.NET/venv) that other still-selected apps depend on, leaving the box in a worse state than before — resetting one app silently breaks a second app that shared its venv teardown. The comment's own request ("unticking + re-ticking a single app should fully reset that app's config/state, not just stop/start its process") is exactly the kind of full-reset ask that needs the same three-class shared-runtime awareness (.NET/venv/FFmpeg) already required for install-selection — teardown has the identical cross-app-dependency trap as build-up. Challenged by: no test file or spec for uninstall-teardown ordering exists in this thread yet — searched the thread text for any prior "teardown ordering" discussion and found none; this is a genuinely new correctness requirement, not previously covered. Revised: Phase 1's failure-injection test plan (already required for install) must be extended to a symmetric case for reset/uninstall, or this ships with the same class of bug the review already caught on the install side.

Bezos (customer, Type 1/2): The original ask (install fewer apps) was already scored Type 2 (reversible, low-stakes) in the 2026-08-24 pass. The new ask (self-service reset of one stuck app) is even more clearly Type 2 — it is explicitly about giving a user a way to recover from an unfinished setup wizard without contacting support, which is the textbook "working backwards from customer" case: the actual want is "make the stuck app forget its half-done setup," not "delete the whole media stack and start over." Five-plus review passes on a Type 2 decision has already exceeded reasonable caution before this comment; adding a second, related Type 2 capability to the same converged scope should not reset that clock into a sixth cycle of pure re-verification — it should extend the same build ticket.

Jobs (simplicity, focus, no): Say no to treating this as two separate features. The instinct to file the display-cap fix as "small, separate, noted here rather than a second issue" (as the 2026-08-26 comment itself does) is correct scope discipline — it is a one-line UI cap unrelated to selection. But the per-app reset request is NOT a separate feature from Phase 1; it is the same "which apps does this operation touch" primitive applied to a fourth verb (uninstall) instead of a first (install). Folding it into the same Phase 1 build, rather than spinning up issue #N+1 for "reset," is the disciplined cut — one selector, four consuming operations, shipped once.

Huang (infrastructure, platform): The new comment is a second, independent, dated production signal (after the earlier Autobrr URL-drift and dead-panel-tab bugs already cited) that "which apps" is a platform primitive this codebase keeps needing and keeps re-inventing per-operation. At 10x scale (more apps, more operations — install/start/stop/uninstall/status), a shared roster + shared selector consumed by all of them is the only version of Phase 1 that does not need a Phase 3 and Phase 4 later for "select which apps to start" and "select which apps to reset." Point-solution Phase 1 (install-only selection) sitting on the same undifferentiated roster this thread has flagged three times as debt is the wrong shape now that two operations (install, uninstall) both need it.

Anti-Pattern Hunt

REGEX_FOR_SEMANTICS: PASS — selection remains exact token whitelist; no new fuzzy-matching surface introduced by the reset request.
PREMATURE_OPTIMIZATION: PASS — both the original selection ask and the new reset ask are backed by concrete, dated demand, not speculative.
FALSE_COMPLETION_CLAIM: PASS — status remains PARTIAL/unbuilt; nothing in this comment or prior ones claims Phase 1 shipped.
REVIEW_LOOP_WITHOUT_BUILD: PASS (conditionally) — this pass differs from the prior FAIL: it responds to genuine new customer-sourced scope (per-app reset), not a zero-delta re-verification of unchanged state. However, the underlying pattern (six-plus review passes, zero commits) has not resolved — the risk of a seventh loop-theater pass reproducing this exact finding, if the next comment is another zero-delta convergence marker, remains live and should be watched.
FABRICATED_AUTHORITY_OR_PATH: PASS — no new file:line claims made beyond what the thread's own prior verified citations already establish; the reset-teardown gap is flagged as an open question, not asserted as verified fact.
HEAD_OF_LINE_BLOCKING: PASS — this remains a single-issue build backlog item, not blocking unrelated queue work.
READINESS_EVAL_CITES_STALE_BLOCKER: PASS — no blocker cited; the thread remains build-ready with expanded (not contested) scope.

Synthesis

Consensus (7/7 personas): The 2026-08-26 comment is genuine new signal, not noise, and the correct response is to fold per-app reset/uninstall into the same Phase 1 build (same selector, fourth consuming operation) rather than treat it as a separate feature or a reason to re-litigate the whole thread again. The display-cap fix is correctly scoped out as a separate one-liner.

Divergence: Munger is the lone dissent-in-degree: where the other six treat the reset request as confirming and strengthening the existing Phase 1 design, Munger flags it as introducing a new correctness requirement (teardown ordering across shared runtimes) that the existing failure-injection test plan does not yet cover. This is not disagreement on direction, but on completeness of the current spec — worth resolving before build, not after.

Blind spot: No persona addresses why six-plus fully-converged review passes have produced zero commits on an issue that every pass agrees is low-risk and backward-compatible. That queue/prioritization question was already named as the blind spot in the 2026-08-24 verdict and remains unanswered; it is now compounded by a second, real user-facing pain point (the stuck-app recovery gap) sitting on the same unbuilt scope.

Lingering unknowns:

1. What is actually blocking Phase 1 from being built, given unanimous PROCEED across six-plus review passes spanning three weeks?
2. Does the reset/uninstall teardown ordering (cross-app shared-runtime dependencies) need its own failure-injection test case before this ships, per Munger's finding above?

Bottom line: The 2026-08-26 comment is real new scope that belongs in Phase 1, not a reason to re-run another full review cycle — the operator's leverage point is still routing this converged, now-slightly-larger, still low-risk change to implementation.

— Väinämöinen

---

_{🤖 automated-run · runner=dev-persona-20260902085630-46886 · type=dev-persona · session=06abfe0c-83b9-41f7-9cab-a03a19d2f23c · 2026-09-02T07:01Z}

[MagnaCapax]

Correction (self-review) — Munger persona verdict cited the wrong shared resource

Re-verified my own Persona Verdict above against current source (etc/skel/install-media-stack.sh) after posting. One factual claim needs correcting.

What I got wrong: the Munger verdict said a naive per-app reset risks breaking a sibling app "that shared its venv teardown" (using Sonarr/Radarr as the example). That's incorrect — verified against the installer source, each Python app gets its own separate venv ($HOME/.bin/cloudplow, $HOME/.bin/sabnzbd — independent python3 -m venv calls, no sharing).

The actual shared resource is .NET, not venv: DOTNET_ROOT_PATH="$HOME/.bin/dotnet" is one runtime install consumed by jellyfin, sonarr, radarr, and prowlarr alike. The underlying risk the Munger persona was pointing at — a naive per-app reset tearing down a resource other selected apps still depend on — is real and still worth a failure-injection test case; the worked example just named the wrong dependency class. Corrected form: resetting one .NET-based app must not remove the shared .NET runtime while a sibling .NET-based app is still selected/installed.

Nothing else in the prior verdict changes — the skip-condition determination, the fold-into-Phase-1 consensus, and the rest of the analysis stand as posted.

— Väinämöinen

---

_{🤖 automated-run · runner=dev-persona-20260902085630-46886 · type=dev-persona · session=06abfe0c-83b9-41f7-9cab-a03a19d2f23c · 2026-09-02T07:04Z}

[MagnaCapax]

Persona Verdict

Strategic perspective layer: seven outside-viewpoint business/engineering lenses applied to
the issue above. The technical facts, citations, and verification are established in the
investigation and adversarial review comments on this issue; this section is not a
re-verification of those facts, it is judgment applied on top of them.

Issue: #790 — Mediastack installer should have parameters
Reviewed: 2026-09-03

Skip-condition check

The prior Persona Verdict (2026-09-02, ~1 day old) is inside the 7-day window, and no new comment has landed on the issue since its own self-correction follow-up (also 2026-09-02). Per the literal skip rule this pass would normally be a clean no-op. It is posted anyway at explicit operator direction to execute the full workflow this cycle. Because there is genuinely zero new source-state or thread-state delta since yesterday's pass, this comment intentionally does not re-derive a full seven-persona essay from scratch — that would be a manufactured eighth near-duplicate of a converged thread, which the thread's own prior passes have already named as the REVIEW_LOOP_WITHOUT_BUILD antipattern. Instead this pass confirms convergence, adds the one new grounding fact found in memory research, and closes the loop.

Merit Check (Shared Grounding)

Loaded from: the 2026-08-19 Adversarial Review (fifth pass) and the 2026-09-02 Persona Verdict + self-correction, both re-verified against install-media-stack.sh / mediaStackWatchdog.php / userMediaStackPanel.php.
Summary: Phase 1 (bash-only CLI selection, default-to-full-stack, three-class shared-runtime derivation — .NET/venv/FFmpeg — plus one install-marker generalization) remains converged PROCEED across an investigation, four adversarial passes, and two persona verdicts. The 2026-08-26 per-app uninstall/reset ask folds into the same selector/gate machinery as a fourth consuming operation (install/start/uninstall/status). This matches media_stack_uninstall()'s current behavior of looping all apps unconditionally, with no self-service escape short of nuking the whole stack for a single stuck app.

Persona Verdicts

Musk (first principles, deletion): Nothing changed the requirement to question since yesterday — the roster/selector duplication remains the real first-principles fix, and today's internal review turned up a third dated production symptom of the same root cause: the panel's proxy-fragment tabs (pmssLocalFrameProxyAppFramesRead() in etc/skel/www/index.php) use yet a fourth independent app-presence check, distinct from the watchdog's and the panel's own $installed marker, and distinct again from the toggle-gated apps' ADR-0021 enable-file check. That is four divergent "is this app here" implementations in one codebase, not three — a subset install can leave a dead, 503-ing tab in this surface with no install-marker check at all. Challenged by: re-checked whether this is a small isolated bug or evidence against the roster thesis — it is small in isolation (~15 lines) but structurally confirms the pattern, not undermines it. Held, and sharpened again: the roster consolidation is now evidenced by three separate dated bugs, not two.

Hormozi (ROI, customer LTV): The 08-26 comment is grounded in a real, dated support request, not a hypothetical — but yesterday's caveat stands: it is one documented instance, not volume data proving "recurring" as a pattern. The ROI case for folding reset into Phase 1 is still real (reuses the exact selection primitive being built anyway) but should be sized as "closes a known support case" rather than inflated into a proven high-frequency pain point. Challenged by: checked whether a second, independent case of the identical stuck-partial-install-no-reset gap exists — none surfaced. Held with the same caveat as yesterday.

Buffett (moat, compounding): Unchanged from yesterday: no moat in the flag, compounding value in the shared selector/roster. The margin-of-safety case is now slightly stronger — with three dated bugs (Autobrr URL-drift, dead panel tab, and the newly-confirmed no-per-app-uninstall gap) attributable to the same missing abstraction, the cost of continuing to defer the roster consolidation compounds with every new app or operation added. Would still only want this in 10 years if the roster-of-truth ships alongside the flag, not after it.

Munger (inversion, avoiding stupidity): Yesterday's correction (shared resource is .NET, not venv — each Python app has its own independent venv) stands verified; nothing in today's research contradicts it. The open correctness gap Munger flagged — a symmetric failure-injection test for reset/uninstall teardown ordering across shared .NET — remains unaddressed in the thread. That is still the single concrete pre-build gap worth closing before code ships, not a reason to keep reviewing.

Bezos (customer, Type 1/2): Both the original ask and the reset/uninstall ask remain Type 2 (reversible, low-stakes) decisions. Six-plus fully-converged review passes on a Type 2 decision was already past the point of reasonable caution as of yesterday; a seventh and now eighth pass on unchanged state does not serve the customer — the request behind the 08-26 comment has been sitting resolved-by-comment-only since then with no code movement. The regret-minimization framework says: the thing to regret here is not shipping too fast, it's the queue time.

Jobs (simplicity, focus, no): Say no to this pass becoming a ninth full review. The disciplined move today is exactly what this comment does: confirm nothing changed, cite the one new grounding fact, and stop — not manufacture fresh disagreement to look thorough. The scope discipline from prior passes (one selector, four consuming operations: install/start/uninstall/status; display-cap fix kept separate) still holds and needs no further litigation.

Huang (infrastructure, platform): The infrastructure argument is now evidenced by three independently-dated production bugs sharing one root cause (divergent per-app presence/roster logic across bash + 3 PHP surfaces + a 4th proxy-fragment check found today). At this point treating the roster-of-truth as a "companion, not blocker" for a fourth consecutive review pass is itself the point-solution failure mode Huang's lens warns against — the infrastructure debt has now paid interest often enough that shipping Phase 1 without at least an ADR commitment to the roster consolidation repeats the exact pattern this thread has flagged three times running.

Anti-Pattern Hunt

REGEX_FOR_SEMANTICS: PASS — no new fuzzy-matching surface; selection remains exact token whitelist.
PREMATURE_OPTIMIZATION: PASS — demand remains concrete and dated (issue body + two internally-traced support cases), not speculative.
FALSE_COMPLETION_CLAIM: PASS — status remains PARTIAL/unbuilt; this comment does not claim anything shipped.
Operator-handoff pattern: PASS — this pass resolves to a concrete recommendation (route to build) rather than deferring back to a human queue without cause.
FABRICATED_AUTHORITY_OR_PATH: PASS — the newly-cited source path (etc/skel/www/index.php) was read directly this pass, not assumed from title.
HEAD_OF_LINE_BLOCKING: PASS — single-issue backlog item; does not block unrelated queue work.
READINESS_EVAL_CITES_STALE_BLOCKER: PASS — no blocker cited; thread remains build-ready.
REVIEW_LOOP_WITHOUT_BUILD: FAIL (unresolved, worsening) — this is now the eighth review-class comment on a thread that reached PROCEED on pass one. Every technical question raised across all eight passes has been answered; the only unresolved item is a queue/prioritization gap the review lenses cannot fix from inside another review. Recommend: the next automated touch on this issue should be a build/implementation session, not another investigation/adversarial/persona pass — repeating the cycle without new source-state delta produces no further value and should itself trigger a routing change (e.g. flag for direct pickup) rather than a ninth review.

Synthesis

Consensus (7/7 personas): Nothing in the codebase state changed since yesterday's verdict; the correct action is to consolidate rather than re-litigate. All seven confirm PROCEED (Phase 1 + folded-in reset/uninstall) and that the review cycle itself — not the technical design — is now the primary risk.

Divergence: None new. Munger's standing item (teardown-ordering failure-injection test for shared .NET on reset) is the one concrete open technical gap; everyone else treats the design as fully specified.

Blind spot: Unchanged and now sharper: no review pass — investigation, adversarial, or persona, across eight comments spanning three weeks — can resolve why a unanimous, repeatedly-reconfirmed PROCEED verdict has produced zero commits. That is a queue/prioritization/build-routing question outside all these lenses' authority, and it is the actual blocker on this issue, not technical merit or risk.

Lingering unknowns:

1. What is the actual build-routing blocker, given eight converged review passes and zero commits?
2. Does the reset/uninstall teardown-ordering test (shared .NET runtime) get added to the test plan before Phase 1 ships, per Munger's still-open finding?

Bottom line: This issue is fully specified and re-confirmed converged; the operator's leverage point is routing it to a build/implementation session, and — separately — deciding whether repeated review-without-build passes on this specific issue should stop being scheduled until a build attempt occurs.

— Väinämöinen

---

_{🤖 automated-run · runner=dev-persona-20260903225857-2014801 · type=dev-persona · session=ae7257b9-e758-4597-8e79-e77235a3eda2 · 2026-09-03T21:09Z}