Bundle CLI ef95f12 and the wave-2 skill: uploaders, overlay triggers, skip, screen links, YouTube until

Merges the held skill commits of five lanes (uploaders and one-page
changes, overlay triggers, screenrig.skip(), screen links for browsers
without storage, advance.until video_end for YouTube pages), tightens
the SKILL.md wording (uploader scope detail moves to
references/playlists.md#change-one-page) and rebuilds the bundle from
cli ef95f12, which adds playlist page add|replace|remove, screen link
create|show|delete, triggers update|deliveries and overlay triggers,
uploader invitations and service clients, and the skip() runtime.

Budget before: repository 109 files, 3,431,988 bytes; plugins/screenrig
50 files, 2,396,469 bytes.
Budget after: repository 109 files, 3,478,944 bytes; plugins/screenrig
50 files, 2,439,526 bytes (cli/dist/bin.js 1,557,752 of 1,572,864 bytes).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Author: gersham

components.lock.json

@@ -3,10 +3,10 @@
   "state": "resolved",
   "cli": {
     "repository": "screenrig/cli",
-    "commit": "fac3cc2181cdf95df32807cfe16b52a2aeea93c4",
+    "commit": "ef95f123f2e4330340637ec3d73d9ab104bfa519",
     "artifact": {
       "file": "screenrig-cli.tgz",
-      "sha256": "764a1eb7b132411c5fbfad75a4c6b4395238f424d4e2f7f08dd8770feba7ccb9"
+      "sha256": "1991edc2b7654df1b1b4fe75bde91348cc4db9fc8189e6ce9498626b749296ee"
     }
   }
 }

plugins/screenrig/cli/dist/bin.js

@@ -86,6 +86,10 @@ never with `--json`. `screenrig status` reports service availability.
   separate `--config` (capabilities) or `login --no-wait --access manage`.
 - `screenrig dashboard open` opens the dashboard for the human;
   `invitations create --email ADDRESS` invites members.
