@cellapp/cli 0.3.0 → 0.3.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cellapp/cli",
-  "version": "0.3.0",
+  "version": "0.3.1",
   "description": "Cellapp static application deployment CLI and Agent Skill",
   "type": "module",
   "license": "MIT",

package/skills/cellapp-deploy/SKILL.md

@@ -19,6 +19,10 @@ npm exec --yes --package=@cellapp/cli@latest -- cellapp --help
 
 Use the same `npm exec --yes --package=@cellapp/cli@latest -- cellapp` prefix for deployment, data and recovery commands below. npm fetches and caches the official package on demand; do not install it globally or ask the user to run setup commands. If Node.js is missing or unsupported, package retrieval fails, or help verification fails, report that exact blocker and stop. Do not use `sudo`, disable TLS checks or implement the upload protocol yourself. Keep the client's upgrade hint separate from the deployment result.
 
+## Authorize before long work
+
+After verifying the client and resolving the project's control origin, check authorization before lengthy development or builds with `npm exec --yes --package=@cellapp/cli@latest -- cellapp apps --project <project>`. It reuses a saved credential or starts device authorization when none exists. Immediately give the user the verification link and code and keep the command running while they approve in the browser. If a saved credential returns 401, run `cellapp login` with the same npm prefix, project and origin, then retry `cellapp apps`. If a code expires before approval, wait until the user is ready, run login again and send the fresh link and code; never leave the expired code as the next step. Do not request a password or treat a chat reply as browser approval. Continue the long work only after authorization succeeds.
+
 ## Inspect
 
 Read `cellapp.json`, the existing build command, static output directory, and `cellapp.data.json` if present. Reuse the application association on updates. For plain HTML omit the build command. Ask only for an ambiguous output or build setting. Cellapp hosts static frontend code; do not deploy SSR, a custom server, private service key, direct PostgreSQL credential, or arbitrary SQL. Bundled frontend values are readable by admitted visitors.
