@skillcdn/console 0.1.23 → 0.3.0

package/docs/specs/cli.md

@@ -24,10 +24,10 @@ The board is a project's ([ADR-0008](../adr/0008-a-workspace-holds-projects-and-
 | `login --url <origin> [--agent <name>] [--token-stdin] [--default]` | `POST /api/v1/connect`, then `POST /api/v1/connect/claim` until a person approved, then `GET /api/v1/me` with the token; `DELETE /api/v1/me/token` with the token a repeated login replaces | the address and the code for a person; then who the token is, and whether this is the default console; keeps the login |
 | `logins` | nothing | one line per login: the console, the account, what the token is called, since when, and which is the default; never a token |
 | `logout [--url <origin>] [--account <login>]` | `DELETE /api/v1/me/token` | that the login's token is given up and forgotten, or that the console was out of reach and the token is left to the Agents page |
-| `whoami` | `GET /api/v1/me` | the login, the role, the workspace, the address, and the project this directory works in; with a project, where the organization's rules and the skill working-the-board are read; then the command's version and where it is installed, the console's version and the range it takes, and the update to make when they differ |
+| `whoami` | `GET /api/v1/me` | the login, the role, the workspace, the address, and the project this directory works in; with a project, where the organization's rules are read and where the skill working-the-board is on this machine; then the command's version and where it is installed, the console's version and the range it takes, and the update to make when they differ |
 | `projects` | `GET /api/v1/projects` | one line per project: key, name, what the person is in it, what waits in it |
 | `use <key> [--url <origin>] [--account <login>]` | `GET /api/v1/projects/<key>` | that the directory works in the project from now on, at which console and as which account where it binds them, and that `console rules` says what its people ask; writes `.skillcdn-console.json` |
-| `work [--person <login>]` | `GET /api/v1/work`, `GET /api/v1/people/<id>/work` | what is on the person's plate across their projects: the open tasks assigned to them, the sooner due first, each with its project; and the decisions waiting. `--person` shows another person's plate, for an administrator or an owner of a project they are in: their open tasks within the projects the asker may see, without the decisions. Needs no project |
+| `work [--person <login>]` | `GET /api/v1/work`, `GET /api/v1/people/<id>/work` | what is on the person's plate across their projects: the open tasks assigned to them, the sooner due first, each with its project; and the decisions waiting. `--person` shows another person's plate, for an administrator or an owner of a project they are in: their open tasks within the projects the asker may see, without the decisions. The tasks done or dropped lately, which the answer carries as `closed` for the week on the plate's page, are in `--json` only. Needs no project |
 | `tasks [--state <state>] [--open] [--mine] [--category <key>] [--goal <id>] [--due <day\|today\|week\|overdue>] [--unassigned] [--archived] [--limit <n>] [--offset <n>]` | `GET .../tasks` with the filters and the page (`--mine` and `--unassigned` not together) | one line per task: number, state, priority, title, owner, assignee, category, due day, what waits on it, and whether it is put away; the tasks put away are left out unless `--archived` asks for them alone; a page at a time |
 | `task <number\|id>` | `GET .../tasks/<ref>`, the decisions about it, the runs on it, `GET .../tasks/<id>/comments` | the task in full, with its plan and its moments, and the discussion on it: each comment whole, with its files and the command that reads each |
 | `task new <title> [--body <markdown>\|--file <path>] [--state <state>] [--priority <priority>] [--category <key>] [--goal <id>] [--starts <day>] [--due <day>] [--assignee <login\|me>] [--parent <number\|id>]` | `POST .../tasks` | the number and the id |
@@ -52,26 +52,26 @@ The board is a project's ([ADR-0008](../adr/0008-a-workspace-holds-projects-and-
 | `members` | `GET .../members` | one line per member: login, role, since when |
 | `member add <login> [--role owner\|member] [--project <key>[,<key>...]]`, `member role <login> <owner\|member>`, `member remove <login>` | `GET /api/v1/people` for the id, then `POST .../members` (once per project when `--project` names several with commas), `PATCH .../members/<id>`, `DELETE .../members/<id>` | the member as they are now, or that they are no longer listed; with several projects, one line per project, a person listed already said so; for an owner |
 | `category new <key> <name> [--color <name>]`, `category edit <key> [--name <name>] [--color <name>]`, `category remove <key>` | `POST /api/v1/categories`, `PATCH .../categories/<key>`, `DELETE .../categories/<key>` | the category as it is now, or that it is gone; for an administrator |
