majestic: cli applies a change now, so stop calling it deprecated

[widgetii]

Problem

Wiki commit b126e5e (#477) migrated 71 recipes from cli to the HTTP API and marked cli
deprecated, on the grounds that the API applies a change live and cli does not. That was
true when it was written. OpenIPC/firmware#2366 has since made cli -s write
/etc/majestic.yaml and then ask Majestic to reload, so the pages describe firmware that no
longer exists.

Three of the claims are wrong rather than merely stale.

What changed

cli is not deprecated — majestic-streamer.md, menu-index.md,
howto-tinycam-onvif.md. The two tools now do the same job, and the pages say which is
better at what instead of preferring one: cli is the one that works before Majestic is
running, which is the whole of first boot (a customizer.sh has no API to call), and it can
write a key this build does not declare. The API validates — 404 for a key the binary does
not have, 400 for a value out of range — and can be called from another machine.

The SIGHUP row was wrong — majestic-streamer.md. It said a reload tears the pipeline
down and builds it again. Majestic has priced the difference for a while now and takes the
cheapest option that will carry the change, which is exactly why setting a bitrate no longer
costs the stream. The row now describes that ladder.

The plugin table attributed reloading to the wrong thing — majestic-plugins.md. It read
killall -HUP majestic (what the WebUI and cli use to apply a change) against a
parameter set live through the HTTP API, which splits on who sent the write. Both the WebUI
and cli produce either outcome depending on the key. The rows now split on what actually
decides it: a reload that rebuilds the pipeline reloads the plugin; a change applied in place
does not.

And majestic-config.md now says why a saved file stays short. widgetii/majestic#608
stopped Majestic writing its own defaults into majestic.yaml, so a value you never set is
absent rather than frozen at whatever the default happened to be when you last pressed Save.
That is what lets a corrected default reach a camera that has already been configured, and it
is worth stating on the page that shows people the full key list.

Checked

No CI in this repo, so by hand:

$ grep -rni deprecat en/ --include='*.md' | grep -iE 'cli|yaml'
(nothing)

$ grep -rn 'cli -s' en/ --include='*.md' | grep -i killall
(nothing — no recipe still tells people to signal after a cli write)

Tables keep their column counts, every relative link in the five changed files resolves, and
#changing-parameters-via-the-http-api still exists — it is linked from two places and both
are in this diff. The heading is deliberately left alone so external deep links keep working.

en/archive/ is untouched.

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

Tip of the day

💡 Did you know, you can keep summaries lean with Finding overflow, which tucks the rest behind 'View more'

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Correct Majestic CLI and reload behavior documentation

🐞 Bug fix 📝 Documentation 🕐 10-20 Minutes

AI Description

• Removes stale deprecation guidance now that cli persists and applies Majestic changes.
• Corrects reload and plugin lifecycle documentation to reflect cost-based change handling.
• Explains default-aware persistence and differences between CLI and HTTP API.

Diagram

graph TD
  Shell["Camera Shell"] --> CLI["cli write"] --> Config["majestic.yaml"] --> Engine{"Change cost"} --> Live["In-place apply"]
  Remote["Remote Client"] --> API["HTTP API"] --> Config
  Engine --> Rebuild["Rebuild + plugin"]

Loading

High-Level Assessment

The PR's behavior-centric documentation is the appropriate approach. Distinguishing CLI and API capabilities while describing reload outcomes by change cost—rather than by the caller—matches current firmware behavior and avoids reinstating obsolete API-only guidance.

Files changed (5) +30 / -12

Documentation (1) +7 / -0

majestic-config.mdExplain default-aware configuration persistence +7/-0

Explain default-aware configuration persistence

• Clarifies that WebUI, API, and CLI saves retain only values differing from build defaults. Explains how omitted values can inherit corrected defaults after firmware upgrades.

en/majestic-config.md

Other (4) +23 / -12

howto-tinycam-onvif.mdReplace deprecated CLI guidance for ONVIF passwords +3/-3

Replace deprecated CLI guidance for ONVIF passwords

• Documents that 'cli -s' applies ONVIF password changes itself and no longer requires a manual SIGHUP. Retains a link to the broader parameter-changing guidance.

en/howto-tinycam-onvif.md

majestic-plugins.mdCorrect plugin reload lifecycle conditions +4/-4

Correct plugin reload lifecycle conditions

• Defines plugin reload behavior according to whether Majestic rebuilds the pipeline or applies a change in place. Removes the incorrect distinction between API-, WebUI-, and CLI-originated changes.

en/majestic-plugins.md

majestic-streamer.mdDocument cost-based reloads and supported CLI writes +15/-4

Document cost-based reloads and supported CLI writes

• Corrects SIGHUP behavior to describe Majestic's graduated application strategy instead of an unconditional pipeline rebuild. Removes CLI deprecation guidance and compares local CLI flexibility with HTTP API validation and remote access.

en/majestic-streamer.md

menu-index.mdRemove yaml-cli deprecation from the tools index +1/-1

Remove yaml-cli deprecation from the tools index

• Describes Majestic's CLI wrapper as persisting and applying changes. Contrasts it with the validating HTTP API without preferring either interface.

en/menu-index.md