@overcrow/mcp 0.1.3 → 0.1.5

package/dist/content/docs/en/guide.md

@@ -5,8 +5,8 @@ submission: create a project, edit its view, style and logic, run it in
 OverCrow, test it, package it and submit it. Each step links to the page
 that covers it in full.
 
-To work with an AI assistant instead, add OverCrow's MCP server to it: see
-[MCP](mcp.md).
+To work with an AI assistant instead, add PlayerVox OverCrow's MCP server to
+it: see [MCP](mcp.md).
 
 ## 1. Install the tools
 
@@ -15,7 +15,7 @@ To work with an AI assistant instead, add OverCrow's MCP server to it: see
 - **Node.js 22 or later** and npm, so that `check` can type-check your
   logic with the project's own TypeScript and the SDK from npm. The CLI checks and packages without it, but
   warns that types were not checked.
-- **OverCrow**, to run the widget while you write it.
+- **PlayerVox OverCrow**, to run the widget while you write it.
 
 `overcrow-widget doctor` tells what your setup has and lacks.
 
@@ -141,8 +141,8 @@ Provide both files or neither, with the same keys. See
 overcrow-widget check
 ```
 
-`check` runs the same validators as OverCrow: manifest, view, style,
-locales, a lint of the logic against what the VM runs, the project's
+`check` runs the same validators as PlayerVox OverCrow: manifest, view,
+style, locales, a lint of the logic against what the VM runs, the project's
 TypeScript, and a package built in memory and read back. Each problem has a
 stable code, a position and a help line; see
 [diagnostics](cli.md#diagnostics).
@@ -153,13 +153,13 @@ stable code, a position and a help line; see
 overcrow-widget dev
 ```
 
-`dev` sends the widget to the OverCrow overlay running on your machine and
-reloads it each time you save. OverCrow offers this only when it was
-started with development installs allowed (`OVERCROW_WIDGET_DEVELOPMENT=1`;
-`overcrow-widget doctor` prints the commands). The widget shows an
-**Unverified · development package** marker; its declared permissions are
-granted for the session only, and nothing is stored. `log.info(…)` from your
-logic prints in the terminal. See
+`dev` sends the widget to the PlayerVox OverCrow overlay running on your
+machine and reloads it each time you save. OverCrow offers this only when it
+was started with development installs allowed
+(`OVERCROW_WIDGET_DEVELOPMENT=1`; `overcrow-widget doctor` prints the
+commands). The widget shows an **Unverified · development package** marker;
+its declared permissions are granted for the session only, and nothing is
+stored. `log.info(…)` from your logic prints in the terminal. See
 [the development channel](dev-channel.md).
 
 ## 9. Test it
@@ -168,9 +168,9 @@ Two kinds of tests, both described in [testing a widget](testing.md):
 
 - unit tests of the logic with `@overcrow/sdk/testing`, which runs your
   module with virtual time and simulated services;
-- scenarios played by `overcrow-widget test` in OverCrow's headless
-  runtime: the real VM and renderer, services answered by fixtures, and
-  images compared with references.
+- scenarios played by `overcrow-widget test` in PlayerVox OverCrow's
+  headless runtime: the real VM and renderer, services answered by fixtures,
+  and images compared with references.
 
 <!-- source: templates/counter/tests/example.scenario.json -->
 ```json
@@ -241,7 +241,7 @@ locally stays unverified; users get widgets from the signed catalog. See
 
 Add a `listing.json` with the marketplace text and run the admission
 yourself. Widgets are no longer proposed by pull request: you will send
-yours from the OverCrow creator space when it opens.
+yours from the PlayerVox OverCrow creator space when it opens.
 
 ```sh
 overcrow-widget admit

package/dist/content/docs/en/index.md

@@ -6,8 +6,8 @@ its view in markup, style it with a small subset of CSS, and write its logic
 in TypeScript against `@overcrow/sdk`. The `overcrow-widget` command-line
 tool checks, tests and packages it; the signed catalog brings it to users.
 