+- An uploader (`invitations create --kind uploader` or `service-client create
+  --uploader`) works only in its folders and playlists (`media upload --folder
+  ID`, `playlist page add|replace|remove`); anything else is
+  `outside_upload_scope` ([one page](references/playlists.md#change-one-page)).
 
 ## Interactive views
 
@@ -116,7 +120,9 @@ instead of per-screen codes: its URL goes in a kiosk browser, in Android or
 Apple managed app configuration as `fleet_link` (`asset_id` names the screen),
 or in `/etc/screenrig/fleet-link` on Linux; `--expires-at` ends it. Its URL
 creates screens, so give it only to the person who configures the devices. A
-factory-reset Android 10+ device enrolls by QR code instead:
+browser that keeps no storage (vMix, OBS) opens the screen's own link
+(`screen link create SCREEN_ID`; rerunning it replaces the link). A
+factory-reset Android 10+ device enrolls by QR code:
 [Android device owner](references/android-device-owner.md).
 
 `screen archive` darkens a screen but keeps its playlist and binding. Before
@@ -155,8 +161,10 @@ screen is archived as `replaced`; delete it, never unarchive it.
 Prefer a card to an application: a card draws natively on every Player, changes
 with `card data put` without republishing, and suits a rotating loop. App code
 must `await screenrig.waitUntilActive()` before `await screenrig.ready()` and
-make no SDK call while `readyState` is not `active`. Use screenRIG's `feeds` for
-weather, rates and other third-party data, never the providers.
+make no SDK call while `readyState` is not `active`. An app with nothing to show
+calls `screenrig.skip()` instead of `ready()`: the screen moves on and counts no
+play. Use screenRIG's `feeds` for weather, rates and other third-party data,
+never the providers.
 
 `media upload` transcodes locally and needs `ffmpeg` and `ffprobe`; `doctor`
 names what is missing, so ask the user to install ffmpeg rather than installing
@@ -275,7 +283,7 @@ Reach for these when the task matches; `screenrig GROUP --help` has the rest.
 
 | Group | Reach for it when | First command |
 | --- | --- | --- |
-| `triggers` | An emergency notification system (CAP 1.2) must take screens over by itself | `triggers create --name NAME --tag TAG`, then `triggers test ID` (a 60-second alert on the screens); the URL and password go only to that system's administrator; `--pull FILE` also has the platform read CAP sources |
+| `triggers` | An emergency system (CAP 1.2), Home Assistant, a sensor or an alerting tool must show something on screens by itself | CAP: `triggers create --name NAME --tag TAG` (`--pull FILE` also reads CAP sources); any other sender: `triggers create --name NAME --kind overlay --show bar\|takeover --tag TAG` ([overlay triggers](references/playlists.md#overlay-triggers)); then `triggers test ID`. The URL and secret go only to the sender's administrator |
 | `notifications` | A person should hear when a screen goes offline or fails (email, chat, pager), or another system should react (signed webhook) | `notifications list` first: every project already emails its owner when a screen is offline 10 minutes. Then `notifications create --email owner --conditions screen_offline,display_disconnected`, or `--webhook URL` (verify `ScreenRig-Signature`; `data.secret` is shown once), `--slack URL`, `--teams URL`, `--pagerduty KEY`, `--telegram TOKEN --telegram-chat ID`; prove it with `notifications test ID` and `notifications deliveries ID`. Other conditions: `running_hot`, `storage_full`, `content_stuck`, `not_playing`, `loop_stalled`, `glass_blank`, `glass_frozen`, `crashing`; `--tag TAG`, `--hold MINUTES`, `update ID --snooze 1h`. Channels, grouping and glass verdicts: [notifications](references/notifications.md). `webhooks` remains for raw event feeds |
 | `alerts` | The user asks what needs attention on the screens, or named screens will be down for maintenance | `alerts list` shows the open problems, one per screen and condition (`--state all` adds resolved; `crashing` is a notice, not an alert). `alerts ack ID` when someone is on it, or `alerts snooze ID --for 4h` to look again later; either skips a notice still in its hold. For maintenance the user names, `alerts mute --tag TAG --for 2h --note TEXT` (or `--screen-id ID`; under 30 days) keeps those screens out of notices and attention; `alerts unmute MUTE_ID` (ids from `alerts mutes`) ends it when the work is done. Changing alerts needs Manage access |
 | `kv`, `kv webhook` | An application keeps live state that the agent or an outside sender sets; the app reads it with `screenrig.kv.get` and hears changes through `screenrig.kv.onChange` | `kv set KEY --app-id app_ID --json-value JSON`; for a sender such as a point of sale or cron job, `kv webhook create KEY --app-id app_ID` (the secret is shown once); a card's webhook: [card webhooks](references/playlists.md#card-webhooks) |

plugins/screenrig/skills/screenrig/SKILL.md

@@ -65,6 +65,29 @@ screenrig kv webhook deliveries kvw_ID --card crd_ID               # why each po
   five minutes. Secrets go to the sender's administrator, never into
   conversation, files or logs.
 
+## Overlay triggers
+
+Home Assistant, a sensor hub or an alerting tool shows words on screens with one
+HTTP POST: a bar over whatever plays, or a full-screen takeover.
+
+```sh
+screenrig triggers create --name "Lobby" --kind overlay --show bar --tag Lobby   # url and secret, shown once
+screenrig triggers test trg_ID           # one-minute test; triggers clear trg_ID ends it
+screenrig triggers deliveries trg_ID     # why each post was shown, ignored or refused
+```
+
+- The sender posts JSON with `Authorization: Bearer SECRET`: `alert_id`, `label`,
+  `title`, `message`, `note`, `duration` (`90s`, `10m`, `until_cleared`; default
+  10m) and `clear` or a `state` of `off`, `closed`, `resolved`. One `alert_id` is
+  one alert; the newest shows; each post holds its alert from now.
+- `--map FILE` builds the post from a tool's body (as card webhooks) and runs every
+  post through it, so leave it off for a sender that posts the members itself.
+  `--style FILE` sets theme and colours, `--signing` adds `ScreenRig-Signature`,
+  `triggers update` changes any of it. A wrong url, a wrong secret and any GET
+  answer the same 404; only `deliveries` says why. A clear is free. Secrets go
+  only to the sender's administrator.
+- Home Assistant example and the full request: <https://screenrig.ai/docs/cli#overlay-triggers>.
+
 ## Per-screen values
 
 Each screen carries its own `fields` (up to 32 lower-case names, values up to
@@ -101,6 +124,31 @@ Assigning it to a screen whose wall differs is refused
 aspect ratio within 4K, `content_fit: "fill"`, text off the seams):
 [video walls](https://screenrig.ai/docs/players.md#video-walls).
 
+## Change one page
+
+`playlist page add PLAYLIST_ID`, `page replace PLAYLIST_ID PAGE_ID` and `page
+remove PLAYLIST_ID PAGE_ID` change one page and leave the others as stored; the
+kept pages are validated again with the new one. `add --media MEDIA_ID` builds a
+full-canvas image or video page on the playlist's canvas (`--seconds`, `--fit`);
+`--file PAGE.json` takes any page. `add` puts the page at the end or in front of
+`--before PAGE_ID`; `replace --media` swaps the media and keeps the dates, and
+with neither `--media` nor `--file` only the dates change.
+
+`--from` and `--until` set the page's `visibility`: `YYYY-MM-DD` or
+`YYYY-MM-DDTHH:MM` in each screen's timezone, `--until` exclusive, and a
+date-only `--until` covers that whole day. `replace --always` removes the dates
+and keeps a switch-off or weekly windows the project set.
+
+Under Propose a page change is a review; your next page change of the same
+playlist joins your pending review, which also lets you replace or remove a page
+still waiting in it, and approving applies them together. Another proposer's
+pending page change makes yours wait (`resource_conflict`) until it is decided.
+
+An uploader changes pages only of its playlists, and its page is an image or
+video of its folders only (a stinger transition's logo included);
+`outside_upload_scope` carries `upload_scope`, what it may use. Invite one with
+`invitations create --kind uploader --folder-id ID --playlist-id ID`.
+
 ## Playlist rules that validation will enforce
 
 - A playlist is `name`, optional `audio`, and `pages`. A page has `id`, `canvas`
@@ -125,8 +173,14 @@ aspect ratio within 4K, `content_fit: "fill"`, text off the seams):
   `application`.
 - For YouTube, put the link the user gave (video, Shorts, live, playlist or
   `youtube.com/channel/UC…/live`) in an `iframe` `src`: the server stores an
-  autoplaying, looping embed without YouTube's controls. Native Players play
-  sound, the web Player plays muted; `mute=1` in the link mutes everywhere.
+  autoplaying, looping embed without YouTube's controls. Every Player plays it
+  with sound where the screen's browser allows sound (the Player web app mutes
+  it when the browser refuses); `mute=1` in the link mutes everywhere. For a
+  page that lasts as long as one video, set the page's advance to
+  `{"mode": "duration", "after_ms": N, "until": "video_end"}`: the page ends
+  when the video does, and `after_ms` is how long it shows when the screen
+  cannot read the video's length. A page with a playlist, a live stream or more
+  than one YouTube video rejects `until` at `advance.until`.
   A channel handle (`@name`) is rejected: ask for a video or channel-ID link.
 - For a Google Slides, Docs or Sheets file, or a PowerPoint, Word or Excel file
   on OneDrive or SharePoint, put the share link, Publish to web link or Embed

plugins/screenrig/skills/screenrig/references/playlists.md

@@ -86,11 +86,10 @@ never with `--json`. `screenrig status` reports service availability.
   separate `--config` (capabilities) or `login --no-wait --access manage`.
 - `screenrig dashboard open` opens the dashboard for the human;
   `invitations create --email ADDRESS` invites members.
-- An uploader (a person, or `service-client create --uploader`) works only in
-  its playlists and folders: `media upload --folder ID`, `playlist page
-  add|replace|remove`. Anything else is `outside_upload_scope`, whose
-  `upload_scope` lists what it may use. Set one up with `invitations create
-  --kind uploader`; see [playlists](references/playlists.md#change-one-page).
+- An uploader (`invitations create --kind uploader` or `service-client create
+  --uploader`) works only in its folders and playlists (`media upload --folder
+  ID`, `playlist page add|replace|remove`); anything else is
+  `outside_upload_scope` ([one page](references/playlists.md#change-one-page)).
 
 ## Interactive views
 
@@ -121,9 +120,9 @@ instead of per-screen codes: its URL goes in a kiosk browser, in Android or
 Apple managed app configuration as `fleet_link` (`asset_id` names the screen),
 or in `/etc/screenrig/fleet-link` on Linux; `--expires-at` ends it. Its URL
 creates screens, so give it only to the person who configures the devices. A
-browser that keeps no storage (vMix, OBS) opens the screen's link instead:
-`screen link create SCREEN_ID` prints it; creating it again replaces it. A
-factory-reset Android 10+ device enrolls by QR code instead:
+browser that keeps no storage (vMix, OBS) opens the screen's own link
+(`screen link create SCREEN_ID`; rerunning it replaces the link). A
+factory-reset Android 10+ device enrolls by QR code:
 [Android device owner](references/android-device-owner.md).
 
 `screen archive` darkens a screen but keeps its playlist and binding. Before
@@ -164,8 +163,8 @@ with `card data put` without republishing, and suits a rotating loop. App code
 must `await screenrig.waitUntilActive()` before `await screenrig.ready()` and
 make no SDK call while `readyState` is not `active`. An app with nothing to show
 calls `screenrig.skip()` instead of `ready()`: the screen moves on and counts no
-play. Use screenRIG's `feeds` for
-weather, rates and other third-party data, never the providers.
+play. Use screenRIG's `feeds` for weather, rates and other third-party data,
+never the providers.
 
 `media upload` transcodes locally and needs `ffmpeg` and `ffprobe`; `doctor`
 names what is missing, so ask the user to install ffmpeg rather than installing
@@ -284,7 +283,7 @@ Reach for these when the task matches; `screenrig GROUP --help` has the rest.
 
 | Group | Reach for it when | First command |
 | --- | --- | --- |
-| `triggers` | An emergency system (CAP 1.2), Home Assistant, a sensor or an alerting tool must show something on screens by itself | CAP: `triggers create --name NAME --tag TAG`; an overlay URL: `triggers create --name NAME --kind overlay --show bar --tag TAG` (a strip over whatever plays) or `--show takeover`; then `triggers test ID`; the URL and password go only to the sender ([overlay triggers](references/playlists.md#overlay-triggers)); `--pull FILE` also has the platform read CAP sources |
+| `triggers` | An emergency system (CAP 1.2), Home Assistant, a sensor or an alerting tool must show something on screens by itself | CAP: `triggers create --name NAME --tag TAG` (`--pull FILE` also reads CAP sources); any other sender: `triggers create --name NAME --kind overlay --show bar\|takeover --tag TAG` ([overlay triggers](references/playlists.md#overlay-triggers)); then `triggers test ID`. The URL and secret go only to the sender's administrator |
 | `notifications` | A person should hear when a screen goes offline or fails (email, chat, pager), or another system should react (signed webhook) | `notifications list` first: every project already emails its owner when a screen is offline 10 minutes. Then `notifications create --email owner --conditions screen_offline,display_disconnected`, or `--webhook URL` (verify `ScreenRig-Signature`; `data.secret` is shown once), `--slack URL`, `--teams URL`, `--pagerduty KEY`, `--telegram TOKEN --telegram-chat ID`; prove it with `notifications test ID` and `notifications deliveries ID`. Other conditions: `running_hot`, `storage_full`, `content_stuck`, `not_playing`, `loop_stalled`, `glass_blank`, `glass_frozen`, `crashing`; `--tag TAG`, `--hold MINUTES`, `update ID --snooze 1h`. Channels, grouping and glass verdicts: [notifications](references/notifications.md). `webhooks` remains for raw event feeds |
 | `alerts` | The user asks what needs attention on the screens, or named screens will be down for maintenance | `alerts list` shows the open problems, one per screen and condition (`--state all` adds resolved; `crashing` is a notice, not an alert). `alerts ack ID` when someone is on it, or `alerts snooze ID --for 4h` to look again later; either skips a notice still in its hold. For maintenance the user names, `alerts mute --tag TAG --for 2h --note TEXT` (or `--screen-id ID`; under 30 days) keeps those screens out of notices and attention; `alerts unmute MUTE_ID` (ids from `alerts mutes`) ends it when the work is done. Changing alerts needs Manage access |
 | `kv`, `kv webhook` | An application keeps live state that the agent or an outside sender sets; the app reads it with `screenrig.kv.get` and hears changes through `screenrig.kv.onChange` | `kv set KEY --app-id app_ID --json-value JSON`; for a sender such as a point of sale or cron job, `kv webhook create KEY --app-id app_ID` (the secret is shown once); a card's webhook: [card webhooks](references/playlists.md#card-webhooks) |

skills/screenrig/SKILL.md

@@ -83,8 +83,9 @@ screenrig triggers deliveries trg_ID     # why each post was shown, ignored or r
 - `--map FILE` builds the post from a tool's body (as card webhooks) and runs every
   post through it, so leave it off for a sender that posts the members itself.
   `--style FILE` sets theme and colours, `--signing` adds `ScreenRig-Signature`,
-  `triggers update` changes any of it. Wrong url, wrong secret and any GET answer the same 404; only
-  `deliveries` says why. A clear is free. Secrets go only to the sender's administrator.
+  `triggers update` changes any of it. A wrong url, a wrong secret and any GET
+  answer the same 404; only `deliveries` says why. A clear is free. Secrets go
+  only to the sender's administrator.
 - Home Assistant example and the full request: <https://screenrig.ai/docs/cli#overlay-triggers>.
 
 ## Per-screen values
@@ -142,8 +143,11 @@ Under Propose a page change is a review; your next page change of the same
 playlist joins your pending review, which also lets you replace or remove a page
 still waiting in it, and approving applies them together. Another proposer's
 pending page change makes yours wait (`resource_conflict`) until it is decided.
-An uploader's page is an image or video of its folders only (a stinger
-transition's logo included).
+
+An uploader changes pages only of its playlists, and its page is an image or
+video of its folders only (a stinger transition's logo included);
+`outside_upload_scope` carries `upload_scope`, what it may use. Invite one with
+`invitations create --kind uploader --folder-id ID --playlist-id ID`.
 
 ## Playlist rules that validation will enforce