@specset/cli 2.1.0 → 2.2.0

package/README.md

@@ -62,6 +62,8 @@ Run `specset --help` or `specset <command> --help` for the full command referenc
 
 For a drawing coordination project, use `specset projects create 'Project name' --json`, then `projects add-docs --project <id> ./drawings.pdf` and `projects ingest-status --project <id> --wait`. New projects automatically support drawing graphs. This CLI requires the drawing graph GA server schema (`Project.drawingGraphEnabled`); the deprecated graph opt-in flags have been removed.
 
+`projects add-docs` also requires the server's duplicate-skip result (`createProjectDocuments.skippedCloudFileIds`). It reports skipped duplicate files and adds the other files in the request.
+
 Source references returned by GraphQL, agent chat, and retrieval tools are shown as clickable `https://app.specbook.ai/go/...` links. The same links can be passed back into tool, GraphQL ID, and download arguments; ordinary GraphQL `id` fields remain UUIDs.
 
 ## Use with Claude, Codex, and ChatGPT
@@ -123,7 +125,9 @@ CLI 1.x requires a Specset deployment that serves public source links (the `/go`
 
 CLI 2.0 requires Node.js 22 or newer and a Specset deployment from 2026-10-10 or later, which app.specset.com is. Existing commands depend on the newer server too: `org list`, `org use` and every command's `--org` resolution query `me.organizationChoices` (PR #972), and the new commands (personal runners, project seeding, submittal reviews, the superadmin namespace) call APIs deployed by that date. On Node.js 20, or against an older deployment, stay on CLI 1.0.0 until both are upgraded.
 
-`org security show`, added in CLI 2.1.0, needs a deployment that serves `Org.secureConfiguration` (PR #1403). CLI 2.1.0 is published before that field is deployed, so the command fails against app.specset.com until the next deploy after the release. `org members list` uses `orgMembers` and works against any deployment CLI 2.0 supports.
+`org members list`, from CLI 2.2.0, reads each member's role name and whether it is a privileged account (`OrgMember.customRole` and `privileged`, PR #1457), for `--privileged` and for organizations that define their own roles. It needs a deployment that serves those fields, which app.specset.com does from the deploy of that PR; against an older deployment, stay on CLI 2.1.0.
+
+`org security show`, added in CLI 2.1.0, needs a deployment that serves `Org.secureConfiguration` (PR #1403). CLI 2.1.0 is published before that field is deployed, so the command fails against app.specset.com until the next deploy after the release. In CLI 2.1.0, `org members list` asks only for `orgMembers` fields every deployment CLI 2.0 supports has.
 
 `agent start --type ProjectReview` requires the server's Project Review agent registration. Project Review has no separate project toggle or superadmin launch requirement. These command and skill additions ride the next CLI release; no npm version is bumped here.
 
@@ -144,11 +148,11 @@ Third-party license attributions are listed in `THIRD_PARTY_NOTICES.md`.
 
 ### Personal machine runners
 
-`specset agent serve --host <deployment>` registers a personal runner while the command is running. Organization selection uses `--org <slug|id>`, the selected organization on that host, or the sole membership. With multiple memberships and no selection, choose an org explicitly. Omitting `--project` makes the runner available throughout that org; `--project <id|link>[,<id|link>…]` restricts it to selected projects. In a local thread, select that machine to authorize the root run and its descendants. Multiple comma-separated project IDs can be allowed; registration is restricted to the signed-in user and organization. `--thread <id>` assigns an existing root immediately; `--message "…" --type DrawingReview` creates an assigned root in a single selected project.
+`specset agent serve --host <deployment>` registers a personal runner while the command is running. Organization selection uses `--org <slug|id>`, the selected organization on that host, or the sole membership. With multiple memberships and no selection, choose an org explicitly. Omitting `--project` makes the runner available throughout that org; `--project <id|link>[,<id|link>…]` restricts it to selected projects. In a local thread, select that machine to authorize the root run and its descendants. Multiple comma-separated project IDs can be allowed; registration is restricted to the signed-in user and organization. `--thread <id>` assigns an existing root immediately; `--message "…" --type DesignQualityReview` creates an assigned root in a single selected project.
 
 `agent serve` serves from the harness accounts in the `runner:` block of `~/.config/specset/config.yml`; `specset harness list` shows them with the routing below. With none listed it uses the logins this shell would use: the host's harness default saved by older CLIs, else every native runtime that can run (Claude Code at `CLAUDE_CONFIG_DIR` or `~/.claude`, Codex at `CODEX_HOME` or `~/.codex`, Antigravity's `agy`). Add another login with `specset harness add claude2 --harness claude --home ~/.claude2 --preferred` (it signs in once to check the login) and drop one with `specset harness remove <name>`; `--account claude2,codex` limits one run to those accounts. Claude uses the platform binary bundled with the CLI's Claude SDK, then native `claude` on PATH. Codex uses `CODEX_PATH`, then native `codex` on PATH, then the native runtime provided by `specset harness install codex`. Antigravity is opt-in: `agent serve` uses it only after you add an account for it (`specset harness add agy --harness antigravity`), never by detection. It uses `agy` on PATH, then `~/.local/bin/agy`; install it from antigravity.google and run `agy` once to sign in. Its login lives in the macOS keychain, so a machine has one Antigravity account.
 
-Every model call carries its routing tier: conversation, orchestrator, planner, analyst, worker, lite, balanced, query or vision. Each tier names a model, and any account whose harness offers that model serves it. The defaults match the app's cloud routing: sonnet for the conversation, orchestrator and planner (Claude Code); gemini-3.8-flash-medium for analyst and vision (Antigravity); gpt-6-luna for worker and query, gpt-6-luna at low effort for lite, and gpt-6-sol at low effort for balanced (Codex). A tier whose model no account offers runs the same class of model (frontier, standard, fast) on a harness the machine has: opus, sonnet and haiku on Claude Code; gpt-6-astra, gpt-6-sol and gpt-6-luna on Codex; gemini-3.8-flash-high, -medium and -low on Antigravity. Change a tier with `specset harness tier worker haiku` (or `model:effort`, or `default`), a class's model with `specset harness model codex standard gpt-6-sol --effort low`, or one run's tiers with `agent serve --tier conversation=opus,worker=haiku`. A conversation's Settings choice (a class or an exact model) applies to that thread's own steps only; its children and helper calls follow the tiers.
+Every model call carries its routing tier: conversation, orchestrator, planner, analyst, worker, drafter, lite, balanced, query or vision. Each tier names a model, and any account whose harness offers that model serves it. The defaults match the app's cloud routing: sonnet for the conversation, orchestrator, planner and drafter (Claude Code); gemini-3.8-flash-medium for analyst and vision (Antigravity); gpt-6-luna for worker and query, gpt-6-luna at low effort for lite, and gpt-6-sol at low effort for balanced (Codex). A tier whose model no account offers runs the same class of model (frontier, standard, fast) on a harness the machine has: opus, sonnet and haiku on Claude Code; gpt-6-astra, gpt-6-sol and gpt-6-luna on Codex; gemini-3.8-flash-high, -medium and -low on Antigravity. Change a tier with `specset harness tier worker haiku` (or `model:effort`, or `default`), a class's model with `specset harness model codex standard gpt-6-sol --effort low`, or one run's tiers with `agent serve --tier conversation=opus,worker=haiku`. A conversation's Settings choice (a class or an exact model) applies to that thread's own steps only; its children and helper calls follow the tiers.
 
 The runner chooses each call's account before claiming it. Among the accounts that offer the call's model, the preferred ones (added with `--preferred`, else all of them) take it while one has room, the least busy first; a native session stays on its account. When those are at their limits, `specset harness failover` decides: `sameModel` (the default) lets the other accounts that offer the model take it, `any` also the same class of model on another harness, and `off` nothing. A call that reaches a limit before producing any output moves the same way. A call whose output already reached the thread fails instead, since running it again could replay native actions, and the next call goes to an account with room. When every allowed account is at its limit, the run stops with the earliest reset time.