-Every built-in widget of OverCrow is written this way, with the same public
-SDK, package format and sandbox as yours. Their sources are the
+Every built-in widget of PlayerVox OverCrow is written this way, with the
+same public SDK, package format and sandbox as yours. Their sources are the
 [reference widgets](widgets.md).
 
 ## What a widget is made of
@@ -52,18 +52,18 @@ export function increment(): void {
 
 - The logic runs in its own small JavaScript VM, in its own sandboxed
   process. It has no DOM, no file system, no network and no access to other
-  widgets; it reaches OverCrow only through the SDK.
+  widgets; it reaches PlayerVox OverCrow only through the SDK.
 - After each event, timer tick or service answer, the VM evaluates the view
-  again and sends OverCrow only what changed. OverCrow lays out and paints
-  the widget itself: no web engine is involved.
+  again and sends PlayerVox OverCrow only what changed. OverCrow lays out
+  and paints the widget itself: no web engine is involved.
 - Everything that reaches the outside (network, storage, clipboard, game
-  data) is a service of OverCrow, which checks the widget's declared and
-  consented permissions at each call. See
+  data) is a service of PlayerVox OverCrow, which checks the widget's
+  declared and consented permissions at each call. See
   [services and permissions](services.md).
 
-These pages call OverCrow **the host** when they describe what it does for a
-widget: the host draws the view, answers the services and keeps the user's
-data.
+These pages call PlayerVox OverCrow **the host** when they describe what it
+does for a widget: the host draws the view, answers the services and keeps
+the user's data.
 
 ## Where to start
 
@@ -74,8 +74,8 @@ data.
    [view](view.md), the [style](style.md), the [logic](logic.md),
    [services and permissions](services.md), [forms](forms.md).
 4. Use the tools: the [CLI](cli.md), [tests](testing.md) and the
-   [development channel](dev-channel.md) that runs your widget in OverCrow
-   while you write it.
+   [development channel](dev-channel.md) that runs your widget in
+   PlayerVox OverCrow while you write it.
 5. Look up an element, a style property, a service or an SDK function in the
    [reference](reference.md).
 6. Before you publish, read [the package](package.md),

package/dist/content/docs/en/limits.md

@@ -25,12 +25,13 @@ and a way out.
   `invalid_request`, a full quota with `quota_exceeded`, and too many
   requests at once with `busy`. See [errors](services.md#errors).
 - **While the logic runs**, exceeding a budget of the VM (the time of a
-  turn, the heap, the messages of a turn) stops the widget; OverCrow
-  restarts it a few times. See
+  turn, the heap, the messages of a turn) stops the widget;
+  PlayerVox OverCrow restarts it a few times. See
   [what happens on a failure](logic.md#what-happens-on-a-failure).
 - **In what the widget shows**, a value out of bounds (a text too long for
-  an attribute, too many nodes) is refused by OverCrow and stops the widget
-  too: bound what you show, for example the number of rows of a list.
+  an attribute, too many nodes) is refused by PlayerVox OverCrow and stops
+  the widget too: bound what you show, for example the number of rows of a
+  list.
 
 Lengths are logical pixels at 100 % content scale. Text limits count UTF-8
 bytes unless the unit says characters. KiB and MiB are 1024 and 1024²

package/dist/content/docs/en/logic.md

@@ -39,13 +39,13 @@ that the view calls with `on:activate={increment}`.
   no DOM, `window`, `fetch`, `setTimeout`, `console`, `Intl` or
   `require`. The standard ECMAScript objects are there (`Math`, `JSON`,
   `Date`, `Map`, `Promise`…), and the SDK is the only way out.