@@ -35,6 +39,8 @@ The display name may repeat. Every owner has one public user slug (`namespace` i
 
 The versioned, non-secret [`cellapp.data.json`](examples/notes/cellapp.data.json) manifest defines tables, columns, primary keys, indexes and operation policies. Types: `text`, `uuid`, `bigint`, `boolean`, `timestamptz`, `jsonb`. Policy modes: `none` (default), `all-admitted-users`, `own-rows`. The `own-rows` mode needs a non-null text `ownerColumn`; reads and writes are checked against the signed application user ID. Every table needs a primary key. No SQL, function, trigger, database password or provider identity belongs in the manifest. Table names are scoped to the app: an app may define `users` without touching platform users or another app's `users`. This is ordinary app data, not the platform identity source. Keep names unique within one app; `rpc` is reserved for the unsupported PostgREST route, PostgreSQL system column names are unavailable, and generated index names must not collide with table names. Check these rules with `data plan` before applying.
 
+For a public form, add `policies.anonymousInsert: "all"` to the intended table; add `anonymousSelect: "all"` only when visitors may read its rows. Omitted fields deny anonymous access. After applying a new manifest version, the owner can run `cellapp anonymous set <app-id> --pages true --read false --write true` (or use the dashboard). The operator must separately enable anonymous submissions. Check the effective state with `cellapp anonymous get <app-id>`. Verify in a browser without an app session: open the page, submit once, confirm an insert-only response contains no row, and confirm GET/PATCH/DELETE and a wrong-Origin POST are rejected. Never put database credentials or a privileged JWT in the page.
+
 A new project needs its first static deployment to create the application association in `cellapp.json`. Build and deploy the frontend once, then use the linked app and configured origin to apply the data manifest. Do not report the table-dependent page as ready until verification succeeds:
 
 ```sh
@@ -56,7 +62,7 @@ Use only `.from(table).select(columns)`, `.insert(values)`, `.update(values)`, `
 
 ## Publish and report
 
-Run `npm exec --yes --package=@cellapp/cli@latest -- cellapp deploy --project <project> --output <output-directory> --build <existing-build-command>` (optionally adding `--namespace` and `--slug` on the first deployment), omitting `--build` for plain HTML. Add `--spa` only for client-side routes. The client performs device authorization when needed; provide the verification link and code, keep the command running while the user approves in the browser, and never request account passwords. Do not treat a chat reply as approval. Report publication only after `status: published`. Report data version/verification and static release separately, then provide the app URL.
+Run `npm exec --yes --package=@cellapp/cli@latest -- cellapp deploy --project <project> --output <output-directory> --build <existing-build-command>` (optionally adding `--namespace` and `--slug` on the first deployment), omitting `--build` for plain HTML. Add `--spa` only for client-side routes. If deployment still starts device authorization, provide the new verification link and code promptly and keep the command running while the user approves in the browser; if it expires, obtain a fresh code before retrying. Report publication only after `status: published`. Report data version/verification and static release separately, then provide the app URL.
 
 The first deployment returns an access key once. Give it only to the requesting owner; never put it in a URL, repository, issue or project state. Old keys can be redeemed only after platform login. `cellapp reset-key <app-id>` rotates future redemption; existing user grants remain active. Revoke an individual grant in the owner console. Use reset or delete only when requested. A lost initial key can be explicitly rotated.
 

package/skills/cellapp-deploy/SKILL.zh-CN.md

@@ -19,6 +19,10 @@ npm exec --yes --package=@cellapp/cli@latest -- cellapp --help
 
 下文的部署、数据和恢复命令都使用相同的 `npm exec --yes --package=@cellapp/cli@latest -- cellapp` 前缀。npm 会按需获取并缓存官方包；不要全局安装，也不要要求用户执行安装命令。如果 Node.js 缺失或版本不受支持、包获取失败或帮助命令验证失败，报告具体障碍并停止。不要使用 `sudo`、关闭 TLS 验证，或自行实现上传协议。客户端的升级提示应与部署结果分开说明。
 
+## 在耗时工作前完成授权
+
+验证客户端并确定项目控制来源后，在长时间开发或构建前运行 `npm exec --yes --package=@cellapp/cli@latest -- cellapp apps --project <project>` 检查授权。已有凭证会被复用；没有凭证时会启动设备授权。验证链接和代码出现后立即交给用户，并在用户通过浏览器批准期间保持命令运行。若已有凭证返回 401，使用相同 npm 前缀、项目和来源运行 `cellapp login`，再重试 `cellapp apps`。若验证码在批准前过期，等用户准备好后重新登录并发出新链接和代码；不要把过期码留作下一步。不要索取密码，也不要把聊天回复当作浏览器批准。授权成功后再开始耗时工作。
+
 ## 检查项目
 
 读取已有的 `cellapp.json`、构建命令、静态输出目录，以及可能存在的 `cellapp.data.json`。更新应用时复用现有关联。无需构建的普通 HTML 省略构建命令。只有输出目录或构建设置不明确时才询问。Cellapp 托管静态前端代码；不要部署 SSR、自定义服务器、私密服务密钥、直连 PostgreSQL 的凭证或任意 SQL。获准访问的访客可以读取打包后的前端内容。
@@ -35,6 +39,8 @@ npm exec --yes --package=@cellapp/cli@latest -- cellapp --help
 
 有版本且不包含秘密的 [`cellapp.data.json`](examples/notes/cellapp.data.json) 清单定义数据表、列、主键、索引和操作策略。类型包括 `text`、`uuid`、`bigint`、`boolean`、`timestamptz`、`jsonb`。策略模式包括 `none`（默认）、`all-admitted-users`、`own-rows`。`own-rows` 模式需要非空的文本型 `ownerColumn`；读写操作会与已登录的应用用户 ID 比对。每张表都需要主键。清单中不能包含 SQL、函数、触发器、数据库密码或提供方身份。表名按应用隔离：一个应用可以定义 `users`，而不影响平台用户或其他应用的同名表。它只是普通应用数据，不是平台身份来源。同一应用内名称必须唯一；`rpc` 为未支持的 PostgREST 路由保留，PostgreSQL 系统列名不可用，生成的索引名也不能与表名冲突。应用前用 `data plan` 检查这些规则。
 
+公开表单只给目标表增加 `policies.anonymousInsert: "all"`；确实允许访客读取记录时才增加 `anonymousSelect: "all"`。未填写即拒绝匿名访问。应用新版清单后，所有者运行 `cellapp anonymous set <app-id> --pages true --read false --write true`，或在控制台设置；运维仍须单独开启匿名提交总开关。用 `cellapp anonymous get <app-id>` 查看实际状态。用未登录浏览器打开页面并提交一次，确认仅新增的响应不包含行内容，匿名 GET/PATCH/DELETE 和错误 Origin 的 POST 均被拒绝。页面中不得放数据库凭证或高权限 JWT。
+
 新项目先完成首次静态部署，以便在 `cellapp.json` 中建立应用关联。先构建并部署一次前端，然后使用已关联的应用和配置的来源应用数据清单。验证成功前，不要报告依赖数据表的页面已准备就绪：
 
 ```sh
@@ -56,7 +62,7 @@ npm exec --yes --package=@cellapp/cli@latest -- cellapp data verify --project <p
 
 ## 发布与报告
 
-运行 `npm exec --yes --package=@cellapp/cli@latest -- cellapp deploy --project <project> --output <output-directory> --build <existing-build-command>`；首次部署时可选传入 `--namespace` 和 `--slug`。普通 HTML 如果不需要构建，则省略 `--build`。仅当应用使用客户端路由时添加 `--spa`。需要设备授权时，由客户端发起流程；将验证链接和代码交给用户，在用户通过浏览器批准期间保持命令运行，不要索取账号密码。聊天中的回复不等于批准。仅在返回 `status: published` 后报告发布成功。数据版本及其验证结果应与静态版本分开报告，最后提供应用地址。
+运行 `npm exec --yes --package=@cellapp/cli@latest -- cellapp deploy --project <project> --output <output-directory> --build <existing-build-command>`；首次部署时可选传入 `--namespace` 和 `--slug`。普通 HTML 如果不需要构建，则省略 `--build`。仅当应用使用客户端路由时添加 `--spa`。如果部署时仍启动设备授权，立即将新的验证链接和代码交给用户，并在用户通过浏览器批准期间保持命令运行；若验证码过期，取得新码后再重试。仅在返回 `status: published` 后报告发布成功。数据版本及其验证结果应与静态版本分开报告，最后提供应用地址。
 
 首次部署只返回一次访问密钥。仅交给提出请求的所有者；不要写入 URL、仓库、Issue 或项目状态。旧密钥只能在平台登录后兑换。`cellapp reset-key <app-id>` 会轮换后续兑换所用密钥，已有用户授权仍有效。可在所有者控制台撤销单个授权。仅在用户要求时才重置密钥或删除应用。初始密钥丢失后，可以按明确要求进行轮换。