@skillcdn/console 0.4.1 → 0.4.2

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

@@ -1,16 +1,16 @@
 ---
 name: deploying-a-console
-description: "Deploys a SkillCDN Console for an organization on AWS behind Cloudflare, by an agent on the person's machine, no developer needed: asks a few plain questions (how many people, the web address, how people sign in and who is in, where the organization's skills are, and its website, whose look the console takes by default), shows the monthly cost of the fitting size and the next before anything is made, creates the database, bucket, secrets, tunnel and containers, builds the organization's own look into the image, leaves a private repository that redeploys on every push, signs the first administrator in, makes the first project, connects an agent and proves it with a file handed in and read back. Also grows it to the next size, updates it to a new version of the console, adds a member or rotates a secret. Use when an agent is asked to deploy, set up, host, upgrade or resize a console for an organization. To build a console's pages, use building-a-console; to work tasks on a board, use working-the-board."
+description: "Deploys a SkillCDN Console for an organization on AWS behind Cloudflare, from a person's machine, no developer needed: a few plain questions (how many people, the address, how people sign in and who is in, the organization's skills, its website, whose look it takes by default), the monthly cost before anything is made, then the database, bucket, secrets, tunnel and containers, a private repository that redeploys on every push, the first administrator signed in, the first project, an agent connected and proven with a file handed in. Also grows it, updates it to a new version, installs a plugin, adds a member or rotates a secret. Use when a person says 'set up a console for our company', 'deploy the console', 'host the console on AWS', 'upgrade our console', 'we need a bigger size'. To build the pages alone, use building-a-console; to write a plugin, building-a-plugin; to work tasks, working-the-board. Every purchase and push is confirmed with its price; nothing is spent without the person's word."
 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.4"
+  version: "1.7"
 skillcdn:
   translations:
     ko:
       title: 조직의 콘솔 배포하기
-      description: "조직의 SkillCDN 콘솔을 AWS와 Cloudflare에 배포합니다. 개발자가 아니어도 됩니다: 에이전트가 쉬운 질문 몇 개(몇 명이 쓰는지, 주소, 로그인 방식과 구성원, 조직 스킬의 위치, 그리고 조직의 웹사이트. 웹사이트가 있으면 그 디자인이 콘솔의 기본이 됩니다)를 묻고, 맞는 크기와 그 다음 크기의 월 비용을 먼저 보여준 뒤, 데이터베이스·버킷·비밀·터널·컨테이너를 만들고, 조직의 디자인을 이미지에 담고, 푸시할 때마다 다시 배포되는 비공개 저장소를 남기고, 첫 관리자를 로그인시키고 첫 프로젝트를 만들고 에이전트를 연결해 파일 제출과 되읽기로 증명합니다. 규모 키우기, 콘솔 새 버전으로 올리기, 구성원 추가, 비밀 교체도 합니다. 조직의 콘솔을 배포·설치·호스팅·업그레이드·확장하라고 할 때 쓰세요. 콘솔 페이지를 만들 때는 building-a-console, 보드의 작업을 할 때는 working-the-board를 쓰세요."
+      description: "조직의 SkillCDN 콘솔을 AWS와 Cloudflare에 배포합니다. 개발자가 아니어도 됩니다: 쉬운 질문 몇 개(몇 명이 쓰는지, 주소, 로그인 방식과 구성원, 조직의 스킬, 디자인의 기본이 되는 웹사이트)를 묻고, 무엇을 만들기 전에 맞는 크기와 그 다음 크기의 월 비용을 보여준 뒤, 데이터베이스·버킷·비밀·터널·컨테이너를 만들고, 조직의 디자인을 이미지에 담고, 푸시마다 다시 배포되는 비공개 저장소를 남기고, 첫 관리자를 로그인시키고, 첫 프로젝트를 만들고, 에이전트를 연결해 파일 제출과 되읽기로 증명합니다. 규모 키우기, 새 버전으로 올리기, 이미지에 플러그인 설치, 구성원 추가, 비밀 교체도 합니다. '우리 회사 콘솔 세팅해줘', '콘솔 배포해줘', 'AWS에 콘솔 올려줘', '콘솔 업그레이드해줘', '더 큰 크기가 필요해', '연차 플러그인 설치해줘'라고 할 때 쓰세요. 페이지만 만들 때는 building-a-console, 플러그인을 만들 때는 building-a-plugin, 작업을 할 때는 working-the-board를 쓰세요. 구매와 푸시는 하나하나 가격과 함께 확인받고, 사람의 말 없이는 아무것도 쓰지 않습니다."
 ---
 # Deploying a console for an organization
 