-- Everything after that happens in **turns**. OverCrow sends an event, a
-  timer tick, a service answer or a change of its own data; your code runs;
-  then the VM evaluates the view again and sends OverCrow only what
-  changed. You never update the view by hand.
+- Everything after that happens in **turns**. PlayerVox OverCrow sends an
+  event, a timer tick, a service answer or a change of its own data; your
+  code runs; then the VM evaluates the view again and sends OverCrow only
+  what changed. You never update the view by hand.
 - A turn has a time budget, and the VM a memory ceiling. A widget that
-  exceeds one is stopped and restarted by OverCrow, a few times; see
-  [what happens on a failure](#what-happens-on-a-failure).
+  exceeds one is stopped and restarted by PlayerVox OverCrow, a few times;
+  see [what happens on a failure](#what-happens-on-a-failure).
 
 The only import a logic module may have is `@overcrow/sdk`. Everything else
 it needs is in the module itself.
@@ -135,8 +135,8 @@ its own.
 
 ## Data from OverCrow: `host`
 
-`host` holds what OverCrow knows about the user and the widget. Its members
-always read the latest value.
+`host` holds what PlayerVox OverCrow knows about the user and the widget.
+Its members always read the latest value.
 
 | Member | Value |
 | --- | --- |
@@ -151,11 +151,11 @@ always read the latest value.
 | `host.grants` | The capabilities the user granted; read it with `hasGrant`. |
 | `host.messages` | The messages of the active language; read them with `t`. |
 
-`onHost(listener)` calls your listener when OverCrow sends new values, with
-the names of the members that changed, before the view is evaluated again.
-Use it when a change needs more than showing the new value: re-arm a timer,
-subscribe again, redraw a canvas. A member may be sent again with the same
-value: compare it with the one you kept when that matters.
+`onHost(listener)` calls your listener when PlayerVox OverCrow sends new
+values, with the names of the members that changed, before the view is
+evaluated again. Use it when a change needs more than showing the new value:
+re-arm a timer, subscribe again, redraw a canvas. A member may be sent again
+with the same value: compare it with the one you kept when that matters.
 
 <!-- source: widgets/stopwatch/logic.ts -->
 ```ts
@@ -173,7 +173,7 @@ through the widget to the game, so the stopwatch hides its buttons unless
 ## The options menu
 
 The rows declared in `wrapper.menu` of the [manifest](manifest.md#the-options-menu)
-are drawn and stored by OverCrow. The logic reads them:
+are drawn and stored by PlayerVox OverCrow. The logic reads them:
 
 - `option(id, fallback)` returns the stored value of a toggle, slider or
   choice row, or `fallback` when there is none or it has another type;
@@ -207,7 +207,7 @@ service: an `action` row can change the state, not write to the clipboard.
 
 ## Timers
 
-There is no `setTimeout`. Timers are OverCrow's, through `timers`:
+There is no `setTimeout`. Timers are PlayerVox OverCrow's, through `timers`:
 
 | Function | Calls back |
 | --- | --- |
@@ -225,7 +225,7 @@ timers.every(1000, () => {
 });
 ```
 
-Three rules follow from OverCrow owning the timers:
+Three rules follow from PlayerVox OverCrow owning the timers:
 
 - **No timer shorter than 100 ms.** A shorter interval is raised to it.
   Motion belongs to the [style](style.md#transitions-and-animations), not to
@@ -270,8 +270,8 @@ function start(): void {
 ```
 
 A duration that only has to advance on screen needs no timer at all: the
-`elapsed` element is advanced by OverCrow from a starting point the logic
-gives it. See the [`elapsed` element](elements.md#elapsed).
+`elapsed` element is advanced by PlayerVox OverCrow from a starting point
+the logic gives it. See the [`elapsed` element](elements.md#elapsed).
 
 ## Time, dates and numbers
 
@@ -339,11 +339,11 @@ export function toggleLabel(running: boolean): string {
 }
 ```
 
-When the user changes OverCrow's language, the view is evaluated again
-with the new messages. A text that the logic computed and stored in the
-state is not: compute texts in functions the view calls, or refresh them in
-`onHost` when `"locale"` changes. The widget's name and its menu labels are
-in the manifest, not in the locales.
+When the user changes PlayerVox OverCrow's language, the view is evaluated
+again with the new messages. A text that the logic computed and stored in
+the state is not: compute texts in functions the view calls, or refresh them
+in `onHost` when `"locale"` changes. The widget's name and its menu labels
+are in the manifest, not in the locales.
 
 `overcrow-widget check` warns when the view calls `t("key")` with a key
 that has no message, and refuses two files whose keys differ.
@@ -368,8 +368,8 @@ function paint(): void {
 ```
 
 Coordinates are logical pixels from the top-left corner of the canvas;
-colours are literal (`#rrggbb`) or colour tokens. OverCrow checks every
-command and draws them itself: there is no pixel access and no shader.
+colours are literal (`#rrggbb`) or colour tokens. PlayerVox OverCrow checks
+every command and draws them itself: there is no pixel access and no shader.
 Draw again when what you show changes, and when `host.theme` changes if you
 use literal colours.
 
@@ -430,15 +430,17 @@ the SDK replacement:
 | `logic.debugger` | `debugger` is a warning. |
 
 The lint helps you; it is not what protects the user. The sandbox, the
-VM's budgets and OverCrow's check of everything the widget sends do that.
+VM's budgets and PlayerVox OverCrow's check of everything the widget sends
+do that.
 
 ## What happens on a failure
 
 - An exception in a handler ends that turn; the widget keeps running, and
   `overcrow-widget dev` shows the fault.
 - A turn longer than its budget (50 ms), a heap over its ceiling or too
-  many messages in a turn stop the widget. OverCrow shows a fixed error in
-  its frame and restarts it after 1, 5 and 15 seconds, at most three times.
+  many messages in a turn stop the widget. PlayerVox OverCrow shows a fixed
+  error in its frame and restarts it after 1, 5 and 15 seconds, at most
+  three times.
 - A rejected promise of a service call is an ordinary error of your code:
   catch it. See [errors](services.md#errors).
 

package/dist/content/docs/en/manifest.md

@@ -7,7 +7,7 @@ it by hand; it is packaged exactly as written.
 
 The file is one strict JSON object. A byte-order mark, a duplicate key,
 trailing data or an unknown field rejects it: there is no field that
-OverCrow ignores.
+PlayerVox OverCrow ignores.
 
 ## A complete example
 
@@ -93,20 +93,21 @@ values it fills in. A manifest with permissions and a menu:
 
 - **`id`** is the widget's identity everywhere: in the catalog, in the
   user's profile, in its storage. It is `<handle>.<name>`, your publisher
-  handle in the OverCrow creator space and a name (`nova.lol-timers`), or,
-  once you verified a domain, that domain reversed and a name
-  (`gg.nova.lol-timers`). An ID is final: it is never given to another
-  widget, even after yours is removed. `nova`, `example`, `yourhandle` and
-  `yourname` are example handles that nobody can publish under, and IDs
-  under `com.playervox` are reserved for widgets published by PlayerVox.
+  handle in the PlayerVox OverCrow creator space and a name
+  (`nova.lol-timers`), or, once you verified a domain, that domain reversed
+  and a name (`gg.nova.lol-timers`). An ID is final: it is never given to
+  another widget, even after yours is removed. `nova`, `example`,
+  `yourhandle` and `yourname` are example handles that nobody can publish
+  under, and IDs under `com.playervox` are reserved for widgets published by
+  PlayerVox.
 - **`version`** is a semantic version. A published version never changes:
   any change to a published widget is a new, higher version.
 - **`schemaVersion`** and **`apiVersion`** are both `1`.
 
 ### Names
 
-`name` gives the name OverCrow shows in its widget list and menus, in
-English and in French. Both are required. A name shows as written: no
+`name` gives the name PlayerVox OverCrow shows in its widget list and menus,
+in English and in French. Both are required. A name shows as written: no
 control character and no invisible or text-direction character, such as
 U+200B (zero-width space) or U+202E (right-to-left override). Menu labels
 follow the same rule.
@@ -121,9 +122,9 @@ follow the same rule.
 ## Sizes
 
 `sizing` says how large the widget is when the user adds it, how small and
-how large the user may resize it, and whether OverCrow can fit its frame to
-its content. Lengths are logical pixels at 100 % scale; the user's content
-scale (50 % to 175 %) multiplies them.
+how large the user may resize it, and whether PlayerVox OverCrow can fit its
+frame to its content. Lengths are logical pixels at 100 % scale; the user's
+content scale (50 % to 175 %) multiplies them.
 
 <!-- generated:manifest-sizing -->
 | Field | Type | Required | Meaning |
@@ -145,11 +146,11 @@ Each of `preferred`, `min` and `max` is a pair of dimensions, with
 | `height` | integer 1 to 4096 | yes | Logical pixels. |
 <!-- /generated:manifest-dimensions -->
 
-With `fit: "both"`, OverCrow sizes the frame to what the view needs, in
-both directions: the Clock grows when the user turns the seconds on. With
-`fit: "height"`, the user chooses the width and the height follows the
-content. With `fit: "none"`, the frame keeps the size the user gave it and
-the view fills it. The user can always resize by hand.
+With `fit: "both"`, PlayerVox OverCrow sizes the frame to what the view
+needs, in both directions: the Clock grows when the user turns the seconds
+on. With `fit: "height"`, the user chooses the width and the height follows
+the content. With `fit: "none"`, the frame keeps the size the user gave it
+and the view fills it. The user can always resize by hand.
 
 <!-- source: widgets/clock/manifest.json -->
 ```json
@@ -190,9 +191,9 @@ A network rule is an object of its own; its fields are described with
 
 ## The options menu
 
-Every widget has an options menu, opened from its frame. OverCrow puts its
-own rows first: opacity, content size, fit to content and, when the widget
-needs one, its account. Visibility in Passive mode is the eye in the
+Every widget has an options menu, opened from its frame. PlayerVox OverCrow
+puts its own rows first: opacity, content size, fit to content and, when the
+widget needs one, its account. Visibility in Passive mode is the eye in the
 widget's toolbar, not a menu row. `wrapper.menu` adds yours below them:
 toggles, sliders, choices, actions and groups, each with a label in both
 languages.
@@ -233,8 +234,8 @@ current value on at most 120 points. Keep labels short, in both languages.
   }
 ```
 
-OverCrow draws the rows, stores their values in the user's profile and
-gives them to the logic: read a value with `option(id, fallback)`, and
+PlayerVox OverCrow draws the rows, stores their values in the user's profile
+and gives them to the logic: read a value with `option(id, fallback)`, and
 follow changes with `onHost`. An `action` row has no value: it calls the
 handler you registered with `onMenu`. See
 [the options menu in the logic](logic.md#the-options-menu).
@@ -346,10 +347,11 @@ Each entry of `choices` is a value and its label:
 
 `requires` at the top level lists data sources the widget cannot work
 without, with the same names as a row's `requires`. On a machine that lacks
-one, OverCrow neither starts nor shows the widget and keeps its place in the
-layout; the widget comes back when the source does. Use it for a widget
-that has nothing to show otherwise, such as a frame-rate counter without a
-frame-rate source. For a single optional value, prefer a row's `requires`.
+one, PlayerVox OverCrow neither starts nor shows the widget and keeps its
+place in the layout; the widget comes back when the source does. Use it for
+a widget that has nothing to show otherwise, such as a frame-rate counter
+without a frame-rate source. For a single optional value, prefer a row's
+`requires`.
 
 ## A larger memory budget
 
@@ -368,8 +370,8 @@ leaves less room for everything else. Ask for it only when
 
 ## How the manifest is checked
 
-`overcrow-widget check` validates the manifest with the validator OverCrow
-itself runs, and points at the member it refuses:
+`overcrow-widget check` validates the manifest with the validator
+PlayerVox OverCrow itself runs, and points at the member it refuses:
 
 ```text
 error[manifest.sizing]: `sizing` is out of bounds or inconsistent
@@ -381,8 +383,8 @@ error[manifest.sizing]: `sizing` is out of bounds or inconsistent
 check: 1 error(s), 0 warning(s)
 ```
 
-OverCrow validates it again when the package is admitted to the catalog,
-when it is installed and each time the widget starts. A new version whose
-manifest asks for more than the previous one (a network rule, a game event,
-a capability, storage or the clipboard) waits until the user approves it
-in the Control Center before it replaces the installed version.
+PlayerVox OverCrow validates it again when the package is admitted to the
+catalog, when it is installed and each time the widget starts. A new version
+whose manifest asks for more than the previous one (a network rule, a game
+event, a capability, storage or the clipboard) waits until the user approves
+it in the Control Center before it replaces the installed version.

package/dist/content/docs/en/mcp.md

@@ -10,7 +10,7 @@ server installs the OverCrow tools it needs by itself.
 claude mcp add overcrow -- npx -y @overcrow/mcp
 ```
 
-Then ask: "Create an OverCrow widget that shows…".
+Then ask: "Create a PlayerVox OverCrow widget that shows…".
 
 ## Add the server
 
@@ -85,9 +85,9 @@ Developer, Edit Config), then restart Claude Desktop.
 
 ## What the server does
 
-- **The first time**, it downloads the OverCrow creator tools of your
-  computer (the [command-line tool](cli.md) and the runtime that plays the
-  [tests](testing.md), about 15 MB) from OverCrow's GitHub release. It
+- **The first time**, it downloads the PlayerVox OverCrow creator tools of
+  your computer (the [command-line tool](cli.md) and the runtime that plays
+  the [tests](testing.md), about 15 MB) from OverCrow's GitHub release. It
   checks every file against the digests written in the server, then keeps
   them in its own folder (`~/.cache/overcrow-mcp`, or
   `%LOCALAPPDATA%\overcrow-mcp` on Windows). Nothing goes on your `PATH`,
@@ -97,7 +97,7 @@ Developer, Edit Config), then restart Claude Desktop.
   (it sees the images that differ), audit, package, prepare the
   submission.
 - **The widget ID** is final. Your assistant asks you for it: your
-  publisher handle in the OverCrow creator space and a name
+  publisher handle in the PlayerVox OverCrow creator space and a name
   (`nova.lol-timers`), or a domain you can verify
   (`gg.nova.lol-timers`).
 - **The submission**: the server checks everything the creator space asks
@@ -119,9 +119,9 @@ Developer, Edit Config), then restart Claude Desktop.
 ## What it does not do
 
 - It never sends, signs or publishes anything. You send the ZIP and the
-  texts in the OverCrow creator space, at creators.playervox.com.
-- It does not install your widget in OverCrow: trying it in a game is the
-  [development channel](dev-channel.md) of the command-line tool.
+  texts in the PlayerVox OverCrow creator space, at creators.playervox.com.
+- It does not install your widget in PlayerVox OverCrow: trying it in a game
+  is the [development channel](dev-channel.md) of the command-line tool.
 - It sends nothing about you: no telemetry, no account.
 
 ## Security
@@ -129,7 +129,7 @@ Developer, Edit Config), then restart Claude Desktop.
 - **Your folders only.** The server works in the folder open in your
   assistant (or the ones given with `--root`). It refuses a system folder,
   your whole home folder, hidden folders, and links that lead outside.
-- **No command of its own choice.** The server runs the OverCrow
+- **No command of its own choice.** The server runs the PlayerVox OverCrow
   command-line tool and npm, nothing else, never through a shell.
 - **Checked downloads.** It downloads only the pinned files from GitHub,
   and checks them before use. npm installs only `@overcrow/sdk` and
@@ -145,10 +145,10 @@ Developer, Edit Config), then restart Claude Desktop.
 ## Offline
 
 Download `overcrow-creator-tools-VERSION-PLATFORM.zip` of your platform
-from OverCrow's GitHub release once, put it in your widgets folder, and ask
-your assistant to run `setup` with it (`zipPath`). Or start the server with
-`--tools-zip` and the path of the file. The file must be exactly the one
-the server pins.
+from PlayerVox OverCrow's GitHub release once, put it in your widgets
+folder, and ask your assistant to run `setup` with it (`zipPath`). Or start
+the server with `--tools-zip` and the path of the file. The file must be
+exactly the one the server pins.
 
 ## Supported computers
 

package/dist/content/docs/en/package.md

@@ -61,8 +61,8 @@ names. Two consequences:
 - the view itself carries no code: `view.json` refers to the functions of
   `logic.js` by number.
 
-A package holds source that OverCrow can read and check, never compiled
-bytecode.
+A package holds source that PlayerVox OverCrow can read and check, never
+compiled bytecode.
 
 ## The same bytes every time
 
@@ -79,14 +79,14 @@ package` to write it; an archive made with another zip tool is refused.
 ## The ledger
 
 `ledger.json`, written by the tool, lists every other file with its size
-and its SHA-256. OverCrow recomputes it from the archive and requires the
-same bytes. It is what ties each file to the package: a file changed,
-added or removed after packaging no longer matches.
+and its SHA-256. PlayerVox OverCrow recomputes it from the archive and
+requires the same bytes. It is what ties each file to the package: a file
+changed, added or removed after packaging no longer matches.
 
 ## How OverCrow checks a package
 
-OverCrow validates a package in full when it is admitted to the catalog,
-when it is installed, and again **each time the widget starts**:
+PlayerVox OverCrow validates a package in full when it is admitted to the
+catalog, when it is installed, and again **each time the widget starts**:
 
 1. the size of the archive, its exact layout and the checksum of each
    entry;

package/dist/content/docs/en/publish-keys.md

@@ -48,10 +48,11 @@ workflow submits the widget on every version tag:
 
 <!-- source: docs/content/examples/weather/.github/workflows/submit.yml -->
 ```yaml
-# Sends the widget to the OverCrow creator space when a version tag is
-# pushed. The publish key is a secret of the repository, and the OverCrow
-# release whose creator tools to use is a variable of the repository.
-name: Submit to OverCrow
+# Sends the widget to the PlayerVox OverCrow creator space when a version
+# tag is pushed. The publish key is a secret of the repository, and the
+# OverCrow release whose creator tools to use is a variable of the
+# repository.
+name: Submit to PlayerVox OverCrow
 
 on:
   push:
@@ -76,7 +77,7 @@ jobs:
           (cd "$tools" && sha256sum --check --quiet SHA256SUMS)
           install -D -m 755 "$tools"/overcrow-widget-*-linux-x86_64 "$HOME/.local/bin/overcrow-widget"
           echo "$HOME/.local/bin" >> "$GITHUB_PATH"
-      - name: Submit to OverCrow
+      - name: Submit to PlayerVox OverCrow
         run: overcrow-widget submit --submission submission.json
         env:
           OVERCROW_PUBLISH_KEY: ${{ secrets.OVERCROW_PUBLISH_KEY }}

package/dist/content/docs/en/publishing.md

@@ -1,9 +1,9 @@
 # Publishing and review
 
 > **Pull requests are closed.** Widgets are no longer proposed by pull
-> request: PlayerVox's own widgets already go through the OverCrow creator
-> space, and yours will when it opens. Until then, this page describes the
-> admission, the review and the catalog a widget goes through.
+> request: PlayerVox's own widgets already go through the PlayerVox OverCrow
+> creator space, and yours will when it opens. Until then, this page
+> describes the admission, the review and the catalog a widget goes through.
 
 Widgets reach PlayerVox OverCrow users through the signed widget catalog:
 OverCrow installs only what that catalog lists. This page goes from a
@@ -86,7 +86,7 @@ overcrow-widget admit widgets/<dir> --format json
 your code or `tsc`:
 
 1. it builds the directory as `package` does: every source, style, logic
-   and package check, then OverCrow's own package reader;
+   and package check, then PlayerVox OverCrow's own package reader;
 2. with `--package`, your archive's compiled view must be byte for byte
    what `view.ocml` compiles to;
 3. it checks the schema bounds, the reserved IDs, `listing.json`, the
@@ -135,14 +135,15 @@ outside CI with the catalog key, whose public half is in
 - lists each version with the SHA-256 and the size of its package; a
   published version never changes, and a change is a new version;
 - carries a strictly increasing sequence number and expires after at most
-  90 days: OverCrow refuses an older sequence and an expired catalog;
+  90 days: PlayerVox OverCrow refuses an older sequence and an expired
+  catalog;
 - tags PlayerVox reference widgets `built-in` (only `com.playervox.*` IDs):
   they are installed on a new profile with their declared permissions
   granted, except for an update that asks for more.
 
-OverCrow verifies the signature, the package digest, its ledger and its
-compiled view before installing, and again each time it starts the widget.
-See [the package](package.md#how-overcrow-checks-a-package).
+PlayerVox OverCrow verifies the signature, the package digest, its ledger
+and its compiled view before installing, and again each time it starts the
+widget. See [the package](package.md#how-overcrow-checks-a-package).
 
 ## Updates
 

package/dist/content/docs/en/reference.md

@@ -26,9 +26,9 @@ together; the pages below are the ones to keep open while you write.
 
 - The tables of elements, attributes, style properties, tokens, services,
   result shapes and limits are **generated from the widget schema**, the
-  same tables that OverCrow and the command-line tool compile into their
-  validators. A check fails when a page differs from the schema, in English
-  or in French.
+  same tables that PlayerVox OverCrow and the command-line tool compile into
+  their validators. A check fails when a page differs from the schema, in
+  English or in French.
 - The **SDK types** are generated from the same schema, so a wrong element,
   icon, capability or service parameter is a TypeScript error in your
   logic.
@@ -48,8 +48,8 @@ These pages describe widget API v1 (`"apiVersion": 1` in the manifest) and
 Three specifications, in the public repository, are written for those who
 implement a host or another tool rather than a widget: the complete
 [generated schema reference](../../widget-schema-v1.md), which also covers
-the protocol between OverCrow and the widget's process and the catalog's
-payloads; the
+the protocol between PlayerVox OverCrow and the widget's process and the
+catalog's payloads; the
 [wire protocol of the development channel](../../dev-channel.md); and the
 [archive and catalog format](../../widget-package-v1.md). A widget author
 does not need them.

package/dist/content/docs/en/result-shapes.md

@@ -36,9 +36,9 @@ the view reads its members:
 - A member that goes with `offsetMinutes` is a timestamp to format with
   that UTC offset; see
   [time, dates and numbers](logic.md#time-dates-and-numbers).
-- An `asset:` handle is an image that OverCrow holds for the widget: bind
-  it to the `src` of an `image` or an `avatar`, or draw it on a canvas. It
-  is not a URL and cannot be read as bytes.
+- An `asset:` handle is an image that PlayerVox OverCrow holds for the
+  widget: bind it to the `src` of an `image` or an `avatar`, or draw it on a
+  canvas. It is not a URL and cannot be read as bytes.
 - A subscription whose shape is "… or `null`" delivers `null` when there is
   nothing to show: no active game, no media player.