-| `skills`, `skills <folder>`, `skills --search <words> [<folder>] [--limit <n>]` | `GET .../skills`; `GET .../skills/browse?path=&cursor=`, page after page to the end; `GET .../skills/find?query=&path=&limit=`, one page | the project's pack, or the organization's: the pack by name with how many skills and documents it has, and each skill with its description, the path `skill` reads it by and the URI an agent loads it by through its own SkillCDN connection; or why there are none to show; where a person connects an agent that has no connection to the address, and where the console's own skills are on this machine, when the command knows. With a folder (`.` for the root; `/` is taken too, but a Windows shell rewrites it into a path before the command sees it), what it holds as `browse_repo` lays it out: its skills, its folders with what each holds and the README that introduces it, its files. With `--search`, what the words find as `search_repo` does, in relevance order, a skill with the files of it that matched, within the folder when one is named, ten unless `--limit` says otherwise (up to 25), and a last line when more matched |
-| `skill <path>`, `skill --file <path>` | `GET .../skills/one?path=&cursor=`, page after page until `complete`; with `--file`, `GET .../skills/file?path=&offset=` until the end | the skill whole, as `load_skill` lays it out: the rules of the repository from its root to the nearest manifest, the body and the included files, each under a line that names its path, then the files it has and what it refers to; or the file whole, or what a folder holds; a private pack through the pack token the project holds ([ADR-0028](../adr/0028-the-console-reads-a-projects-pack-through-the-deployments-rest-api-with-a-pack-token-for-a-private-one.md)). `--file` takes no skill's path beside it: the two given together are not understood |
+| `skills`, `skills <folder>`, `skills --search <words> [<folder>] [--limit <n>] [--cursor <cursor>]` | `GET .../skills`; `GET .../skills/browse?path=&cursor=`, page after page to the end; `GET .../skills/find?query=&path=&cursor=&limit=`, one page | the project's pack, or the organization's ([ADR-0031](../adr/0031-the-console-reads-a-pack-as-the-skillcdn-command-does-and-a-local-one-from-a-directory.md)): where it is, at a deployment or on the console's machine, and how the read went; what a client is told of it on connect, as the deployment tells one, with the reads named as the console's commands; every skill with the path of its `SKILL.md` and every document, as a search without words lists them; where a person connects an agent of its own, and where the console's own skills are on this machine. With a folder (`.` for the root; `/` is taken too, but a Windows shell rewrites it into a path before the command sees it), what it holds, whole, as `browse_repo` lays it out for a model. With `--search`, one page of what the words find, as `search_repo` does: skills first with the files of theirs that matched, then documents, in relevance order, within the folder when one is named, ten unless `--limit` says otherwise (up to 25), and a `nextCursor` line when more matched, which `--cursor` continues. `--json` is the console's answer: what the pack answered, in the shapes of the main repository's REST API, the pages of a folder joined |
+| `skill <path>`, `skill --file <path>` | `GET .../skills`, then `GET .../skills/one?path=&cursor=`, page after page until `complete`; with `--file`, `GET .../skills/file?path=&offset=` until the end | the skill whole, as `load_skill` lays it out for a model: the rules of the repository from its root to the nearest manifest, the instructions, the included files, then its supporting files and what it refers to, rendered by the main repository's own renderers with the reads named as the console's commands; or the file whole, or what a folder holds; a private pack through the pack token the project holds ([ADR-0028](../adr/0028-the-console-reads-a-projects-pack-through-the-deployments-rest-api-with-a-pack-token-for-a-private-one.md)). `<path>` is the path of the SKILL.md from the repository's root, or the URI the pack names it by (`skill://<host>/<owner>/<name>/<path>`); a URI of another pack is not understood. `--file` takes no skill's path beside it: the two given together are not understood. A read the pack refused prints its status and the pack's own words, and exits with `0` |
 | `rules` | `GET .../rules`, or `GET /api/v1/rules` without a project named, and `GET /api/v1/me` | the rules that hold, as they read for the person (`{language}` is the language they chose, or the task's) ([ADR-0023](../adr/0023-the-rules-of-a-board-are-pages-the-workspace-and-its-projects-keep-read-first-by-every-agent.md)): the workspace's, the console's own until an administrator writes the organization's, with its version and who wrote it when written; then this project's own, or that it adds none |
 | `rules write --body <markdown>\|--file <path>\|-\|none [--workspace] [--base <version>]` | `PUT .../docs/rules` or `POST .../docs/rules/archive`; with `--workspace`, `PUT /api/v1/rules` or `POST /api/v1/rules/archive` | the version written, that the console's own rules sent as they are wrote nothing, or that the rules are put away; for an owner of the project, or an administrator for the workspace's |
-| `take <number\|id> [--agent <name>]` | `GET .../tasks/<ref>`, then `POST .../runs`, then `GET .../rules`, `GET /api/v1/me`, `GET .../tasks/<ref>` again and `GET .../tasks/<id>/comments` | the run that began, the task in full as it stands taken with the discussion on it, the rules that hold as they read for the person, and what to do next; a run open on the task is taken over, and that is said when it happened ([ADR-0020](../adr/0020-the-console-does-not-claim-an-agent-is-at-work-a-run-says-when-it-was-last-heard-from-and-a-new-run-takes-over.md)) |
-| `report <markdown>`, `report --file <path>`, `report -` | `POST .../runs/<id>/reports` | how many reports the run carries |
-| `hand-in <https url \| file path> [--label <words>]` | `POST .../runs/<id>/artifacts` for a link; `POST .../runs/<id>/files` for a file, sent as a form with its name and its media type by extension | how many artifacts; a picture handed in is shown on the task, and where a report names it as `![words](its name)` |
+| `take <number\|id> [--agent <name>]` | `GET .../tasks/<ref>`, then `POST .../runs`, then `GET .../rules`, `GET /api/v1/me`, `GET .../tasks/<ref>` again, `GET .../tasks/<id>/comments` and `GET .../runs?open=true&mine=true` | the run that began, the task in full as it stands taken with the discussion on it, the rules that hold as they read for the person, and what to do next; a run open on the task is taken over, and that is said when it happened ([ADR-0020](../adr/0020-the-console-does-not-claim-an-agent-is-at-work-a-run-says-when-it-was-last-heard-from-and-a-new-run-takes-over.md)); another run of the token open in the project is named, with the `--run <id>` to say on every command on a run from here |
+| `report <markdown> [--run <id>]`, `report --file <path> [--run <id>]`, `report - [--run <id>]` | `POST .../runs/<id>/reports` | how many reports the run carries |
+| `hand-in <https url \| file path> [--label <words>] [--run <id>]` | `POST .../runs/<id>/artifacts` for a link; `POST .../runs/<id>/files` for a file, sent as a form with its name and its media type by extension | how many artifacts; a picture handed in is shown on the task, and where a report names it as `![words](its name)` |
 | `comment <number\|id> "<markdown>" [--attach <path>]...`, `comment <number\|id> --file <path>`, `comment <number\|id> -` | `GET .../tasks/<ref>`, then `POST .../tasks/<id>/comments`: as JSON, or as one form with the part `body` and a part `file` per file attached, its media type by extension | the comment as written, with its files and the command that reads each; a word to the task's people, which needs no run ([ADR-0024](../adr/0024-a-task-carries-a-discussion-of-comments-with-their-files-read-as-one-thread-with-the-runs-and-the-decisions.md)) |
 | `file <id> [--out <path>]` | `GET .../files/<id>` | that the file is saved, where, with its size and type: under its own name in the working directory, at the path, or into the directory named; a file a run handed in, one put in a comment, or one attached to a page, so that an agent looks at a picture a person put on the board |
-| `ask "<question>" --option "<label>" ... [--body <markdown>\|--file <path>] [--wait <seconds>]` | `POST .../decisions` with `runId`, then `GET .../decisions/<id>?wait=` | the decision raised, its options; then the answer, or that it still waits |
+| `ask "<question>" --option "<label>" ... [--body <markdown>\|--file <path>] [--wait <seconds>] [--run <id>]` | `POST .../decisions` with `runId`, then `GET .../decisions/<id>?wait=` | the decision raised, its options; then the answer, or that it still waits |
 | `decision <id> [--wait <seconds>]` | `GET .../decisions/<id>`, with `?wait=` while waiting | the decision; with a wait, the answer or that it still waits |
 | `decisions [--open] [--limit <n>] [--offset <n>]` | `GET .../decisions` | one line per decision; a page at a time |
-| `finish [--summary <markdown>\|--file <path>]`, `fail [...]` | `POST .../runs/<id>/end` | how the run ended |
+| `finish [--summary <markdown>\|--file <path>] [--run <id>]`, `fail [...]` | `POST .../runs/<id>/end` | how the run ended |
 | `abandon [<run id>] [--summary <markdown>]` | `POST .../runs/<id>/end`, as `abandoned` | the same |
 | `runs [--task <number\|id>] [--open] [--mine] [--limit <n>] [--offset <n>]` | `GET .../runs` | one line per run, with when an open one was last heard from; a page at a time |
 | `run <id>` | `GET .../runs/<id>` | the run in full, with its reports, what it handed in and where each file is read |
 | `decision <id> --outcome <markdown>\|--file <path>` | `PATCH .../decisions/<id>` | the decision as a record, with what followed written down |
 | `docs [<folder>] [--search <words>] [--archived]` | `GET .../docs?folder=` or `?q=` | the folders and the pages of a folder, or the pages found by words: one line per page |
 | `doc <path> [--version <n>\|--versions]` | `GET .../docs/<path>`, `.../versions`, `.../versions/<n>` | the page in full: its body, what it refers to, what refers to it, its files; or its versions; or one as it was |
-| `write <path> [--title <title>] --body <markdown>\|--file <path> [--base <version>]` | `GET .../docs/<path>` for the title when none is said, then `PUT .../docs/<path>` | the path, the title and the version written, and what the page refers to |
+| `write <path> [--title <title>] --body <markdown>\|--file <path> [--base <version>]` | `GET .../docs/<path>` for the title when none is said, then `PUT .../docs/<path>` | the path, the title and the version written, and what the page refers to; the title is shown above the body, on the page and by `doc`, so the body does not begin with it |
 | `attach <path> <file> [--label <words>]` | `POST .../docs/<path>/files`, as a form | how many files the page carries; a picture attached is shown where the page's body names it as `![words](its name)` |
 | `archive <path>`, `restore <path>` | `POST .../docs/<path>/archive`, `.../restore` | that the page is put away, or back |
 | `serve [<dir>] [--port <n>]` | `GET /api/v1/me` once; then every request of the pages under `/api/`, carried with the token | where it serves and as whom; then nothing until stopped ([a console of one's own](#a-console-of-ones-own)) |
@@ -90,13 +90,13 @@ What an administrator or an owner does on the pages, their agent does with `peop
 
 ## The run a command means
 
-`report`, `hand-in`, `ask`, `finish` and `fail` act on a run. Named with `--run <id>`, that one; else the one open run begun with this token in the project (`GET .../runs?open=true&mine=true`). None open, or several: the command exits with `1` and says so, listing the open ones, so that an agent working two tasks at once says which.
+`report`, `hand-in`, `ask`, `finish` and `fail` act on a run. Named with `--run <id>`, that one; else the one open run begun with this token in the project (`GET .../runs?open=true&mine=true`). None open, or several: the command exits with `1` and says so as `run.none` or `run.ambiguous`, listing the open ones, so that an agent working two tasks at once says which; `take` says the same when the run it begins is beside another of the token's.
 
 `tasks`, `decisions` and `runs` show a page at a time: `DEFAULT_PAGE_LIMIT` lines unless `--limit <n>` says otherwise (up to `LIST_LIMIT`), from `--offset <n>` on, and a last line, `... more: --offset <n>`, says how to ask for the next page when there is one; with `--json`, the console's answer as it is, `more` included. An agent reads the first page and asks for the next only when what it looks for is not on it.
 
 ## Waiting for a decision
 
-`ask` waits 60 seconds for the answer unless `--wait` says otherwise, within what an agent's shell gives one command; `decision <id> --wait <seconds>` waits as long as it is told, a day at most. The command asks the console to hold each request for up to 50 seconds (`?wait=`), the server's own bound, and repeats while the time lasts, with a breath between requests; the answer arrives as soon as a person gives it, since the console is woken through the database's own channel. A decision that still waits when the time is up is exit code `3`: the run waits with it, so the agent keeps waiting with `console decision <id> --wait 100`, within what its shell gives one command, and goes on meanwhile only with work that does not depend on the answer. `ask` prints the decision's id as soon as it is raised, before any waiting, so that a wait cut short loses nothing; with `--json` it prints the decision then, and again with its answer when that comes.
+`ask` waits 60 seconds for the answer unless `--wait` says otherwise, within what an agent's shell gives one command; `decision <id> --wait <seconds>` waits as long as it is told, a day at most. The command asks the console to hold each request for up to 50 seconds (`?wait=`), the server's own bound, and repeats while the time lasts, with a breath between requests; the answer arrives as soon as a person gives it, since the console is woken through the database's own channel. A decision that still waits when the time is up is exit code `3`: the run waits with it, so the agent keeps waiting with `console decision <id> --wait 100`, within what its shell gives one command, and goes on meanwhile only with work that does not depend on the answer. `ask` prints the decision's id as soon as it is raised, before any waiting, so that a wait cut short loses nothing; with `--json` it prints the decision then, and again with its answer when that comes. The answer may be the person's own words rather than one of the options: it is then one more option of the decision, marked as theirs, and the one chosen; the command prints it so, and the agent acts on it as given.
 
 ## A console of one's own
 

package/docs/specs/rest.md

@@ -121,7 +121,7 @@ The rules of the board ([ADR-0023](../adr/0023-the-rules-of-a-board-are-pages-th
 
 ### `GET /api/v1/work`
 
-`{ "tasks": [{ "project": { "key", "name", "color", "symbol", "icon" }, "task" }, ...], "decisions": [{ "project", "decision" }, ...] }`: what is on the asker's plate across the projects they may see ([ADR-0019](../adr/0019-a-task-is-planned-in-days-the-board-keeps-its-moments-and-goals-and-categories-give-the-work-its-shape.md)): the open tasks assigned to them, the sooner due first and those with no day last, and the decisions that wait for a person, the longest waiting first; each with the project it belongs to, so that a page says and links it. At most `LIST_LIMIT` of each.
+`{ "tasks": [{ "project": { "key", "name", "color", "symbol", "icon" }, "task" }, ...], "closed": [{ "project", "task" }, ...], "decisions": [{ "project", "decision" }, ...] }`: what is on the asker's plate across the projects they may see ([ADR-0019](../adr/0019-a-task-is-planned-in-days-the-board-keeps-its-moments-and-goals-and-categories-give-the-work-its-shape.md)): the open tasks assigned to them, the sooner due first and those with no day last; `closed`, the tasks assigned to them that are done or dropped and not yet put away, the last closed first, so that the week on the plate's page shows them on their days as a project's calendar does; and the decisions that wait for a person, the longest waiting first; each with the project it belongs to, so that a page says and links it. A task put away is in neither list ([ADR-0030](../adr/0030-a-task-is-put-away-from-any-state.md)). At most `LIST_LIMIT` of each.
 
 ### `GET /api/v1/tokens` and `POST /api/v1/tokens`
 
@@ -141,7 +141,7 @@ An administrator's sight of everyone's agents ([ADR-0011](../adr/0011-an-agent-c
 
 ### `GET /api/v1/people/<id>/work`
 
-`{ "tasks": [{ "project", "task" }, ...] }`: what is on another person's plate, for whoever oversees them: an administrator, or an owner of a project the person is in (everyone of the workspace is in a project open to it; a private one holds those listed), signed in or through their agent. The person's open tasks, the sooner due first and those with no day last, within the projects the asker may see and no other, each with its project; the decisions are left out, since they wait for anyone. `auth.forbidden` for anyone else; `person.not_found` for an id that is nobody's.
+`{ "tasks": [{ "project", "task" }, ...], "closed": [{ "project", "task" }, ...] }`: what is on another person's plate, for whoever oversees them: an administrator, or an owner of a project the person is in (everyone of the workspace is in a project open to it; a private one holds those listed), signed in or through their agent. The person's open tasks, the sooner due first and those with no day last, and as `closed` their tasks done or dropped and not yet put away, both within the projects the asker may see and no other, each with its project; the decisions are left out, since they wait for anyone. `auth.forbidden` for anyone else; `person.not_found` for an id that is nobody's.
 
 ### Connecting an agent
 
@@ -197,7 +197,7 @@ Writing one, for whoever may work in the project, with a session or a token, is
 
 ### `GET /api/v1/projects/<key>/decisions?open=&task=&limit=&offset=`
 
-`{ "items": [decision, ...], "more": boolean }`: the project's, the ones that wait first, newest first within each, a page at a time as the tasks are (`limit`, `offset`, `more`); `open=true` keeps only those that wait, `task=<id>` only those about one task. A decision carries its `question`, `body` (Markdown: the context it rests on), `options` (each an `id` and a `label`), `taskId` and `taskNumber` (or `null`), `raisedBy`, `run` (the `id` and `agent` of the run that raised it, when an agent asked, or `null`), `answer`: `null` while it waits, else the chosen `option`, a `note` or `null` (the rationale given with it), `by` and `at`; and `outcome`, what followed, in Markdown, or `null` until someone writes it. Context, rationale and outcome make the decision a record ([ADR-0009](../adr/0009-documents-are-pages-of-markdown-in-a-project-addressed-by-path-versioned-and-linked-both-ways.md)); a link in any of them to a document's path is kept both ways, so that the document says the decision refers to it.
+`{ "items": [decision, ...], "more": boolean }`: the project's, the ones that wait first, newest first within each, a page at a time as the tasks are (`limit`, `offset`, `more`); `open=true` keeps only those that wait, `task=<id>` only those about one task. A decision carries its `question`, `body` (Markdown: the context it rests on), `options` (each an `id` and a `label`; the last carries `own: true` when it is the person's own answer, written instead of choosing, and the options given carry no `own`), `taskId` and `taskNumber` (or `null`), `raisedBy`, `run` (the `id` and `agent` of the run that raised it, when an agent asked, or `null`), `answer`: `null` while it waits, else the chosen `option`, a `note` or `null` (the rationale given with it), `by` and `at`; and `outcome`, what followed, in Markdown, or `null` until someone writes it. Context, rationale and outcome make the decision a record ([ADR-0009](../adr/0009-documents-are-pages-of-markdown-in-a-project-addressed-by-path-versioned-and-linked-both-ways.md)); a link in any of them to a document's path is kept both ways, so that the document says the decision refers to it.
 
 ### `POST /api/v1/projects/<key>/decisions`
 
@@ -207,7 +207,7 @@ Takes `question`, `options` (two to `MAX_OPTIONS` labels), and optionally `body`
 
 One decision. With `wait=<seconds>` (`0` to `600`) the request is held while the decision waits, up to the server's own bound (50 seconds), and answers the decision as it stands then: how an agent learns the answer at once, woken through the database's own channel, without asking again and again. A decision answered already, or a wait of `0`, answers at once.
 
-The answer takes `option` (the id of one of its options) and optionally a `note`. A decision is answered once; the answer records who gave it and when, writes a `decision.answered` event with the label of the option, and lets a run that waited go on (`status: running`), unless another decision of its still waits.
+The answer takes `option` (the id of one of its options) or `own` (the person's own answer, where none of the options is it: one line, up to `MAX_OPTION_LABEL_LENGTH`, as an option is worded; `request.invalid` with both or with neither), and optionally a `note`. An answer of the person's own becomes one more option of the decision, numbered after the ones given and marked `own: true`, and the one chosen, so that the answer names an option either way and every reader finds its label. A decision is answered once; the answer records who gave it and when, writes a `decision.answered` event with the label of the option, and lets a run that waited go on (`status: running`), unless another decision of its still waits.
 
 ### `PATCH /api/v1/projects/<key>/decisions/<id>`
 
@@ -245,19 +245,11 @@ Takes `status` (`finished`, `failed` or `abandoned`) and optionally a `summary`
 
 ### `GET /api/v1/projects/<key>/skills`
 
-The project's pack, as the SkillCDN deployment serves it at the project's address, or at the organization's (`SKILLS_ADDRESS`) when the project names none, read through `SKILLCDN_URL` ([ADR-0028](../adr/0028-the-console-reads-a-projects-pack-through-the-deployments-rest-api-with-a-pack-token-for-a-private-one.md)): `{ "address", "source", "page", "status", "items" }`. `address` is canonical, or `null` with `status: "none"` when neither names one; `source` is the deployment's origin and `page` where a person browses the address. When `ready`, `pack` names the pack as its manifest does, else its README, else the host (`name`, `description` and `language`, each or `null`), and `counts` says how many `skills` and `documents` the deployment indexed at the address; neither is there otherwise. `status` is `ready`, or why `items` is empty: `indexing` and `failed` as the deployment says of the repository, `not_found` when it does not serve the address to the console (a private pack is read with the project's pack token; without one the console asks as nobody, so a private repository is not read), `token_invalid` when the deployment refuses the pack token the project holds (expired, removed, or its maker lost the repository), `unavailable` when it could not be reached or read. An item is one skill: `name`, `description`, `directory` and `path` (of its `SKILL.md`, from the repository's root, which the routes below take), `page` (the skill at the deployment, for a person), `uri` (what an agent loads it by through its own SkillCDN connection, `skill://gh/<owner>/<repo>/<path>`, or `null`), and `translations` (the title and the description by language tag, as the repository gives them). The console keeps nothing of the skills: a public answer per address stands for a minute, then the deployment is asked again; what is read with a pack token is asked every time, and held for nobody.
+The project's pack, read by address ([ADR-0028](../adr/0028-the-console-reads-a-projects-pack-through-the-deployments-rest-api-with-a-pack-token-for-a-private-one.md), [ADR-0031](../adr/0031-the-console-reads-a-pack-as-the-skillcdn-command-does-and-a-local-one-from-a-directory.md)): at the project's address, or at the organization's (`SKILLS_ADDRESS`) when the project names none; at the SkillCDN deployment of `SKILLCDN_URL` for the address of a git host, with the pack token the project holds where the pack is private, and from the directory of `SKILLS_DIR` for a `local` address (`/local/<owner>/<name>`), read on the console's machine with the reading rules a deployment applies. `{ "address", "source", "page", "status", "refusal", "pack", "counts", "items", "mount" }`. `address` is canonical, or `null` with `status: "none"` when neither names one; `source` is the deployment's origin and `page` where a person browses the address there, both `null` for a pack read from a directory. When `ready`, `pack` names the pack as its manifest does, else its README, else the host (`name`, `description` and `language`, each or `null`), `counts` says how many `skills` and `documents` the index found, and `items` are the skills: `name`, `description`, `directory` and `path` (of its `SKILL.md`, from the repository's root, which the routes below take), `page` (the skill at the deployment, for a person, or `null`), `uri` (what an agent loads it by through its own SkillCDN connection, `skill://<host>/<owner>/<name>/<path>`, or `null`; one of a `local` pack means something on the console's machine and nowhere else), and `translations` (the title and the description by language tag, as the repository gives them). `mount` is what the address serves as the main repository's REST API answers it (`RestMount` of `@skillcdn/core`), for a program that renders what a model is given, or `null` when nothing was answered. `status` is `ready`, or why `items` is empty: `indexing` and `failed` as the pack says of itself, `not_found` when nothing is served to the console at the address (a private pack is read with the project's pack token; without one the console asks as nobody, so a private repository is not read; a `local` pack is not in the directory), `token_invalid` when the deployment refuses the pack token the project holds (expired, removed, or its maker lost the repository), `unavailable` when the pack could not be reached or read; `refusal` carries the pack's own `code` and `message` then, with `sourceUrl` and `directories` where it gave them (`null` and empty otherwise), and is `null` when the read went well. The console keeps nothing of the skills: a public answer per address stands for a minute, then the pack is asked again; what is read with a pack token is asked every time, and held for nobody.
 
-### `GET /api/v1/projects/<key>/skills/one?path=&cursor=` and `GET .../skills/file?path=&offset=&limit=`
+### `GET /api/v1/projects/<key>/skills/one?path=&cursor=`, `.../skills/file?path=&offset=&limit=`, `.../skills/browse?path=&cursor=&limit=` and `.../skills/find?query=&path=&cursor=&limit=`
 
-One skill of the pack, and a file of it, read by the console from the deployment for whoever may see the project, with the pack token where the project holds one ([ADR-0028](../adr/0028-the-console-reads-a-projects-pack-through-the-deployments-rest-api-with-a-pack-token-for-a-private-one.md)); each read is logged with who read what, never with what was read. `path` is the path from the repository's root, up to 500 characters; a query that is not one is `request.invalid`.
-
-`skills/one` is the deployment's `load_skill`, in the console's shape: `{ "address", "source", "page", "status", "skill" }`, `skill` being `null` unless `status` is `ready`, else `path`, `directory`, `name`, `description`, `rules` (the manifests that hold for the skill, from the repository's root to the nearest, each `path`, `body` and `truncated`), `body`, `included` (the files the skill includes, the same way), `files` (the paths of the skill's own files), `references` (each `path` and `status`: `available`, `blocked`, `missing` or `outside_mount`), `complete` and `nextCursor` (a page may end inside a rule or a file; the next page continues it, and the skill is whole only when `complete`), `serving` (`full`, whether the skill is served whole or described only under its license; `license`; `sourceUrl`, where it is read at its host) and `warnings`. `skills/file` is `read_repo_file`: `{ "address", "source", "status", "file", "folder" }`, `file` being the page (`path`, `content`, `offset`, `nextOffset` or `null` at the end, `totalLength`, in characters; `limit` 1 to 100,000) or `folder` what a folder holds (`path`, `entries` of `path`, `kind` and `size`, `truncated`), both `null` unless `ready`; `failed` here is a file the deployment will not carry, too large or not text.
-
-### `GET /api/v1/projects/<key>/skills/browse?path=&cursor=&limit=` and `GET .../skills/find?query=&path=&cursor=&limit=`
-
-What a folder of the pack holds, and what words find in it, read the same way: the deployment's `browse_repo` and `search_repo` in the console's shape, for whoever may see the project, with the pack token where the project holds one ([ADR-0028](../adr/0028-the-console-reads-a-projects-pack-through-the-deployments-rest-api-with-a-pack-token-for-a-private-one.md)); each read is logged with who read which folder, never with the words searched for. `path` is a folder's path from the repository's root, up to 500 characters, the mounted folder when left out; `cursor` continues one listing; a query out of bounds is `request.invalid`.
-
-`skills/browse` answers `{ "address", "source", "page", "status", "folder" }`, `folder` being `null` unless `ready`, else the folder's `path`, its `overview` (the README that introduces it: `path`, `title` and `description`, or `null`), its `entries`, each with `kind` (`skill`, `directory` or `file`), `path` (of the `SKILL.md` for a skill), `name` and `description` (or `null`), `skillCount` and `documentCount` (what a folder holds), `size` (a file's, in bytes, or `null`), `overviewPath` (a folder's README, or `null`), `license` and `describedOnly` (a skill's: whether the address only describes it under its license), and `nextCursor` (or `null` at the end; `limit` 1 to 200, 50 unless given). `skills/find` answers `{ "address", "source", "page", "status", "found" }`, `found` being `null` unless `ready`, else the `query` (1 to 500 characters, required), the `path` the search was kept to (or `null`), `items` in relevance order, a `skill` as the listing's item with the `files` of it that matched (each `path`, `title` and `summary`), `moreFiles`, `license` and `describedOnly`, or a `document` with its `path`, `title`, `summary` and `skillDirectory` (or `null`), and `nextCursor` (`limit` 1 to 25, 10 unless given). Words are matched, not meaning, in the language the pack is written in; the deployment's listing of a mount is bounded, and these two are how the rest of a large pack is reached.
+One skill of the pack, a file of it, what a folder holds and what words find, read by the console from the pack for whoever may see the project, with the pack token where the project holds one ([ADR-0028](../adr/0028-the-console-reads-a-projects-pack-through-the-deployments-rest-api-with-a-pack-token-for-a-private-one.md)), and answered as the pack answered them ([ADR-0031](../adr/0031-the-console-reads-a-pack-as-the-skillcdn-command-does-and-a-local-one-from-a-directory.md)): `{ "address", "source", "page", "status", "refusal", "read" }`, the envelope as above, and `read` the body of the matching route of the main repository's REST API, as `@skillcdn/core` spells it, or `null` unless `ready`. `skills/one` is `load_skill`: `read` is a `RestSkill`, a page of the skill's context, the rules from the repository's root to the nearest manifest, the body and the included files, which `complete` and `nextCursor` say to continue, and `commit`, the commit it was read from. `skills/file` is `read_repo_file`: `read` is a `RestFile`, a page of the file in characters (`offset`, `nextOffset`, `totalLength`; `limit` 1 to 100,000) or, when the path names a folder, its entries. `skills/browse` is `browse_repo`: `read` is a `RestBrowse`, a page of what the folder holds (`limit` 1 to 200, 50 unless given; `cursor` continues). `skills/find` is `search_repo`: `read` is a `RestFind`, a page of what the words find in relevance order (`query` 1 to 500 characters, required; `limit` 1 to 25, 10 unless given). `path` is a path from the repository's root, up to 500 characters, the mounted folder when `browse` and `find` leave it out; a query out of bounds is `request.invalid`. Each read is logged with who read what of which pack, never with what was read or the words searched for. What the pack refuses is the status with the pack's own `refusal`: a skill or a file that is not there is `not_found`, a file the pack will not carry, too large or not text, is `failed` with where it is at its source. `@skillcdn/core` reads every `read` back as the result it was made from (`skillResultOf`, `fileResultOf`, `directoryResultOf`, `browseResultOf`, `findResultOf`, at the `mountSummaryOf` of the listing's `mount`) and renders what a model is given; the command does exactly that.
 
 ### `PUT /api/v1/projects/<key>/pack-token` and `DELETE .../pack-token`
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@skillcdn/console",
-  "version": "0.1.23",
+  "version": "0.3.0",
   "description": "What a custom SkillCDN console is built from: the API client and schemas, the components, the composition of the default console, and the console command agents work the board with.",
   "license": "MIT",
   "homepage": "https://github.com/skillcdn/console#readme",
@@ -68,6 +68,7 @@
     "vitest": "^5.0.3"
   },
   "dependencies": {
+    "@skillcdn/core": "^0.3.0",
     "react-markdown": "^10.1.0",
     "remark-gfm": "^4.0.1",
     "zod": "^4.6.5"

package/skills/deploying-a-console/SKILL.md

@@ -5,7 +5,7 @@ license: MIT
 compatibility: Needs a shell with Node.js 24 or newer, git, curl, jq and the AWS CLI v2, the gh command signed in or an empty repository the person made, network access to AWS, Cloudflare, GitHub and npm, an AWS account and a domain on Cloudflare the person can create a key and a token for, and a browser on any device for the few steps only a signed-in person can take. Works in any agent that can run a shell and write files; on Windows, in Git Bash with path conversion off.
 metadata:
   author: skillcdn
-  version: "1.1"
+  version: "1.2"
 skillcdn:
   translations:
     ko:
@@ -14,7 +14,7 @@ skillcdn:
 ---
 # Deploying a console for an organization
 
-What goes in: an AWS account, a domain on Cloudflare or one to buy, and the answers to a few plain questions. What comes out: the console at `https://<hostname>`, signed in by its first administrator, with a first project and an agent connected; running as containers on AWS next to a managed PostgreSQL and a bucket, reached only through Cloudflare, every secret in a parameter store; a private deployment repository whose every push rebuilds and redeploys; a budget alert; and a record, `DEPLOY.md`, of what exists and how it is run. The person never needs to know the cloud: every choice is derived from their answers, shown with its cost, and changed when they ask. The shape and why it was chosen are [ADR-0017](/docs/adr/0017-the-reference-deployment-is-the-image-on-aws-behind-cloudflare-written-as-a-skill.md); what the console asks of any platform is [deploy/README.md](/deploy/README.md).
+What goes in: an AWS account, a domain on Cloudflare or one to buy, and the answers to a few plain questions. What comes out: the console at `https://<hostname>`, signed in by its first administrator, with a first project and an agent connected; running as containers on AWS next to a managed PostgreSQL and a bucket, reached only through Cloudflare, every secret in a parameter store; a private deployment repository whose every push rebuilds and redeploys; a budget alert; and a record, `DEPLOY.md`, of what exists and how it is run. The person never needs to know the cloud: every choice is derived from their answers, shown with its cost, and changed when they ask. The shape and why it was chosen are [ADR-0017](/docs/adr/0017-the-reference-deployment-is-the-image-on-aws-behind-cloudflare-written-as-a-skill.md); what the console asks of any platform is [deploy/README.md](/deploy/README.md). For one machine, a trial, or a closed network that reaches no cloud, the smallest install of [deploy/README.md](/deploy/README.md#the-smallest-install-and-a-closed-network) is the shape, not this skill: the image next to PostgreSQL with the packs in a directory, carried in where nothing is reachable.
 
 ## How the person is involved
 

package/skills/working-the-board/SKILL.md

@@ -5,7 +5,7 @@ license: MIT
 compatibility: Needs a shell with the console command on the PATH (npm install -g @skillcdn/console, Node.js 24 or newer), signed in by a person. Nothing else; the command needs no key of its own and the agent never sees a token.
 metadata:
   author: skillcdn
-  version: "1.16"
+  version: "1.19"
 skillcdn:
   translations:
     ko:
@@ -41,7 +41,7 @@ The full contract is the [specification of the command line](/docs/specs/cli.md)
 | Input | Source |
 |---|---|
 | The task | Its number (`#7`) or its id, from what the person said. Told to pick one, `console work` lists what is on the person's plate across their projects, the sooner due first (`--person <login>` another person's, for an administrator or an owner of a project they are in), and `console tasks --state ready --mine` what is ready and theirs in this one (`--due overdue`, `--due week`, `--category <key>` and `--goal <id>` narrow it further); a task is never taken without being told which, or that any ready one may be. |
-| The work | The task's body, read with `console task <number>`: what to make, where, the milestones, what to ask; the comments on it, which are the discussion so far, printed with the task, their pictures saved with `console file <id>`; with its plan, the category, the goal it works towards (`console goal <id>` says what reaching it means, its category and the days it starts and is meant to be reached by) and the days it starts and is due, which the reports and the summary keep to. The pages it links to (`console doc <path>`) and the project's pack (`console skills` lists its skills and says how many skills and documents it has; `console skills <folder>` shows what a folder of it holds, `console skills --search <words>` what the words find in it; `console skill <path>` reads one whole through the console, its rules first, a private pack through the pack token the project holds, [ADR-0028](/docs/adr/0028-the-console-reads-a-projects-pack-through-the-deployments-rest-api-with-a-pack-token-for-a-private-one.md); `console skill --file <file>` a file of it; a host that lists skills through a connection of its own loads them by their URI) say the rest. |
+| The work | The task's body, read with `console task <number>`: what to make, where, the milestones, what to ask; the comments on it, which are the discussion so far, printed with the task, their pictures saved with `console file <id>`; with its plan, the category, the goal it works towards (`console goal <id>` says what reaching it means, its category and the days it starts and is meant to be reached by) and the days it starts and is due, which the reports and the summary keep to. The pages it links to (`console doc <path>`) and the project's pack (`console skills` says where the pack is, what a client is told of it on connect, and every skill and document; `console skills <folder>` shows what a folder of it holds, `console skills --search <words>` what the words find in it; `console skill <path>` reads one whole through the console, its rules first, as an MCP client's model is given it, a private pack through the pack token the project holds, [ADR-0028](/docs/adr/0028-the-console-reads-a-projects-pack-through-the-deployments-rest-api-with-a-pack-token-for-a-private-one.md), and a pack on the console's own machine from its directory, [ADR-0031](/docs/adr/0031-the-console-reads-a-pack-as-the-skillcdn-command-does-and-a-local-one-from-a-directory.md); `console skill --file <file>` a file of it; a host that lists skills through a connection of its own loads them by their URI, which means nothing elsewhere for a pack on the console's machine) say the rest. |
 | The rules | The workspace's, the console's own until an administrator writes the organization's, and this project's own when it has them: which skills to load first, where the work lives, the pages, what may be decided alone, how to report ([ADR-0023](/docs/adr/0023-the-rules-of-a-board-are-pages-the-workspace-and-its-projects-keep-read-first-by-every-agent.md)). `console take` prints them with the task, so they are read once, there; `console rules` reads them without taking, as when a task is still to be chosen. They hold over this skill's defaults where they differ. |
 
 ## Workflow
@@ -54,7 +54,7 @@ Told which task, go to phase 2: `console take` prints the rules of the board wit
 
 ### Phase 2: Take
 
-`console take <number>`. A run begins: the task is in progress and the person's, and every report, hand-in, question and ending from here acts on this run. Taken by mistake, `console abandon` leaves it and the task stays as it was.
+`console take <number>`. A run begins, and the command says its id: the task is in progress and the person's, and every report, hand-in, question and ending from here acts on this run. With another run of the person's open in the project, which `console take` says, each of those commands names the run: `--run <id>`. Taken by mistake, `console abandon` leaves it and the task stays as it was.
 
 ### Phase 3: Work, and report at the milestones
 
@@ -62,7 +62,7 @@ The work happens where it happens: in the repository, the document, the tool. At
 
 ### Phase 4: Ask when a person must decide
 
-A choice the body does not settle, a trade-off, a cost, a change of scope: `console ask "<question>" --option "<one>" --option "<another>" --body "<what they need to know>"`. The run waits for the answer; the command waits a minute and exits with `3` while it is still to come. Keep waiting with `console decision <id> --wait 100`, as often as needed, and meanwhile do only what does not depend on the answer. Act on the answer as given; what was answered is not asked again. Once acted on, `console decision <id> --outcome "<what followed>"` makes the decision read as a record.
+A choice the body does not settle, a trade-off, a cost, a change of scope: `console ask "<question>" --option "<one>" --option "<another>" --body "<what they need to know>"`. The run waits for the answer; the command waits a minute and exits with `3` while it is still to come. Keep waiting with `console decision <id> --wait 100`, as often as needed, and meanwhile do only what does not depend on the answer. Act on the answer as given, which may be the person's own words rather than one of the options, marked as theirs; what was answered is not asked again. Once acted on, `console decision <id> --outcome "<what followed>"` makes the decision read as a record.
 
 ### Phase 5: Hand in
 
@@ -78,13 +78,7 @@ After the last report, `console finish --summary "<what was done, and what is le
 
 ## Setting up, when told to
 
-A task or a person may ask for the project itself rather than work in it: a project made or changed (`console project new <key> "<name>"`, `console project edit <key>`), its mark (`console project icon <key> <file>`), its members (`console member add <login>`, `console member role`, `console member remove`), the workspace's categories (`console category new <key> "<name>"`, `console category edit`, `console category remove`), what a person is (`console person role <login> <admin|member>`), its goals (`console goal new`), and its rules (`console rules write --file <path>`, from [the example](references/project-rules.md); the workspace's with `--workspace`, for an administrator). The agent does these as its person may, an owner of the project or an administrator of the workspace ([ADR-0021](/docs/adr/0021-a-token-configures-as-its-person-does.md)); the feed names the agent beside the person on each. What the person may not, the console refuses (`auth.forbidden`): that step goes back to the person in the report, never worked around. `console people` and `console members` say who is who, by login.
-
-## The sentence a repository carries
-
-A repository whose checkouts are worked through a console says so in its agreement (AGENTS.md, or CLAUDE.md where that is the file agents read), in one sentence copied as it is and placed at the head of its workflow; a pack says it in the rules of its `SKILLCDN.md`, with `the checkout` for `this checkout`. The sentence binds the checkout to the console and says nothing of how: the command's help and this skill say how, and the repository's own agreement keeps saying how a change is committed and pushed.
-
-> **Bound to a console?** When `.skillcdn-console.json` is in this checkout, or `console whoami` names a project, work the task through that SkillCDN console (`console help` says how).
+A task or a person may ask for the project itself rather than work in it: a project made or changed, its mark, its members, the workspace's categories, what a person is, its goals, its rules. [references/setting-up.md](references/setting-up.md) says which commands do that, as the person may: an owner of the project, or an administrator of the workspace; a project's rules start from [references/project-rules.md](references/project-rules.md).
 
 ## Hard rules
 
@@ -93,9 +87,10 @@ A repository whose checkouts are worked through a console says so in its agreeme
 - The board's words are the vocabulary's own: states `idea`, `ready`, `in_progress`, `in_review`, `done` and `dropped`; priorities `low`, `normal`, `high` and `urgent`; a day is `2026-10-24`. Taking a task moves it, finishing moves it; it is not moved by hand around a run. When a task is started and when it is done, the board writes down itself: never typed.
 - The plan is the person's: a task's days, its category and its goal are changed (`console task edit`) only when the task says so or a person asks, and a goal is set or moved (`console goal new`, `console goal edit`) only when the person is an owner and said to.
 - The rules are the people's: `console rules write` only when a person asked for exactly that, and never to loosen what they ask of agents.
-- Exit codes: `0` done; `1` refused or unreachable, the reason on standard error as a code and words, which `console help <command>` names; `2` not understood; `3` a decision still waits.
+- Exit codes: `0` done; `1` refused or unreachable, the reason on standard error as a code and words, which `console help <command>` names; `2` not understood; `3` a decision still waits; `4` the command and the console do not go together, and standard error says which to update.
 - Everything sent is held to limits the console states (`console help <command>`); a refusal `request.invalid` names the field.
 
-## Terms
+## Beside this skill
 
-- **Task**: what is to be done, numbered per project, with its plan (a category, a goal, the days it starts and is due) and its moments (when it was started and done, which the board keeps). **Goal**: what the project works towards, on its roadmap, with the day it is meant to be reached by; its progress is its tasks. **Category**: a kind of work, the workspace's word for it, by key. **Run**: one agent at work on one task for one person, with its reports, what it handed in, and what it waits for. **Decision**: a question with options, which a person answers on the board. **Page**: a document of the project, Markdown at a path that does not change. **Project**: a board of its own, with its members and its skills address.
+- The sentence a repository's agreement carries to bind its checkouts to a console, and how a pack says it: [references/the-sentence.md](references/the-sentence.md).
+- The board's words, task, goal, category, run, decision, page and project, said once: [references/terms.md](references/terms.md).

package/skills/working-the-board/references/setting-up.md

@@ -0,0 +1,3 @@
+# Setting up, when told to
+
+A task or a person may ask for the project itself rather than work in it: a project made or changed (`console project new <key> "<name>"`, `console project edit <key>`), its mark (`console project icon <key> <file>`), its members (`console member add <login>`, `console member role`, `console member remove`), the workspace's categories (`console category new <key> "<name>"`, `console category edit`, `console category remove`), what a person is (`console person role <login> <admin|member>`), its goals (`console goal new`), and its rules (`console rules write --file <path>`, from [the example](project-rules.md); the workspace's with `--workspace`, for an administrator). The agent does these as its person may, an owner of the project or an administrator of the workspace ([ADR-0021](/docs/adr/0021-a-token-configures-as-its-person-does.md)); the feed names the agent beside the person on each. What the person may not, the console refuses (`auth.forbidden`): that step goes back to the person in the report, never worked around. `console people` and `console members` say who is who, by login.

package/skills/working-the-board/references/terms.md

@@ -0,0 +1,9 @@
+# Terms
+
+- **Task**: what is to be done, numbered per project, with its plan (a category, a goal, the days it starts and is due) and its moments (when it was started and done, which the board keeps).
+- **Goal**: what the project works towards, on its roadmap, with the day it is meant to be reached by; its progress is its tasks.
+- **Category**: a kind of work, the workspace's word for it, by key.
+- **Run**: one agent at work on one task for one person, with its reports, what it handed in, and what it waits for.
+- **Decision**: a question with options, which a person answers on the board.
+- **Page**: a document of the project, Markdown at a path that does not change.
+- **Project**: a board of its own, with its members and its skills address.

package/skills/working-the-board/references/the-sentence.md

@@ -0,0 +1,5 @@
+# The sentence a repository carries
+
+A repository whose checkouts are worked through a console says so in its agreement (AGENTS.md, or CLAUDE.md where that is the file agents read), in one sentence copied as it is and placed at the head of its workflow; a pack says it in the rules of its `SKILLCDN.md`, with `the checkout` for `this checkout`. The sentence binds the checkout to the console and says nothing of how: the command's help and the skill working-the-board say how, and the repository's own agreement keeps saying how a change is committed and pushed.
+
+> **Bound to a console?** When `.skillcdn-console.json` is in this checkout, or `console whoami` names a project, work the task through that SkillCDN console (`console help` says how).

package/src/api.ts

@@ -188,6 +188,7 @@ export {
   type RestMembers,
   type RestMePatch,
   type RestOrganization,
+  type RestPackRefusal,
   type RestPackTokenInput,
   type RestPeople,
   type RestPerson,
@@ -210,12 +211,9 @@ export {
   type RestRuns,
   type RestSkill,
   type RestSkillBrowse,
-  type RestSkillBrowseEntry,
   type RestSkillFile,
   type RestSkillFind,
-  type RestSkillFindItem,
   type RestSkillLoad,
-  type RestSkillPage,
   type RestSkills,
   type RestTask,
   type RestTaskCounts,
@@ -280,6 +278,7 @@ export {
   restMePatchSchema,
   restMeSchema,
   restOrganizationSchema,
+  restPackRefusalSchema,
   restPackTokenInputSchema,
   restPeopleSchema,
   restPersonPatchSchema,
@@ -300,16 +299,12 @@ export {
   restRunInputSchema,
   restRunSchema,
   restRunsSchema,
-  restSkillBrowseEntrySchema,
   restSkillBrowseSchema,
   restSkillFileSchema,
-  restSkillFindItemSchema,
   restSkillFindSchema,
   restSkillLoadSchema,
-  restSkillPageSchema,
   restSkillSchema,
   restSkillsSchema,
-  restSkillTextSchema,
   restTaskCountsSchema,
   restTaskInputSchema,
   restTaskLinkSchema,