OpenIPC · widgetii · Sep 5, 2026 · Sep 5, 2026
diff --git a/en/howto-tinycam-onvif.md b/en/howto-tinycam-onvif.md
@@ -62,9 +62,9 @@ Notes:
 - **Choose a strong password.** OpenIPC's published default web login is
   `root` / `123456`; do not leave a trivial password like that on a camera that
   is reachable from anywhere untrusted.
-- The HTTP API is the current method. The older `cli -s .onvif.password …` +
-  `killall -HUP majestic` approach still works but is
-  [documented as deprecated](majestic-streamer.md#changing-parameters-via-the-http-api).
+- From a shell on the camera, `cli -s .onvif.password …` does the same thing —
+  it applies the change itself, with no `killall` needed. See
+  [changing parameters](majestic-streamer.md#changing-parameters-via-the-http-api).
 
 ### tinyCam side
 

diff --git a/en/majestic-config.md b/en/majestic-config.md
@@ -9,6 +9,13 @@ change from the defaults, so a working file is usually much shorter than what
 follows — this page is a reference of what exists, not a file to paste whole.
 `/etc/majestic.full` on the camera is a shorter sample of the same thing.
 
+Majestic keeps it that way. When it saves the file — from the WebUI, the API, or
+after a `cli` write — it writes only the keys that differ from the defaults this
+build carries, so a value you never changed stays absent rather than being
+frozen at whatever the default happened to be when you last pressed Save. That
+is deliberate: it is what lets a default corrected in a later version reach a
+camera that has already been configured.
+
 Two ways to check a key against the build you are actually running, which beats
 trusting any wiki page:
 

diff --git a/en/majestic-plugins.md b/en/majestic-plugins.md
@@ -156,15 +156,15 @@ Where that falls in the startup sequence, and what does *not* re-trigger it:
 | Event | Plugin (re)loaded |
 |---|---|
 | Majestic start, after SDK init and encoder channel creation, just before the RTSP server | yes |
-| `killall -HUP majestic` (what the WebUI and `cli` use to apply a change) | yes |
-| A parameter set live through the HTTP API, such as `?video0.size=1920x1080` | no |
+| A reload that rebuilds the pipeline — `killall -HUP majestic`, or a change to a key that costs a rebuild, however it was made | yes |
+| A change Majestic applies in place, such as `?video0.bitrate=4096` or the same key through `cli` | no |
 
 So settings applied through the vendor's `/proc` interface, which a pipeline
 rebuild resets, can be re-applied from the constructor without any external
 timer. A live parameter change is applied in place by Majestic and does not pass
 through the plugin, so a knob that must follow the resolution has to be
-re-applied by whoever changes it — send the plugin command right after the API
-call that changed the setting.
+re-applied by whoever changes it — send the plugin command right after the write
+that changed the setting, whether that was an API call or `cli`.
 
 The one script hook Majestic has of its own is
 [`/usr/sbin/motion.sh`](majestic-streamer.md), run on a motion event.

diff --git a/en/majestic-streamer.md b/en/majestic-streamer.md
@@ -126,7 +126,7 @@ an isolated bench, not on a network.
 
 | Signal | What it does |
 |---|---|
-| `SIGHUP` | Re-read `/etc/majestic.yaml`, tear the media pipeline down and build it again. This is what `killall -HUP majestic` — and the WebUI, and `cli` — use to apply a change. Repeat signals within 3 seconds are ignored. |
+| `SIGHUP` | Re-read `/etc/majestic.yaml` and apply whatever changed, at the smallest cost that will carry it: most keys are pushed straight at the SDK with the stream untouched, some restart one subsystem or rebuild one encoder channel, and only the rest tear the pipeline down and build it again. This is what `cli` asks for after a write, and what `killall -HUP majestic` does by hand. Repeat signals within 3 seconds collapse into one reload. |
 | `SIGQUIT` | Release the SDK and the video memory with it, but keep the process running and answering. This is how `sysupgrade` frees RAM for a firmware download. A `SIGHUP` afterwards brings the pipeline back. |
 | `SIGINT`, `SIGTERM` | Release the SDK and exit. |
 | `SIGUSR2` | Start or end a SIP call — see [SIP](#sip) below. Only in builds with SIP, and only when `sip.enabled` is set. |
@@ -245,9 +245,20 @@ curl http://localhost/api/v1/config --data-binary @- <<'EOF'
 EOF
 ```
 
-> The older `cli` / `yaml-cli` utility (e.g. `cli -s .video0.fps 10 ; killall
-> -HUP majestic`) is deprecated. Prefer the HTTP API above, which applies the
-> change live and persists it for you.
+> `cli` does the same job from a shell on the camera, and no longer needs a
+> `killall` after it:
+>
+> ```
+> cli -s .video0.fps 10
+> ```
+>
+> It writes `/etc/majestic.yaml` and then asks Majestic to reload, so the change
+> applies at the same cost the API would charge for it. Use whichever suits the
+> job. `cli` is the one that works before Majestic is running — a `customizer.sh`
+> seeding a camera on first boot has no API to call — and it can write a key this
+> build does not declare. The API is the one that validates: `404` for a key the
+> binary does not have, `400` for a value outside its range, and it can be called
+> from another machine.
 
 ### Experimental Control Features (not yet described in endpoints)
 

diff --git a/en/menu-index.md b/en/menu-index.md
@@ -42,7 +42,7 @@ We would be grateful for any feedback and suggestions.
 ### Tools
 
 * [ipctool](https://github.com/openipc/ipctool) - Tool (and library) for checking IP camera hardware.
-* [yaml-cli][yaml-cli] - Tool for changing settings from the CLI (deprecated for Majestic; use the [HTTP API](majestic-streamer.md#changing-parameters-via-the-http-api) instead).
+* [yaml-cli][yaml-cli] - Tool for changing settings from the CLI. For Majestic, `cli` wraps it and asks Majestic to apply the change; the [HTTP API](majestic-streamer.md#changing-parameters-via-the-http-api) does the same over HTTP and validates the key.
 * [glutinium](https://github.com/ZigFisher/Glutinium) - Additional OpenWRT packages.
 
 ### Windows software