@@ -20,10 +20,10 @@ What goes in: an AWS account, a domain on Cloudflare or one to buy, and the answ
 
 - **Questions:** one message at the start, the ones under "Inputs" that the request leaves open, in plain words. Then a second message, so that the questions stay short: the order of cost for the size ([sizing.md](references/sizing.md)'s snapshot, named as such) and the two credentials to create ([access.md](references/access.md)), so that the person knows what it costs before an account or a key exists, and the credentials are ready when the plan is.
 - **Checkpoints:** the plan with today's cost, before anything is made; each purchase with its price (a domain); a secret only the person holds, asked with the exact steps once the address is known; the first push, which starts the first build and makes the address public once it serves; the record's push; the deletion of the secrets file and the token file. One short message each, with the recommendation, and "OK", in the person's language, continues.
-- **Go-ahead:** when the person says to go ahead alone, the reports between phases need no answer. The plan, a purchase, the first push and a deletion are confirmed in every mode.
-- **Waiting:** what only the person or the world can finish, the run waits for, in the open. A domain whose nameservers the person must change answers at Cloudflare minutes to hours later: the zone is made first, the steps go out in the second message, and from phase 5 the run checks the zone every ten minutes for up to an hour, saying so; still not there, it stops with the record saying what waits and resumes at phase 5 when the person says the nameservers are set. The only way of signing in answered `later` means nobody can sign in: the run stops at phase 5 the same way and resumes when the secret is in the secrets file.
+- **Go-ahead:** when the person says to go ahead alone, the reports between phases need no answer. The plan, a purchase, every push and a deletion are confirmed in every mode.
+- **Waiting:** what only the person or the world can finish, the run waits for, in the open. A domain whose nameservers the person must change answers at Cloudflare minutes to hours later: the zone, which costs nothing and is undone as easily, is made in phase 1, the one thing made before the plan, so that the steps go out in the second message, and from phase 5 the run checks the zone every ten minutes for up to an hour, saying so; still not there, it stops with the record saying what waits and resumes at phase 5 when the person says the nameservers are set. The only way of signing in answered `later` means nobody can sign in: the run stops at phase 5 the same way and resumes when the secret is in the secrets file.
 - **Changes mid-run:** applied from that point. What was created is kept and recorded, never silently deleted.
-- **Language:** messages to the person in the language they wrote in; the repository's files in English, its `README.md` and `DEPLOY.md` in the organization's language.
+- **Language:** messages to the person in the language they wrote in; the repository's files in English, its `README.md` and `DEPLOY.md` in the language the person wrote in, unless they name another.
 
 ## Requirements
 
@@ -32,7 +32,7 @@ What goes in: an AWS account, a domain on Cloudflare or one to buy, and the answ
 | A shell with Node.js 24 or newer, git, curl, jq and the AWS CLI v2 (`aws --version`); on Windows, Git Bash with `export MSYS_NO_PATHCONV=1`, since Git Bash otherwise rewrites an argument that starts with `/` (a log group, a parameter) into a Windows path before a program sees it | Every command of the run; the deployment repository |
 | The deployer's access key and the Cloudflare token, as [access.md](references/access.md) says they are made and reach the agent | Everything on AWS and at Cloudflare |
 | The `gh` command signed in (`gh auth status`), or an empty private repository the person made | The deployment repository, its first push, watching its runs |
-| The `console` command, `npm install -g @skillcdn/console` in phase 1 | The proof at the end: an agent connected, a file handed in; and this skill's two scripts, which the package carries at `$(npm root -g)/@skillcdn/console/skills/deploying-a-console/scripts/`, copied into the run's `scratch/` folder, or read through the connection and written there |
+| The `console` command, `npm install -g @skillcdn/console` in phase 1 | The proof at the end: an agent connected, a file handed in; and this skill's two scripts, which the package carries at `$(npm root -g)/@skillcdn/console/skills/deploying-a-console/scripts/`, copied into the run's `scratch/` folder, or read through the connection and written there; and the skill building-a-console, beside this one at `$(npm root -g)/@skillcdn/console/skills/building-a-console/SKILL.md` or through the connection, for the look and `console-ui/` |
 | The person, with a browser on any device | The GitHub App or the Google client, the first sign-in, approving the agent's code, a registrar's nameservers |
 | Network access to AWS, Cloudflare, GitHub and npm | |
 
@@ -42,19 +42,20 @@ Check these before the first message. Without the AWS CLI, offer to install it (
 
 | Input | Source |
 |---|---|
-| How many people | Asked: "How many people will use the console within a year: just you, up to 10, up to 30, or up to 100?" The answer picks the size ([sizing.md](references/sizing.md)). |
-| The board's name | Suggested from the convention and confirmed, never invented: the organization or the person the console is for, then Console, as `SkillCDN Console` is named. With the organization's name in the request or on its website: "The board will be called `Acme Console`, as consoles are named: the organization's name, then Console. Keep it, or say another?" Without one: "Whose console is this, your organization's or yours? Its name, then Console, is what the board is called." It goes to `WORKSPACE_NAME`, one line of up to 100 characters: what the pages say after the SkillCDN mark, and what the console calls itself at SkillCDN when it connects a pack. |
-| The web address | Asked: "Which web address should the console have? A domain you already own, and where it is registered (I set it up on Cloudflare; you change its nameservers there once, and I give you the steps), or should I find one to buy (I show the price before buying)? I suggest `console.<domain>`." A domain is needed: the tunnel has no free hostname. A domain that already serves the organization's site is fine: only the console's hostname is added to its zone, and nothing of the site is touched (resources.md "A zone that serves other hosts"). |
+| How many people | Asked: "How many people will use the console within a year: just you, up to 10, up to 30, or up to 100?" The answer picks the size ([sizing.md](references/sizing.md)); more than 100 is `large` with its numbers raised at the plan, and said so. |
+| The board's name | Suggested from the convention and confirmed, never invented: the organization or the person the console is for, then Console, as `SkillCDN Console` is named. With the organization's name in the request or on its website: "The board will be called `Acme Console`, as consoles are named: the organization's name, then Console. Keep it, or say another?" With an organization and no name: "What is your organization's name? Its name, then Console, is what the board is called." Without either: "Whose console is this, your organization's or yours? Its name, then Console, is what the board is called." It goes to `WORKSPACE_NAME`, one line of up to 100 characters: what the pages say after the mark, and what the console calls itself at SkillCDN when it connects a pack. |
+| The web address | Asked: "Which web address should the console have? A domain you already own, and where it is registered (I set it up on Cloudflare; you change its nameservers at your registrar once, and I give you the steps; your website and your mail keep working, since their records come over as they are), or should I find one to buy (I show the price before buying)? I suggest `console.<domain>`." A domain is needed: the tunnel has no free hostname. A domain that already serves the organization's site is fine: only the console's hostname is added to its zone, and nothing of the site is touched (resources.md "A zone that serves other hosts"). |
 | How people sign in, and who | Asked: "How should people sign in: with GitHub, with Google (Workspace), or both? Who configures the console (you, at least): their GitHub login or Google address. With GitHub, everyone of your organization can be in, as the organization has them: say which organization. With a Google Workspace, everyone of the domain is in. Anyone else, an administrator lets in on the People page once the console runs." |
 | The organization's skills | Asked: "Where are your organization's skills on SkillCDN, if anywhere yet? An address like `/gh/<owner>/<repo>`. Is that repository private?" Default: none; a project names one later on its Settings page. A private one is connected in phase 6, with a code the person approves at SkillCDN ([ADR-0036](/docs/adr/0036-a-private-pack-is-connected-with-a-code-a-person-approves-from-the-projects-settings.md)); nothing of it is needed before. |
 | The organization's website, and the look | Asked: "Does your organization have a website? Its address." With one, the console takes the organization's look by default: the marks, the colours and the type read from the site as building-a-console's [the-look-from-a-website.md](/skills/building-a-console/references/the-look-from-a-website.md) says, mapped onto the pages and shown at the plan, and built into the image as the organization's own console, `console-ui/` of the deployment repository, so that the first deploy already carries it. Without a site, or when the person says the default pages are fine, the image's default pages serve: the board's name alone, and no marks. A look that is wanted later is the same skill, building-a-console, in `console-ui/`, and a push. |
+| The plugins | Asked only when the request names one, or the organization's console is to carry a feature of its work (leave, customers, money): "Should the console carry a plugin? Which package, at which version or tag?" Default: none. A plugin is installed by building it into the image from `plugins/package.json` and its lockfile in the deployment repository, with no install scripts ([deploy/README.md "Plugins in the image"](/deploy/README.md#plugins-in-the-image)), and enabled by the administrator on the console's settings page once it runs, consenting to what it asks; one with `storage:sql` needs the database user to hold `CREATEROLE`, which the master user of phase 3's database does. One wanted later is a row of [running-it-again.md](references/running-it-again.md); one to be written is [building-a-plugin](/skills/building-a-plugin/SKILL.md). |
 | The AWS account | Asked: "Do you have an AWS account for this, or should the console get an account of its own (the simplest to run and to read the bill of)?" A new account is made by the person, on the paid plan, with the order of cost already in front of them (the second message). |
-| The region | Asked when the organization's country does not say: "Which AWS region: the one nearest your people?" Default: the nearest to where the organization is (`ap-northeast-2`, Seoul, for Korea; `ap-northeast-1` for Japan; `eu-central-1` for central Europe; `us-east-1` for the eastern United States). |
+| The region | Asked when the organization's country does not say: "Where are most of your people: a country, or a city?" The region is the one nearest them: `ap-northeast-2` (Seoul), `ap-northeast-1` (Tokyo), `ap-southeast-1` (Singapore), `eu-central-1` (Frankfurt), `eu-west-1` (Ireland), `eu-west-2` (London), `us-east-1` (N. Virginia), `us-east-2` (Ohio), `us-west-2` (Oregon); `aws ec2 describe-regions` lists them all, and sizing.md says how a region's prices are read. |
 | The run's folder | Asked with a suggestion: "Which folder should the deployment live in on this machine? I suggest `console-deploy` under your home folder." It is made at once and becomes the deployment repository. |
 | The deployment repository | Asked: "Where should the deployment's files live on GitHub: a private repository under your account, or under an organization you name?" Its name is the folder's. |
 | Where alerts go | Asked: "Which email should the cost alert go to?" |
 | The console's version | Derived: the latest release of the console, the tag `@skillcdn/console@<version>` of its repository: the last line of `git ls-remote --tags https://github.com/skillcdn/console 'refs/tags/@skillcdn/console@*' \| sort -t@ -k3 -V` is the highest version, and its first column the commit (an annotated tag lists its commit on a `^{}` line, which sorts last the same way), pinned in the deployment repository as `CONSOLE_REF`. An organization's own console (building-a-console) depends on the package at that same version, so that the pages and the server are one release. An update is the next tag, a new commit there. |
-| Everything else | Derived and shown in the plan: the size's numbers, the names (`console` for the cluster and the database, `api` and `worker` for the services, `console-files-<account id>` for the bucket), the generated secrets (`AUTH_SECRET`, the database password), the variables of [deploy/README.md](/deploy/README.md) with the tunnel's settings (`TRUSTED_PROXIES=127.0.0.1,::1`, `CLIENT_IP_HEADER=cf-connecting-ip`, `HTTP_KEEP_ALIVE_SECONDS=100`) and the bucket read and written as the task's own role (`S3_CREDENTIALS=platform`), so that no key exists for it; the connector's image, mirrored into the organization's image repository; the estimate of this size and the next, the budget alert at one and a half times the estimate, the rate limiting rule on the sign-in paths, and what the person does once. |
+| Everything else | Derived and shown in the plan: the size's numbers and the names of everything made (resources.md "Phase 2"); the generated secrets (`AUTH_SECRET`, the database's password); the variables of [deploy/README.md](/deploy/README.md) with the tunnel's settings (`TRUSTED_PROXIES=127.0.0.1,::1`, `CLIENT_IP_HEADER=cf-connecting-ip`, `HTTP_KEEP_ALIVE_SECONDS=100`) and the bucket read and written as the task's own role (`S3_CREDENTIALS=platform`), so that no key exists for it; the connector's image, mirrored into the organization's image repository; the estimate of this size and the next, the budget alert at one and a half times the estimate, the rate limiting rule on the sign-in paths, and the few steps the person takes once. |
 
 ## Workflow
 
@@ -70,11 +71,11 @@ Produces the **plan**, shown at the checkpoint. From the answers: the size and w
 
 ### Phase 3: Foundation
 
-Produces the **resource record**: each resource with its name and id. In this order: the zone at Cloudflare, with the records the domain serves already found by Cloudflare's scan and checked by the person against their registrar's DNS page, so that nameservers propagate meanwhile; the network and its two security groups; the database, started, and waited for while the rest is made; the bucket; the image repository, the log group, the roles, the task's with the bucket's policy, the cluster; the tunnel, the hostname, always-HTTPS for the hostname and the rate limiting rule; the parameters, generated and derived, from the secrets file. Then, the hostname being known, the message for each secret the person holds (access.md "The GitHub App", "The OAuth client"): "Save it in the secrets file as the line I show, or say `later` and that way of signing in stays off until it is set." A value the person pastes into the chat instead is written into the file by the agent's file tool, never repeated, and the person is told to generate a new one once the run is over, since the chat kept a copy; the new one goes in as "a secret rotated" of the record.
+Produces the **resource record**: each resource with its name and id. In this order: the zone at Cloudflare, with the records the domain serves already found by Cloudflare's scan and checked by the person against their registrar's DNS page, so that nameservers propagate meanwhile; the network and its two security groups; the database, started, and waited for while the rest is made; the bucket; the image repository, the log group, the roles, the task's with the bucket's policy, the cluster; the tunnel, the hostname, always-HTTPS for the hostname and the rate limiting rule; the parameters, generated and derived, from the secrets file. The message for each secret the person holds (access.md "The GitHub App", "The OAuth client") goes out right after the plan's word, the hostname being fixed there, so that they do it while the foundation is made: "Save it in the secrets file as the line I show, or say `later` and that way of signing in stays off until it is set." A value the person pastes into the chat instead is written into the file by the agent's file tool, never repeated, and the person is told to generate a new one once the run is over, since the chat kept a copy; the new one goes in as "a secret rotated" of the record.
 
 ### Phase 4: The deployment repository
 
-Produces the **repository**: `deploy/console.env`, the task definitions `deploy/migrate.task.json`, `deploy/api.task.json` and, at the large size, `deploy/worker.task.json`, the workflow `.github/workflows/deploy.yml`, `README.md` and a draft `DEPLOY.md`, as resources.md gives them, every value filled from the record; with the organization's look, `console-ui/`, the organization's own console made here with building-a-console at the console's pinned version, from the look approved at the plan, which the workflow builds into the image on every push (resources.md "The organization's own console"); and on AWS the role the workflow assumes, trusted for this repository's `main` alone. Show the files, each with the lines that matter pointed out for a person who is not a developer, and the look's pages where a browser can be driven; commit; create the empty private repository. Checkpoint: "Pushing starts the first build (about ten minutes), runs the migrations, and starts the console at <hostname>. OK?" On the word, push, and watch the run to its end.
+Produces the **repository**: `deploy/console.env`, the task definitions `deploy/migrate.task.json`, `deploy/api.task.json` and, at the large size, `deploy/worker.task.json`, the workflow `.github/workflows/deploy.yml`, `README.md` and a draft `DEPLOY.md`, as resources.md gives them, every value filled from the record; with the organization's look, `console-ui/`, the organization's own console made here with building-a-console at the console's pinned version, from the look approved at the plan, which the workflow builds into the image on every push (resources.md "The organization's own console"); with a plugin named at the plan, `plugins/package.json` and its lockfile, which the workflow installs into the image (resources.md "The plugins"); and on AWS the role the workflow assumes, trusted for this repository's `main` alone. Show the files, each with the lines that matter pointed out for a person who is not a developer, and the look's pages where a browser can be driven; commit; create the empty private repository. Checkpoint: "Pushing starts the first build (about ten minutes), runs the migrations, and starts the console at <hostname>. OK?" On the word, push, and watch the run to its end.
 
 ### Phase 5: Live
 
@@ -90,11 +91,11 @@ Produces the **proof**: `console task new "Deployment check"` with a body that s
 
 ### Phase 8: Record and delivery
 
-Produces **`DEPLOY.md`** in the repository, from the template in resources.md: what exists under which names, the size and its estimate, how a deploy happens, how to add a member, update, grow, rotate a secret, pause and remove, and what is owed. Checkpoint: "Committing and pushing the record. OK?" (a change to the record alone does not redeploy). Then, on the person's word, delete the secrets file and the token file. Deliver in one message: the address, what was made in the person's words, the estimate and the alert, what the person still owes (a `later` secret, nameservers), what was verified and how, and how the console is operated from here: the record, and a push.
+Produces **`DEPLOY.md`** in the repository, from the template in resources.md: what exists under which names, the size and its estimate, how a deploy happens, how to add a member, update, grow, rotate a secret, pause and remove, and what is owed. Checkpoint: "Committing and pushing the record. OK?" (a change to the record alone does not redeploy). Then, on the person's word, delete the secrets file and the token file; the profile `console` stays in the AWS CLI's credentials, since the record's commands run as it, until the deployment is removed. Deliver in one message: the address, what was made in the person's words, the estimate and the alert, what the person still owes (a `later` secret, nameservers), what was verified and how, and how the console is operated from here: the record, and a push.
 
 ### Running it again
 
-The same skill, from phase 2, with the plan naming only what changes: a new version (the next release tag's commit as `CONSOLE_REF` in `deploy/console.env`, with `console-ui/` moved to the same version of the package when there is one, a push), a new connector (`CLOUDFLARED_VERSION` there, a push), the next size (the numbers in the task definitions and a push; the database's class with one command, as sizing.md "Growing" says), a person let in or taken out (on the People page, or `console person add <login>` and `console person deactivate <login>`, by an administrator; no push), a secret rotated (the parameter overwritten, the service rolled), the console paused or removed (resources.md "Removing"). Each is confirmed at the plan, and the record is updated with it.
+The same skill, from phase 2, with the plan naming only what changes and its price: a new version of the console or of the connector, a plugin installed, updated or removed, the next size, a person let in or taken out, a secret rotated, a console shared with outside teams or customers, the console paused or removed. What each takes is in [running-it-again.md](references/running-it-again.md); each is confirmed at the plan, and the record is updated with it.
 
 ### Verdicts
 
@@ -112,7 +113,7 @@ The same skill, from phase 2, with the plan naming only what changes: a new vers
 3. The first push is confirmed, and every push after it: once the repository is connected, a push is a deployment, which the person chose at the plan.
 4. The person is never asked to do what the key and the token can do; what only they can do (a GitHub App or a Google client, a sign-in, approving a code, nameservers at their registrar) is given as the exact steps of the day in one message, for the registrar they named where its steps are known and in general words otherwise, so that they can do it while the run goes on.
 5. Nothing of the deployment listens on the internet: the tasks' security group has no inbound rule, the database is not publicly accessible, the bucket blocks public access, and the hostname reaches the console only through the tunnel.
-6. Names and ids go into the repository and the record; a value a secret scanner would flag never does, and `scratch/`, the key file and the token file never enter git. Every file the repository gets is shown before it is pushed.
+6. Names and ids go into the repository and the record; a value a secret scanner would flag never does, and `scratch/`, the key file and the token file never enter git. Every file written by hand is shown before it is pushed; a generated file (a lockfile, a build) is named.
 7. What was created is kept and recorded, never silently deleted; removing the deployment is a run of its own, asked for, and confirmed resource by resource.
 8. The console's contract holds on every rollout: `migrate` runs and exits `0` before the new `api` and `worker` start, as the one-off task of the workflow, or, without a pipeline, as a container of every task of both roles that its own container waits on (resources.md "Without a pipeline"); the stop timeout stays above the shutdown grace period, and no secret is a build argument.
 
@@ -120,13 +121,10 @@ The same skill, from phase 2, with the plan naming only what changes: a new vers
 
 | Term | Meaning |
 |---|---|
-| Size | `small`, `medium` or `large`: the numbers of sizing.md, chosen by how many people. |
-| The deployer | The IAM user whose key the agent acts with, as the profile `console` of the AWS CLI. |
-| The task's role | The role the containers run as, `console-task`, whose credentials the platform hands them and renews: it may read and write the bucket, and nothing else; no key exists for the files. |
-| The run's folder | The folder the person chose, which becomes the deployment repository; `scratch/`, the key file and the token file in it never enter git; the secrets file is beside it, in the folder above. |
+| The deployer | The IAM user whose key the agent acts with, the profile `console` of the AWS CLI. |
+| The task's role | `console-task`, the role the containers run as, with credentials the platform hands them and renews: it may read and write the bucket, and nothing else; no key exists for the files. |
+| The run's folder | The folder the person chose, which becomes the deployment repository; `scratch/`, the key file and the token file in it never enter git. |
 | The tunnel | The Cloudflare Tunnel whose connector runs beside the `api` container; the hostname's traffic comes in through it and nothing else does. |
-| Task, service | On ECS, a task is the containers of one role running together; a service keeps the wanted number of tasks running and rolls them to a new definition. |
-| Parameter | A value in SSM Parameter Store that a task reads as an environment variable at start. |
-| The deployment repository | The private repository of the task definitions, the workflow and the record; a push to it is a deployment. |
-| `DEPLOY.md` | The record: what exists under which names, how it is run, what is owed, what it costs. |
-| Later | A secret the person did not supply; the way of signing in it serves stays off, and the record says so. |
+| Task, service, parameter | On ECS, a task is the containers of one role running together, and a service keeps the wanted number of tasks running and rolls them to a new definition; a parameter is a value in SSM Parameter Store that a task reads as an environment variable at start. |
+| The deployment repository, the record | The private repository of the task definitions, the workflow and `DEPLOY.md`, the record of what exists under which names, how it is run, what is owed and what it costs; a push to it is a deployment. |
+| The secrets file; the key file and the token file | `console-secrets.json` in the folder above the run's folder, the values the person holds and the run generates, each stored as a parameter (access.md); `.aws-key.csv` and `.cf-token` in the run's folder, saved there by the person and read by the agent into the profile and the header file. None enters git, and each is deleted when the run is over, the secrets file on the person's word. |

package/skills/deploying-a-console/references/access.md

@@ -44,26 +44,28 @@ The first answers with the account id the plan names; the second with the defaul
 | Zone | Zone WAF | Edit | The rate limiting rule |
 | Account | Registrar | Edit | Only when a domain is to be bought in the run |
 
-Zone Resources: Include, All zones, so that a zone made in the run is covered. Account Resources: the one account. Client IP filtering: none. TTL: none, or a year. Continue to summary, Create Token, copy the secret once. Read where Edit is needed is the mistake to look for: a token with Read lists tunnels and rules and fails only at the first creation, with `403` and code `10000` (resources.md "When a step fails").
+Ask for every row at once, Registrar excepted, which is asked only when a domain is to be bought: whether the zone serves other hosts, which decides between Zone Settings and Dynamic URL Redirects, is learned only once the token exists. Zone Resources: Include, All zones, so that a zone made in the run is covered. Account Resources: the one account. Client IP filtering: none. TTL: none, or a year. Continue to summary, Create Token, copy the secret once. Read where Edit is needed is the mistake to look for: a token with Read lists tunnels and rules and fails only at the first creation, with `403` and code `10000` (resources.md "When a step fails").
 
 **How it reaches the agent.** Save it in a file named `.cf-token` in the run's folder (a file without an extension: in Notepad, "All files" as the type, so that it is not `.cf-token.txt`), and tell the agent; the agent reads it into the environment for each call and never prints it. The file is listed in the deployment repository's `.gitignore` from the first commit, and deleted at the end of the run on the person's word. A token pasted into the chat is written into the file with the agent's file tool and never repeated, and the person is told to make a new token once the run is over, since the chat kept a copy.
 
 **Verify:**
 
 ```sh
-CLOUDFLARE_API_TOKEN=$(tr -d '\r\n ' < .cf-token)
-curl -s https://api.cloudflare.com/client/v4/user/tokens/verify -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN"
-curl -s https://api.cloudflare.com/client/v4/zones -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN"
-curl -s https://api.cloudflare.com/client/v4/accounts -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN"
+printf 'Authorization: Bearer %s\n' "$(tr -d '\r\n ' < .cf-token)" > scratch/auth.txt
+curl -s https://api.cloudflare.com/client/v4/user/tokens/verify -H @scratch/auth.txt
+curl -s https://api.cloudflare.com/client/v4/zones -H @scratch/auth.txt
+curl -s https://api.cloudflare.com/client/v4/accounts -H @scratch/auth.txt
 ```
 
-`"status": "active"`, the zones the token sees (the domain among them, or none yet), and the account with its id; the last call is refused without Account Settings Read, which is fine when the zone exists and carries the id. The file carries a carriage return on Windows; the `tr` strips it. These calls prove the token is live, not what it may change: Read lists exactly what Edit lists.
+`"status": "active"`, the zones the token sees (the domain among them, or none yet), and the account with its id; the last call is refused without Account Settings Read, which is fine when the zone exists and carries the id. The file carries a carriage return on Windows; the `tr` strips it, and the header goes to `curl` from a file in `scratch/`, never on a command line. These calls prove the token is live, not what it may change: Read lists exactly what Edit lists.
 
 ## The git host
 
 **The deployment repository.** The organization's deployment lives in a private repository on GitHub: the task definitions, the workflow that builds and deploys, the record. The agent makes it with the `gh` command signed in (`gh auth status`; `gh auth login` otherwise, which opens the browser for the person) under the owner the person names: their account, or an organization. Without `gh`, the person creates an empty private repository in the browser (New repository, private, no README) and gives its address, and the agent pushes to it.
 
-**The GitHub App, for signing in with GitHub, and for the organization to say who is in.** One app does both ([ADR-0022](/docs/adr/0022-who-is-in-is-the-consoles-own-record-and-an-administrator-keeps-it.md)): its client signs people in, and, installed on the organization, it lets the console read who is a member, at sign-in and every ten minutes after. Once the console's address is known, the person, signed in to GitHub as an owner of the organization (checked 2026-10): Your organizations, Settings next to the organization, Developer settings, GitHub Apps, New GitHub App.
+### The GitHub App, for signing in with GitHub, and for the organization to say who is in
+
+One app does both ([ADR-0022](/docs/adr/0022-who-is-in-is-the-consoles-own-record-and-an-administrator-keeps-it.md)): its client signs people in, and, installed on the organization, it lets the console read who is a member, at sign-in and every ten minutes after. Once the console's address is known, the person, signed in to GitHub as an owner of the organization (checked 2026-10): Your organizations, Settings next to the organization, Developer settings, GitHub Apps, New GitHub App.
 
 - GitHub App name: the board's name (34 characters at most, unique across GitHub).
 - Homepage URL: the console's address, `https://<hostname>`.
@@ -71,12 +73,14 @@ curl -s https://api.cloudflare.com/client/v4/accounts -H "Authorization: Bearer
 - Webhook: untick Active. The console takes no webhooks.
 - Permissions: under Organization permissions, Members: Read-only. Nothing else, and no repository permission: the console reads who is in, and nothing of the code.
 - Where can this GitHub App be installed?: Only on this account.
-- Create GitHub App. The app's page shows the **App ID** and the **Client ID**: copy both into the chat (neither is secret). Under Client secrets, Generate a new client secret, and save it to the secrets file as `GITHUB_CLIENT_SECRET` (below), as the line the agent shows. Under Private keys, Generate a private key: a `.pem` file downloads; save its content to the secrets file as `GITHUB_APP_PRIVATE_KEY`, the file's lines joined with `\n`, as the line the agent shows (the agent writes it from the file when told where it is, and deletes the file on the person's word). A secret pasted into the chat instead is written into the file by the agent's file tool and never repeated, and the person generates a new one once the run is over, since the chat kept a copy; the new one goes in as "a secret rotated" of the record.
+- Create GitHub App. The app's page shows the **App ID** and the **Client ID**: copy both into the chat (neither is secret). Under Client secrets, Generate a new client secret, and save it to the secrets file as `GITHUB_CLIENT_SECRET` (below), as the line the agent shows. Under Private keys, Generate a private key: a `.pem` file downloads; tell the agent where the file is, and it writes the key into the secrets file as `GITHUB_APP_PRIVATE_KEY` whole and deletes the file on the person's word; by hand instead, the file's lines joined with `\n`, as the line the agent shows. A secret pasted into the chat instead is written into the file by the agent's file tool and never repeated, and the person generates a new one once the run is over, since the chat kept a copy; the new one goes in as "a secret rotated" of the record.
 - Install App, in the app's left sidebar: Install next to the organization, and confirm. No repository access is asked for, since the app has no repository permission. Everyone of the organization is in from then on, as the organization has them; the plan's `GITHUB_ORG` is the organization's login, as it reads in `github.com/<login>`.
 
 Without an organization, an OAuth app signs people in as well (Developer settings, OAuth Apps, New OAuth App: the same name, homepage and callback; Register application; the Client ID and a client secret), and an administrator lets each person in on the People page. No scopes are needed either way: the console asks only who the person is.
 
-**The OAuth client, for signing in with Google.** In the Google Cloud console, a project of the organization's, Google Auth Platform (checked 2026-10): if the project has not registered with Google Auth yet, the Overview asks for the app's name, a support address and the audience (Internal, for a Workspace organization), once. Then Clients, Create client, Application type **Web application**, name it, under Authorized redirect URIs add `https://<hostname>/auth/google/callback`, Create. Copy the **Client ID** into the chat; the client secret is shown once: save it to the secrets file as `GOOGLE_CLIENT_SECRET`, as the line the agent shows (pasted instead: written to the file by the agent, never repeated, and replaced after the run, as with GitHub's). The Workspace domain, when everyone of it is a member, is the plan's `GOOGLE_WORKSPACE_DOMAIN`. Changes take from minutes to hours to be effective at Google.
+### The OAuth client, for signing in with Google
+
+In the Google Cloud console, a project of the organization's, Google Auth Platform (checked 2026-10): if the project has not registered with Google Auth yet, the Overview asks for the app's name, a support address and the audience (Internal, for a Workspace organization), once. Then Clients, Create client, Application type **Web application**, name it, under Authorized redirect URIs add `https://<hostname>/auth/google/callback`, Create. Copy the **Client ID** into the chat; the client secret is shown once: save it to the secrets file as `GOOGLE_CLIENT_SECRET`, as the line the agent shows (pasted instead: written to the file by the agent, never repeated, and replaced after the run, as with GitHub's). The Workspace domain, when everyone of it is a member, is the plan's `GOOGLE_WORKSPACE_DOMAIN`. Changes take from minutes to hours to be effective at Google.
 
 ## The secrets file
 

package/skills/deploying-a-console/references/resources.md

@@ -9,13 +9,13 @@ The run's folder is the deployment repository to be; `scratch/` in it holds the
 ```bash
 export MSYS_NO_PATHCONV=1                 # Git Bash on Windows: keep /console and the like as written
 export AWS_PROFILE=console AWS_REGION=<region>
-export CLOUDFLARE_API_TOKEN=$(tr -d '\r\n ' < .cf-token)
-cf() { curl -sS "https://api.cloudflare.com/client/v4$1" -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" -H "Content-Type: application/json" "${@:2}"; }
+printf 'Authorization: Bearer %s\n' "$(tr -d '\r\n ' < .cf-token)" > scratch/auth.txt   # the header from a file, never on a command line
+cf() { curl -sS "https://api.cloudflare.com/client/v4$1" -H @scratch/auth.txt -H "Content-Type: application/json" "${@:2}"; }
 ACCOUNT=$(aws sts get-caller-identity --query Account --output text)
 SECRETS=../console-secrets.json          # outside the repository; made by the first `set` below, never a copy of assets/secrets.example.json
 ```
 
-Every id the run makes or finds (`CF_ACCOUNT`, `ZONE`, `VPC`, `SUBNETS`, `TASKS_SG`, `DB_SG`, `ENDPOINT`, `BUCKET`, `TUNNEL`, the rules' ids) goes into `scratch/notes.md` as it is made, as a line `NAME=value`, and a new shell sets them again from there (`set -a; . scratch/notes.md; set +a` when the file holds nothing but such lines): phases 5 to 7 come after a ten-minute watch, or after a pause of hours, almost always in a new shell.
+Every id the run makes or finds (`CF_ACCOUNT`, `ZONE`, `VPC`, `SUBNETS`, `TASKS_SG`, `DB_SG`, `ENDPOINT`, `BUCKET`, `TUNNEL`, the rules' ids) goes into `scratch/notes.md` as it is made, as a line `NAME=value`, and a new shell sets them again from there (`set -a; . scratch/notes.md; set +a` when the file holds nothing but such lines): phases 5 to 7 come after a ten-minute watch, or after a pause of hours, almost always in a new shell. Where every command runs in a new shell, as some agents' tools do, the lines above go in `scratch/env.sh`, sourced at the start of every command; a wait longer than one command may take (the database, the workflow's run, a sign-in) runs in the background or is polled.
 
 A value that must not be seen goes through a file or a pipe, never a command line: `aws ... --cli-input-json file://scratch/<file>` for a request that carries one, and the two scripts of this skill ([import-aws-key.mjs](../scripts/import-aws-key.mjs), [store-secrets.mjs](../scripts/store-secrets.mjs)), copied to `scratch/`, for the key and the parameters. A response that carries one is piped straight into the secrets file:
 
@@ -30,8 +30,8 @@ node -e "process.stdout.write(require('node:crypto').randomBytes(36).toString('b
 2. The command and the scripts: `npm install -g @skillcdn/console`, then copy `$(npm root -g)/@skillcdn/console/skills/deploying-a-console/scripts/*.mjs` into `scratch/` (or write them there from the connection's copy of the skill).
 3. The key: the person saved `.aws-key.csv` in the folder ([access.md](access.md)). `node scratch/import-aws-key.mjs .aws-key.csv console` writes the profile and deletes the file. Then `aws configure set region <region> --profile console`.
 4. `aws sts get-caller-identity`: the account id and `user/console-deployer`. A refusal means the key is wrong or not yet active (a minute after creation).
-5. The network: `aws ec2 describe-vpcs --filters Name=is-default,Values=true --query 'Vpcs[0].VpcId' --output text`. `None`: `aws ec2 create-default-vpc`. Then the subnets: `aws ec2 describe-subnets --filters Name=vpc-id,Values=<vpc> Name=default-for-az,Values=true --query 'Subnets[].SubnetId' --output text`.
-6. The token: `cf /user/tokens/verify` answers `"status": "active"`; `cf "/zones?name=<domain>" > scratch/zone.json` the zone, with its id, its `status` and its account (`ZONE=$(jq -r '.result[0].id' scratch/zone.json)`, `CF_ACCOUNT=$(jq -r '.result[0].account.id' scratch/zone.json)`), or an empty list when the domain is not on Cloudflare yet, in which case `CF_ACCOUNT=$(cf /accounts | jq -r '.result[0].id')` and `ZONE` waits for phase 3. A zone that exists: `cf "/zones/$ZONE/dns_records" | jq '.result | length'`; records of its own mean the zone serves the organization's site already, which the access record says and phase 3 "A zone that serves other hosts" acts on.
+5. The network: `aws ec2 describe-vpcs --filters Name=is-default,Values=true --query 'Vpcs[0].VpcId' --output text`. `None`: phase 3 "The network" makes one. Then the subnets, once there is a VPC: `aws ec2 describe-subnets --filters Name=vpc-id,Values=<vpc> Name=default-for-az,Values=true --query 'Subnets[].SubnetId' --output text`.
+6. The token: `cf /user/tokens/verify` answers `"status": "active"`; `cf "/zones?name=<domain>" > scratch/zone.json` the zone, with its id, its `status` and its account (`ZONE=$(jq -r '.result[0].id' scratch/zone.json)`, `CF_ACCOUNT=$(jq -r '.result[0].account.id' scratch/zone.json)`), or an empty list when the domain is not on Cloudflare yet, in which case `CF_ACCOUNT=$(cf /accounts | jq -r '.result[0].id')` and the zone is made now, as "The zone, first" says: the one thing made before the plan, since it costs nothing, is undone as easily, and its nameservers must reach the person in the second message. A zone that exists: `cf "/zones/$ZONE/dns_records" | jq '.result | length'`; records of its own mean the zone serves the organization's site already, which the access record says and phase 3 "A zone that serves other hosts" acts on.
 7. The git host: `gh auth status`; the owner the person named is theirs or an organization they are in (`gh api user`, `gh api user/orgs`).
 8. The tools: `node --version` (24 or newer), `git --version`, `jq --version`, `curl --version`.
 
@@ -39,7 +39,7 @@ Report what is missing in one message, with the row of access.md to add, before
 
 ## Phase 2: Plan and estimate
 
-Nothing is created. The size from the answer and its numbers ([sizing.md](sizing.md) "The sizes"); the prices read and the estimate computed ("Reading today's prices"); the names:
+Nothing is created, but for the zone of phase 1, which costs nothing. The size from the answer and its numbers ([sizing.md](sizing.md) "The sizes"); the prices read and the estimate computed ("Reading today's prices"); the names:
 
 | Resource | Name |
 |---|---|
@@ -59,10 +59,12 @@ The plan message is the estimate message of sizing.md followed by the line in th
 
 ### The zone, first
 
-Not on Cloudflare yet: `cf /zones -X POST --data '{"name":"<domain>","account":{"id":"'$CF_ACCOUNT'"},"type":"full"}'`, then `ZONE=$(cf "/zones?name=<domain>" | jq -r '.result[0].id')`. Before the nameservers change, the zone must carry what the domain serves already (its site, its mail), or that stops working at the switch: `cf "/zones/$ZONE/dns_records/scan" -X POST` has Cloudflare find the common records and add them (checked 2026-10), `cf "/zones/$ZONE/dns_records" | jq -r '.result[] | "\(.type) \(.name) \(.content)"'` lists what the zone now has, and the list goes to the person with the nameserver steps: "Compare this with the DNS page at your registrar and send me anything that is missing", each missing one added with `cf "/zones/$ZONE/dns_records" -X POST --data '{"type":"<MX | A | CNAME | TXT>","name":"<name>","content":"<value>","priority":<MX only>,"ttl":1}'`. The answer's `name_servers` go to the person with the steps for their registrar (access.md "The domain"), the run goes on, and the hostname answers once `cf "/zones?name=<domain>"` says `"status": "active"`. A domain to buy: `cf "/accounts/$CF_ACCOUNT/registrar/domain-search?q=<words>"` to find one, `cf "/accounts/$CF_ACCOUNT/registrar/domain-check" -X POST --data '{"domains":["<domain>"]}'` for the live price, the checkpoint with the price and the renewal, then `cf "/accounts/$CF_ACCOUNT/registrar/registrations" -X POST --data '{"domain_name":"<domain>"}'`; a `202` is polled at `.../registrations/<domain>/registration-status`. Buying through the API was in beta when checked (2026-10) and is not open to every account: `extension_not_supported_via_api`, a `404` or a route error means the person buys in the dashboard (Domain Registration, Register Domains), with the price in front of them there. A bought domain's zone is active at once, and `ZONE` is read as above.
+Not on Cloudflare yet, and not made in phase 1: `cf /zones -X POST --data '{"name":"<domain>","account":{"id":"'$CF_ACCOUNT'"},"type":"full"}' > scratch/zone.json`, then `ZONE=$(jq -r .result.id scratch/zone.json)`, and the nameservers are `jq -r '.result.name_servers[]' scratch/zone.json`. Before the nameservers change, the zone must carry what the domain serves already (its site, its mail), or that stops working at the switch: `cf "/zones/$ZONE/dns_records/scan" -X POST` has Cloudflare find the common records and add them (checked 2026-10), `cf "/zones/$ZONE/dns_records" | jq -r '.result[] | "\(.type) \(.name) \(.content)"'` lists what the zone now has, and the list goes to the person with the nameserver steps: "Compare this with the DNS page at your registrar and send me anything that is missing", each missing one added with `cf "/zones/$ZONE/dns_records" -X POST --data '{"type":"<MX | A | CNAME | TXT>","name":"<name>","content":"<value>","priority":<MX only>,"ttl":1}'`. Each record the scan added is checked for `proxied` (`cf "/zones/$ZONE/dns_records" | jq -r '.result[] | "\(.id) \(.name) \(.proxied)"'`): a record of the organization's site or mail is set `"proxied":false` (`cf "/zones/$ZONE/dns_records/<id>" -X PATCH --data '{"proxied":false}'`), so that it comes over as it is and nothing of the site passes through Cloudflare until the person asks for that; and the zone's SSL mode (`cf "/zones/$ZONE/settings/ssl"`) is read and said at the plan, since a site proxied later needs `full` or `strict` to keep serving its own certificate. The answer's `name_servers` go to the person with the steps for their registrar (access.md "The domain"), the run goes on, and the hostname answers once `cf "/zones?name=<domain>"` says `"status": "active"`. A domain to buy: `cf "/accounts/$CF_ACCOUNT/registrar/domain-search?q=<words>"` to find one, `cf "/accounts/$CF_ACCOUNT/registrar/domain-check" -X POST --data '{"domains":["<domain>"]}'` for the live price, the checkpoint with the price and the renewal, then `cf "/accounts/$CF_ACCOUNT/registrar/registrations" -X POST --data '{"domain_name":"<domain>"}'`; a `202` is polled at `.../registrations/<domain>/registration-status`. Buying through the API was in beta when checked (2026-10) and is not open to every account: `extension_not_supported_via_api`, a `404` or a route error means the person buys in the dashboard (Domain Registration, Register Domains), with the price in front of them there. A bought domain's zone is active at once, and `ZONE` is read as above.
 
 ### The network
 
+No default VPC (phase 1 found `None`): `aws ec2 create-default-vpc` first, free of charge, then its subnets as phase 1 reads them.
+
 ```sh
 VPC=<vpc>; SUBNETS=<subnet ids, comma-separated>
 TASKS_SG=$(aws ec2 create-security-group --group-name console-tasks --description "console tasks: no inbound" --vpc-id $VPC --query GroupId --output text)
@@ -213,7 +215,7 @@ In the run's folder, write:
 ```sh
 CONSOLE_REPOSITORY=https://github.com/skillcdn/console.git
 CONSOLE_REF=<the commit of the release tag pinned at the plan>
-CLOUDFLARED_VERSION=<the connector's release, such as 2026.10.0, from github.com/cloudflare/cloudflared/releases>
+CLOUDFLARED_VERSION=<the connector's newest release, which gh api repos/cloudflare/cloudflared/releases/latest --jq .tag_name prints>
 AWS_ACCOUNT_ID=<account id>
 AWS_REGION=<region>
 ECR_REPOSITORY=console
@@ -225,7 +227,7 @@ WORKER_COUNT=<0 | 0 | 1>
 PLATFORM=linux/amd64
 ```
 
-`PLATFORM=linux/arm64` with `cpuArchitecture` `ARM64` in the task definitions when the organization's builds run on ARM runners (sizing.md "Options").
+`PLATFORM=linux/arm64` with `cpuArchitecture` `ARM64` in the task definitions when the organization's builds run on ARM runners (sizing.md "Options the plan offers").
 
 ### `deploy/api.task.json`
 
@@ -316,7 +318,7 @@ name: Deploy the console
 on:
   push:
     branches: [main]
-    paths: ["deploy/**", "console-ui/**", ".github/workflows/deploy.yml"]
+    paths: ["deploy/**", "console-ui/**", "plugins/**", ".github/workflows/deploy.yml"]
   workflow_dispatch:
 permissions:
   id-token: write
@@ -356,6 +358,9 @@ jobs:
             (cd console-ui && npm ci && npm run build)
             printf 'FROM %s\nCOPY --chown=node:node console-ui/dist/ /app/web/\n' "$IMAGE" | docker build --platform "$PLATFORM" -t "$IMAGE" -f - .
           fi
+          if [ -f plugins/package.json ]; then
+            printf 'FROM node:24-bookworm-slim AS plugins\nWORKDIR /plugins\nCOPY plugins/package.json plugins/package-lock.json ./\nRUN npm ci --omit=dev --ignore-scripts\nFROM %s\nCOPY --from=plugins --chown=node:node /plugins/ /app/plugins/\nENV PLUGINS_DIR=/app/plugins\n' "$IMAGE" | docker build --platform "$PLATFORM" -t "$IMAGE" -f - .
+          fi
           docker push "$IMAGE"
           echo "IMAGE=$IMAGE" >> "$GITHUB_ENV"
       - name: Register the task definitions
@@ -431,11 +436,20 @@ aws iam put-role-policy --role-name console-github-deploy --policy-name console-
 
 `scratch/deploy-policy.json`: `ecr:GetAuthorizationToken` on `*`; `ecr:BatchCheckLayerAvailability`, `ecr:InitiateLayerUpload`, `ecr:UploadLayerPart`, `ecr:CompleteLayerUpload`, `ecr:PutImage`, `ecr:BatchGetImage`, `ecr:DescribeImages` on `arn:aws:ecr:<region>:<account>:repository/console`; `ecs:RegisterTaskDefinition`, `ecs:DescribeTaskDefinition`, `ecs:RunTask`, `ecs:DescribeTasks`, `ecs:DescribeServices`, `ecs:CreateService`, `ecs:UpdateService`, `ecs:ListTasks` on `*`; `iam:PassRole` on the two task roles; `logs:DescribeLogStreams`, `logs:GetLogEvents`, `logs:FilterLogEvents` on `arn:aws:logs:<region>:<account>:log-group:/console:*`.
 
+### The organization's own console
+
+`console-ui/`, when the organization has a look of its own: a console made with building-a-console at the plan's look, depending on `@skillcdn/console` at the version of the release `CONSOLE_REF` pins, with a `package-lock.json` (the workflow runs `npm ci`), a `build` script that runs `vite build` into `dist/`, and a `vite.config.ts` that sends `/api` to `console serve` while it is built; the workflow builds it on every push and lays `console-ui/dist/` over the image's web root. Absent, the image's default pages serve.
+
+### The plugins
+
+`plugins/package.json` and `plugins/package-lock.json`, when the plan names a plugin: `dependencies` only, each at an exact version from the registry or a tag of a git host (`github:<owner>/<repo>#<tag>`), written with `npm install --save-exact --package-lock-only --ignore-scripts <package>@<version>` in `plugins/`, which installs nothing on the machine; no scripts, no other field that does anything. The workflow installs them into the image from the lockfile with no install scripts and sets `PLUGINS_DIR`, as [deploy/README.md "Plugins in the image"](/deploy/README.md#plugins-in-the-image) lays it out; the console reads them at boot, and the administrator enables each on the settings page once the console runs. Absent, the console has no plugins. A plugin that asks `storage:sql` needs the database user to hold `CREATEROLE`, which the master user of phase 3's database does; one that keeps files is bounded with `PLUGIN_FILE_BYTES_AT_MOST` in `deploy/console.env` as `PROJECT_FILE_BYTES_AT_MOST` is, and each plugin's thread may hold `PLUGIN_MEMORY_MB_AT_MOST` (256 unless set), which the task's memory leaves room for.
+
 ### The rest of the repository
 
 - `README.md`, in the organization's language: what this repository is (the deployment of the organization's console), that a push to `main` deploys, where the record is, and where the skill that made it lives (`skillcdn.ai/gh/skillcdn/console`).
 - `DEPLOY.md`: the draft from the template (phase 8), filled as far as the run has gone.
 - `console-ui/`: only when the organization has its own console (building-a-console makes it); otherwise absent and the image's default UI serves.
+- `plugins/`: only when the plan names a plugin; otherwise absent, and the console has none.
 
 ### Commit, create, push, watch
 
@@ -542,6 +556,7 @@ Only on request, each step confirmed, in this order, after a last snapshot of th
 | `aws rds create-db-instance` refuses the engine version | The region has no PostgreSQL 18 yet | `describe-db-engine-versions --engine postgres` and take the newest major it lists |
 | `create-bucket` says the name is taken | Bucket names are global | Add a short suffix and update the task definition and the files policy |
 | `POST /zones` is refused with a permission error | The token lacks Zone Edit | Add the row (access.md) and run the step again |
+| `POST /zones` answers that the domain is on Cloudflare already, in another account | The organization's zone lives under another Cloudflare account | The person signs in there and moves the domain to this account, or makes the token under that account; the run then reads the zone as phase 1 does |
 | The migration task exits `78` | A variable refused; the log names it, never its value | Fix the parameter or the environment entry, push again |
 | The migration task exits `1` with a connection error | The tasks' group is not allowed into the database's, or the URL's host is wrong | Check the `authorize-security-group-ingress` and the endpoint in `DATABASE_URL` |
 | `ResourceInitializationError` on a task: unable to pull secrets | The execution role cannot read `/console/*` | Check `console-parameters` on `console-task-execution` and the parameter ARNs |

package/skills/deploying-a-console/references/running-it-again.md

@@ -0,0 +1,15 @@
+# Running it again
+
+A deployment is changed with the same skill, from phase 2: the plan names only what changes, with today's price where the change bills, the person says the word, the change is made as its row says, and the record, `DEPLOY.md`, is updated with it, in the same push or, where the change made none, in a push of its own, confirmed as phase 8 confirms it. The skill is read whole first, as for a first run; its rules hold here as there, and a push is a deployment (hard rule 3). The record's "How it is run" (resources.md "Phase 8: the record") says the same for the person who runs the console without an agent; the two are kept saying the same.
+
+| What changes | What it takes |
+|---|---|
+| A new version of the console | The next release tag's commit as `CONSOLE_REF` in `deploy/console.env`, found as the Inputs say under "The console's version"; `console-ui/`, where there is one, moved to the same version of the package, so that the pages and the server stay one release; a push, which builds the image and rolls it, `migrate` first. |
+| A plugin installed, updated or removed | The package named in `plugins/package.json` at an exact version or a tag of a git host, and the lockfile written beside it: `cd plugins && npm install --save-exact --package-lock-only --ignore-scripts <package>@<version>` (`npm uninstall --package-lock-only <package>` to remove), as [deploy/README.md "Plugins in the image"](/deploy/README.md#plugins-in-the-image) says; a push, which builds the image with the plugin installed and rolls it, `migrate` first. Then the administrator enables it on the console's settings page, consenting to what it asks, makes or chooses its board project and grants its roles ([planning-the-board](/skills/planning-the-board/references/setting-up.md)); a plugin with `storage:sql` needs the database user to hold `CREATEROLE`, which the master user does. The record names the plugin and its version. What a removed plugin stored stays until an administrator purges it. |
+| A new connector | `CLOUDFLARED_VERSION` in `deploy/console.env`, the connector's newest release, which `gh api repos/cloudflare/cloudflared/releases/latest --jq .tag_name` prints; a push. |
+| The next size | The numbers of the task definitions set to the next size's (sizing.md "The sizes"), `API_COUNT` and `WORKER_COUNT` in `deploy/console.env`; to `large`, `deploy/worker.task.json` written as resources.md gives it and `WORKER_IN_PROCESS` dropped from the api task; the database's class changed with one command, when nobody works (sizing.md "Growing"); the estimate of the new size at the plan; a push. |
+| A person let in or taken out | With an organization at GitHub, in the organization, which the console reads on its own; otherwise by an administrator, on the People page or with `console person add <login>` and `console person deactivate <login>`; no push, since nothing of the deployment changes. |
+| A secret rotated | The new value read from a secrets file of the same shape, as in phase 3, never from the chat; the parameter overwritten with the skill's script and the service rolled, so that the tasks start with it (resources.md "Phase 8: the record", "A secret rotated"); the file deleted again on the person's word; the record's line "a secret rotated", with the date. |
+| A console shared with outside teams or customers, each in projects of their own | The settings of [deploy/README.md "A shared console"](/deploy/README.md#a-shared-console): who sees whom, the bytes a project's files may hold together, tokens that end; as lines of the task definitions, with a push, or on the Settings page, with none. |
+| The console paused | Both services at zero tasks and the database stopped, which pauses the deployment at the cost of storage alone, for seven days at most, after which the database starts itself (sizing.md "Growing", "Fewer people"); the reverse resumes; the record says since when. |
+| The console removed | A run of its own, asked for and confirmed resource by resource (hard rule 7), as resources.md "Removing" says: a last snapshot of the database first, and the deployment repository kept, with the record of what was removed. |

package/skills/deploying-a-console/references/sizing.md

@@ -77,6 +77,8 @@ Part of the plan, in plain words, one line per item, the chosen size first:
 
 ## Options the plan offers
 
+None of these is offered by default: the plan names one only when the answers call for it (files kept at Cloudflare already, no tunnel wanted, builds on ARM runners), and at `large` asks one question: "Should the database survive the loss of one data centre? Two zones double its line."
+
 - **The database as serverless capacity.** Aurora Serverless v2 for PostgreSQL scales its capacity with load, down to nothing when idle (0 ACU with automatic pause, since 2024-11). The console holds a listening connection open and sweeps every fifteen minutes, so it never idles and the database never pauses: the floor is 0.5 ACU, about $44 a month at $0.12 per ACU-hour (read 2026-10), more than the `small` and `medium` instances. Offer it when the organization wants capacity that follows load without resizing, and say the floor.
 - **The bucket on Cloudflare R2** instead of S3: the same S3 API, `S3_ENDPOINT=https://<account id>.r2.cloudflarestorage.com`, `S3_REGION=auto`, path style; no egress charges. Its keys are made in the Cloudflare dashboard (R2, Manage API tokens, Object Read & Write on the one bucket), saved in the secrets file as `S3_ACCESS_KEY_ID` and `S3_SECRET_ACCESS_KEY`, stored as parameters and carried by the `api` task as secrets, with no `S3_CREDENTIALS` line: the task's role cannot reach R2. Offer it when the organization keeps its files at Cloudflare already; S3 stays the default because the task's own role reaches it with no key to keep, and the budget and the audit are then in one account.
 - **A load balancer instead of the tunnel.** ECS Express Mode creates an Application Load Balancer with HTTPS on an AWS domain in one command, at about $16 to $23 a month for the balancer (read 2026-10); the custom domain is a manual step on the balancer, and Cloudflare then proxies to it. Offer it only when the organization does not want its traffic through the tunnel; the tunnel is the default because it costs nothing, exposes nothing, and brings the client's address to the console cleanly.

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

@@ -0,0 +1,96 @@
+---
+name: planning-the-board
+description: "Puts work on the board of a SkillCDN Console and sets the board up, as a person asks, with the console command: tasks written from what they say or plan, each with its days, category, goal, parent and workers; goals on the roadmap; a project made or changed, with its mark, its members and its rules; the workspace's categories, people and settings; a private pack connected; a plugin's board project when an administrator enables one. Use when a person says 'put this on the board', 'write these as tasks', 'plan next week', 'set up a project for this', 'add Kim to the project', 'write the rules', 'make a category for design'. To work a task that is on the board, use working-the-board, which also writes a single piece of work given in chat before working it; to write a plugin, building-a-plugin. Everything is done as the person may: a task by anyone in the project, the rest by an owner or an administrator; what they may not, the console refuses, and the step goes back to them. Nothing is spent."
+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 who works in the project, owns it, or administers the workspace, as the step needs. Nothing else; the agent never sees a token.
+metadata:
+  author: skillcdn
+  version: "1.1"
+skillcdn:
+  translations:
+    ko:
+      title: 보드 계획하고 설정하기
+      description: "SkillCDN 콘솔의 보드에 일을 올리고 보드를 설정합니다. 사람이 말하거나 계획한 일을 날짜·범주·목표·상위 작업·담당자와 함께 작업으로 쓰고, 로드맵에 목표를 세우고, 프로젝트를 만들거나 바꾸고(마크, 구성원, 규칙), 워크스페이스의 범주·사람·설정을 다루고, 비공개 팩을 연결하고, 관리자가 플러그인을 켤 때 그 보드 프로젝트를 만들거나 고릅니다. '이거 보드에 올려줘', '이것들 작업으로 써줘', '다음 주 계획 세워줘', '이 일로 프로젝트 만들어줘', '김OO 프로젝트에 추가해줘', '규칙 써줘', '디자인 범주 만들어줘', '연차 플러그인 켜줘'라고 할 때 쓰세요. 보드에 있는 작업을 하는 것은 working-the-board이고, 그 스킬도 채팅으로 받은 일 하나는 먼저 보드에 쓰고 시작합니다. 플러그인을 만드는 것은 building-a-plugin입니다. 모든 일은 그 사람이 할 수 있는 만큼 합니다: 작업은 프로젝트에서 일하는 누구나, 나머지는 프로젝트 소유자나 워크스페이스 관리자. 할 수 없는 일은 콘솔이 거부하고 그 단계는 사람에게 돌아갑니다. 비용은 들지 않습니다."
+---
+# Planning and setting up the board
+
+What a person says goes in: work to put on the board, a plan for a week or a milestone, a project to set up, a member to add, a category, the rules. What comes out is the board changed as they said, and the numbers and the ids the commands printed, told back to them. The board is a SkillCDN Console ([architecture](/docs/architecture.md)): a workspace of projects, each a board of tasks with its roadmap of goals, sorted into the workspace's categories. The agent acts as the person who signed the command in, who works in the project, owns it or administers the workspace, and no further ([ADR-0021](/docs/adr/0021-a-token-configures-as-its-person-does.md)). Writing and setting up need no run: the project's feed of events records every write, with the agent named beside the person.
+
+## How the person is involved
+
+- **Questions:** only what the request and the board leave open, in one message before anything is read or written: the project, when the directory names none and the person has several ("Which project? `console projects` lists them by key."); a time the plan cannot turn into a day ("Which day is the launch?"; a week or a day named needs no question); a person named whom the project's members do not resolve to one login ("Which login is Kim? `console members` lists them."). Nothing else: the category, the goal, the parent, the state and the days are derived as the Inputs say, shown, and changed on request.
+- **Checkpoints:** the plan before it is written, whenever more than one task is written, or a day, a category, a state or a worker was derived rather than said, or a goal is set or moved, or tasks that exist are changed: one message with the table of phase 2, the derived cells marked, and "OK" writes it. One task with everything said, a member, a category: written at once and told.
+- **Go-ahead:** when the person says to go ahead alone, the plan is written at once and reported as the same table, with the numbers. The rules of a board are written only when the person asked for exactly that, go-ahead or not.
+- **Changes mid-run:** a task written wrong is changed (`console task edit`), never written twice; one that should not exist is put away (`console task archive`), since nothing is deleted; a plan changed in the message is rewritten from that point and shown again.
+
+## Requirements
+
+| Need | How | When missing |
+|---|---|---|
+| The `console` command, signed in as the person | `console whoami` says as whom, at which console and in which project this directory works. `console projects` says what the person is in each project; `console people` and `console members` say who is who, by login. | Stop and tell the person: `npm install -g @skillcdn/console`, then `console login --url <the console's address>`, which shows an address and a code they approve on the console's own pages. Never look for a token. Refused because the person is out (`auth.deactivated`, `auth.not_admitted`, [ADR-0044](/docs/adr/0044-a-token-of-a-person-who-is-out-is-kept-and-refused-with-the-reason-until-they-are-back-in.md)), nothing is written, and the person is told. |
+| The standing the step needs: what the person is in the project or the workspace | A task written, changed or put away: anyone who works in the project. A goal, the project's settings, its mark, its members, its rules, its pack token: an owner of the project (an administrator owns every project). A project made, the workspace's categories, people and settings, its rules and its pack token: an administrator ([ADR-0045](/docs/adr/0045-a-project-is-made-by-an-administrator.md)). | What the person may not, the console refuses (`auth.forbidden`): the step is told back to them with who may do it, and never worked around. |
+| The command's own words | `console help <command>` says every form and flag, the limits (a title's length, how many tasks a project holds) and the refusals by code, read when the command is about to be used. | They are the reference at run time; this skill says what to write, and in what order. |
+
+The board's words, task, goal, category, run, decision, page and project, are said once in [terms.md](/skills/working-the-board/references/terms.md); the command's contract is the [specification of the command line](/docs/specs/cli.md). A page this skill links by a path from the root (`/docs/...`, `/skills/...`) is a file of the console's repository: read it through the connection that served this skill, or in the package on this machine, where `console whoami` prints the skills are.
+
+## Inputs
+
+| Input | Source |
+|---|---|
+| The project | The one the directory works in (`console whoami`), else `--project <key>` on every command, from what the person said or the question above. |
+| The work, or the plan | What the person said, in chat or in a document they point to: the pieces of work, their time, who does what. One piece of work is one task; a milestone that several tasks reach is a goal; a task waits for another only when the person said so, and a list is not an order. |
+| The board as it is | `console categories`, the keys a task is sorted by; `console goals`, the roadmap; `console tasks --open` and `console tasks --search <words>`, so that a task is not written twice and a parent is found by its title; `console workspace`, the day the week begins and the time zone; `console rules`, which may say how tasks are written here: the language, the folders of the pages, who decides what. |
+| The people | `console members` for the project, `console people` for the workspace, by login, which `--worker`, `member` and `person` take. A name is matched against the members' logins and names: exactly one match is the login, shown at the checkpoint; none, or several, is the question above. A login is matched as typed, so a person the list hides (where who sees whom is narrowed) is still named by their login. |
+| The days | From the plan's words, by this machine's clock: `today`, `tomorrow`, `+7`, or a day as `2026-11-03`. A week named ("next week", "this week") is a start on its first day and a due on its last, the week beginning as `console workspace` says, and on Monday when it says `auto`; "by Friday" is a due day alone; a span the person gave in working days ends on its Friday only when they said so. A time that is not a day ("by the launch") is the question above. A due day is never before the start. |
+| Everything else | Derived and marked in the plan: the category whose name the task's words name or imply, and when two fit alike the one the project's tasks of that kind use (`console tasks --search`), else left empty and named in the account; the state, `ready` when the task can be taken from today on, its start day being the plan and not a gate, and `idea` only when a decision or a fact the body lacks must come first; the priority, `normal` unless the person said otherwise; the goal from the milestone the person named, found with `console goals --search <words>`. |
+
+## Workflow
+
+The questions of "How the person is involved" are asked before phase 1 when the request leaves them open; after that, each phase ends with one line to the person, and only phase 2 stops for them.
+
+### Phase 1: Read the board
+
+Produces the **shape of the board**: the project, its categories, its goals, its open tasks, its members and its rules, read with the commands of the Inputs. A project that does not exist yet goes to phase 4 first, for an administrator. A category the plan needs and the workspace lacks is left empty on the task and proposed in the account, for an administrator to make; it is never made unasked.
+
+### Phase 2: Shape the plan
+
+Produces the **plan**: one line per task, as a table the person reads at a glance (title, category, start and due day, priority, goal, parent, workers, state, with the derived cells marked), and the goals to set or move. A task is one piece of work that one agent or person finishes and hands in. Its title says what is to be done, in plain words that stand on their own, up to 200 characters: a noun the person gave ("the pricing table") takes the plainest verb that makes it work to do ("Make the pricing table"), shown at the checkpoint, and the scope stays theirs; what the title refers to (a milestone, a commit, a page) goes in the body, linked where it can be. The body is the work order for the agent that takes the task, in the shape of [a-task.md](references/a-task.md), holding only what the person said: what to make in their words, where and the milestones when they said them, and under "Ask" what they did not say, so that the agent asks on the board rather than guesses; what the rules say is read first goes under "Read first". A task that exists already, one open task whose title names the same piece of work, is changed in what the person said of it (its days, its workers), not written again. Stop for the checkpoint as "How the person is involved" says.
+
+### Phase 3: Write
+
+Produces the **tasks and goals on the board**. A goal first, for an owner: `console goal new "<title>" [--body <markdown>] [--category <key>] [--starts <day>] [--due <day>]`, and `goal id:` is read from the line printed; a goal is changed with `console goal edit <id> [the same flags]`, `none` clearing a category or a day. Then each task: `console task new "<title>" --body <markdown>|--file <path> --state <state> [--priority <priority>] [--category <key>] [--goal <id>] [--starts <day>] [--due <day>] [--worker <login|me>]... [--parent <number|id>]`, `--state` given every time, since a task written without it is an `idea`, and a body longer than a line given with `--file` from a scratch file of the run. The number and the id are read from the lines printed (`Task #<n> written`, `task id:`), never assumed, since other agents write on the same board; `--json` prints the whole answer for a script. A change is `console task edit <number> [the same flags]`, `none` clearing a field; a task that should not exist is put away, `console task archive <number>`, and `console task restore <number>` brings it back. What the console refuses is named by its code and fixed or told back: `task.invalid_category`, `task.invalid_goal`, `task.invalid_dates`, `task.invalid_parent`, `task.too_many`; `task.invalid_worker` says the person may not work in the project, and listing them is a step of phase 4 the person asks for.
+
+### Phase 4: Set up, when asked
+
+Produces the **project and the workspace as asked**: a project made or changed, its mark, its members, the workspace's categories and people, its settings, the rules, a private pack connected, a plugin enabled with its board project, each with the command and the standing [setting-up.md](references/setting-up.md) gives it. A project's rules start from [project-rules.md](references/project-rules.md) and are written only when a person asked for exactly that. A plugin that puts decisions, tasks and pages on a board gets its project when an administrator enables it, made from the plugin's own defaults or chosen among those that exist (setting-up.md "A plugin's board project"); it is a project as any, its tasks planned here as any, and what the plugin writes there carries the plugin's name. What the person may not do goes back to them, with who may.
+
+### Phase 5: Tell
+
+Produces the **account**: the table of phase 2 as it stands on the board, with the numbers and the ids, and the console's address from `console whoami`; what was derived (a category, a day, a state, a login) and how to change it (`console task edit <number> ...`); what was refused, and whose step it is. In the person's language, in one message.
+
+## Verdicts
+
+| Result | Verdict |
+|---|---|
+| Every piece of work the person named is one task on the board, with the plan as they said it, no task twice, and the numbers told back | Done |
+| A day, a category, a goal or a login could not be read from what was said: the task is written without it, and the account says so and how to set it | Done, with the gap named |
+| A step was refused for the person's standing (`auth.forbidden`), a key was taken, a login was not of the workspace or not of the project | Told back, with who may do it or what to change; never worked around |
+| A task was written twice, or in the wrong project | The extra one put away, and said so; nothing is deleted |
+
+## Hard rules
+
+- The plan is the person's: nothing on the board is changed that they did not ask for, and a task's days, category, goal and workers are set from their words by the rules of the Inputs, never from the agent's own view of what should come first.
+- The board writes its moments itself: when a task was started and done is never typed. The state is set by hand only as the plan says (`idea`, `ready`, or `done` for work that was done elsewhere), and never around a run, which `console take` and `console finish` move.
+- A number or an id is read from what the command printed, never assumed; a task whose number is not known is found with `console tasks --search <words>`, a goal's id with `console goals --search <words>`.
+- Nothing is deleted: a task, a page and the rules are put away, and come back.
+- A project is made by an administrator ([ADR-0045](/docs/adr/0045-a-project-is-made-by-an-administrator.md)), and a private one tells a member nothing of itself; a key does not change once made, so it is chosen with the person, and a key the console says is taken (`project.key_taken`) is not guessed around.
+- The rules of a board are the people's: written only when a person asked for exactly that, from the example, and never to loosen what they ask of agents.
+- Never look for, read, print or send a token. A pack token is connected with a code the person approves at SkillCDN, or read from standard input, never an argument.
+- What the console refuses goes back to the person, in their words, with who may do it: the console decides on every request, and the agent tries no other way.
+
+## Beside this skill
+
+- The commands of setting up, with the standing each needs: [references/setting-up.md](references/setting-up.md).
+- An example of a task written as a work order: [references/a-task.md](references/a-task.md).
+- An example of a project's rules: [references/project-rules.md](references/project-rules.md).
+- Working a task that is on the board: [working-the-board](/skills/working-the-board/SKILL.md).

package/skills/planning-the-board/references/a-task.md

@@ -0,0 +1,36 @@
+# An example of a task
+
+What a person, or their agent for them, writes on the board for an agent to take: the title says what is to be done and stands on its own; the flags carry the plan; the body is the work order, written from a scratch file of the run. An invented organization, Acme, and its web app, whose member `kim` is named by login. This is the full shape, for a person who gave the whole work order; a task given as a title alone keeps the same headings and says under "Ask" what was not said.
+
+~~~sh
+console task new "Refuse an empty file in the import parser" \
+  --file task.md --category engineering --goal <the goal's id> --due +3 --worker kim
+~~~
+
+`task.md`:
+
+~~~markdown
+## What to make
+
+The parser at `src/import/parse.ts` accepts an empty file and writes an empty record. It should refuse one with the error `import.empty`, and the API should answer `400` with it.
+
+## Where
+
+The repository acme/web, a branch from `main`. Its AGENTS.md holds inside it: `pnpm check` before a hand-in, a pull request and never a push to main.
+
+## Milestones
+
+1. A failing test that imports an empty file.
+2. The fix, with the error in the API's catalogue.
+3. The pull request, handed in.
+
+## Ask
+
+Whether an empty file is refused or skipped is settled: refused. Ask if the fix needs a change to the schema, or touches another endpoint.
+
+## Read first
+
+`guides/local-setup` of this project's pages; the skill `engineering/skills/working-in-web/SKILL.md` of the pack.
+~~~
+
+The command prints the task's number and its id, which are told back to the person. The agent that takes the task reads the body with `console take`, works it as working-the-board says, and hands in the pull request. What was decided before (refused, not skipped) is in the body, so that no decision is asked for it; what is left open is named, so that the agent asks on the board rather than guessing.