@codetreker/daynight 0.21.11 → 0.22.1

package/README.md

@@ -22,6 +22,7 @@ GitHub CLI and Copilot CLI on `PATH`.
 - [Task deletion](#task-deletion)
 - [Task attachments](#task-attachments)
 - [Worker configuration and startup](#worker-configuration-and-startup)
+- [Worker manual management](#worker-manual-management)
 - [Review configuration and startup](#review-configuration-and-startup)
 - [Review status listing](#review-status-listing)
 - [Durable review state](#durable-review-state)
@@ -98,6 +99,14 @@ daynight login [--no-browser]         # Authorize CLI access through the browser
 daynight logout                      # Revoke and remove the current CLI credential
 daynight worker                     # Show worker help
 daynight worker run                 # Run until interrupted
+daynight worker attach              # Open the worker Herdr session
+daynight worker repo list [--json]
+daynight worker repo add [--project <project-id>]
+daynight worker repo remove [--project <project-id>]
+daynight worker retry <task-id> --claim-id <claim-id> [--project <project-id>]
+daynight worker release <task-id> --claim-id <claim-id> --if-version <version> [--project <project-id>]
+daynight worker resume <task-id> --claim-id <previous-claim-id> --if-version <version> [--project <project-id>]
+daynight worker transfer <task-id> --claim-id <claim-id> --if-version <version> [target options] [--project <project-id>]
 daynight review                     # Show review help
 daynight review run
 daynight review list                 # Also review ls
@@ -305,6 +314,24 @@ records startup-file ownership and installation limits.
 
 ## Configuration setup
 
+The shared configuration file is `~/.daynight/config.yml`. The complete
+[`config.example.yml`](config.example.yml) covers service access, review and worker
+settings with their defaults and optional overrides. It is included at the root
+of the npm package. For an npm global installation, locate it with:
+
+```bash
+npm root --global
+```
+
+Open `@codetreker/daynight/config.example.yml` beneath that directory. Select the
+sections needed for your commands and replace the example repositories and local
+paths. For a new configuration, save the selected settings to
+`~/.daynight/config.yml`; for an existing file, merge them while preserving its
+credential, generated `workerId` and unrelated settings. The example itself is
+not loaded automatically. Repository paths resolve from the configuration
+directory, with the rules in the [worker](#worker-configuration-and-startup) and
+[review](#review-configuration-and-startup) guides.
+
 Project and task commands use `https://daynight.cc` when the configuration file or
 `serverUrl` is absent. A production connection needs no server configuration.
 Run `daynight login` to display an authorization code and open the verification
@@ -337,7 +364,8 @@ commands do not start login, follow redirects with credentials, or automatically
 repeat a write. Reconcile an unconfirmed business mutation before another one.
 
 The first `review run`, `review list` or `review ls` asks for a repository when
-the file or `repositories` field is absent. To configure one in advance, run:
+the file, `review` section or `review.repositories` field is absent. To configure
+one in advance, run:
 
 ```bash
 daynight review add-repo https://github.com/OWNER/REPO.git
@@ -769,12 +797,69 @@ integration/history instead of installing or changing global native settings.
 Git transport and tools used by the task, such as authenticated GitHub CLI for
 PR delivery, must also be ready.
 
-Run `daynight login` for Daynight authentication. Add the following mapping to
-the shared `~/.daynight/config.yml`, preserving existing connection and review
-settings:
+Run `daynight login` for Daynight authentication, then select one or more
+existing accessible Projects:
+
+```bash
+daynight worker repo add
+daynight worker repo list
+daynight worker repo remove
+```
+
+Add and remove list remote Projects for multiselection. Each choice includes its
+name, UUID and repository URL. A new registration saves the selected Project ID,
+original server repository URL and an absolute local path. Matching existing
+registrations retain their configured transport URL, path and native settings;
+a remote-only registration gains only its Project ID. Remove changes configuration
+only: clones, claims, worktrees, native history and frozen execution settings
+remain. A running worker reads its next selection at startup, without hot reload.
+For scripts, identify one accessible existing Project explicitly:
+
+```bash
+daynight worker repo add --project PROJECT_UUID
+daynight worker repo remove --project PROJECT_UUID
+daynight worker repo list --json
+```
+
+`list` reads local registrations without remote discovery. Add and remove
+operate on existing accessible remote Projects, not raw Git URLs or new Project
+creation. Cancellation, empty choices, authentication or API failures, invalid
+selections and save failures leave the selection unchanged.
+
+An empty repository list makes interactive `worker run` offer the same Project
+selection. Fresh startup saves the selection before creating worker identity,
+SQLite, Git or Herdr resources. A restarted worker with retained state first
+establishes its cleanup controller, so committed cleanup deadlines continue
+while Project lookup or prompting waits. New task resources wait for successful
+selection. Startup checks the service and selected worker settings from one
+captured configuration source; changed service or credentials require restarting
+the worker. Without terminal input and stderr, configure a Project with
+`worker repo add --project PROJECT_UUID` before startup.
+
+New paths use `worker.repositoryRoot`, defaulting to `~/daynights`, independently
+of `review.repositoryRoot`. The worker root accepts the current home
+shortcut (`~` or `~/`), absolute paths and paths relative to `config.yml`; Windows
+also accepts `~\`. Registration resolves that root with the actual home and
+saves absolute paths. Ordinary repositories use `<root>/<host>/<owner>/<repo>`;
+generic transport, user, port or nested-path identities retain distinct encoded
+coordinates. Existing Project paths and agent overrides survive repeat add and
+root edits.
+
+Network and interaction hold no configuration lock. The atomic writer rereads
+current YAML, preserves comments and unrelated edits, and refuses changed
+worker root, repository selection or service credentials. Save also rejects
+shared YAML aliases that would alter unrelated effective settings; separate the
+worker data from those aliases before retrying. Unaffected aliases remain valid.
+Repository identities, Project IDs and logical or physical paths must remain
+distinct, including the Daynight state directory. These commands do not clone
+repositories, acquire tasks or start Herdr.
+
+For explicit repository paths and runtime overrides, retain the shared
+connection and review settings and configure `worker` directly:
 
 ```yaml
 worker:
+  repositoryRoot: ~/daynights
   maxConcurrent: 1
   pollIntervalMs: 5000
   recoveryLimit: 3
@@ -791,17 +876,25 @@ worker:
       args: []
 ```
 
-These are the defaults for all optional worker fields; `repositories` is
-required. Each entry requires `remote` and `path`, with optional `projectId`,
-`agent`, `model` and `args`. The service project must already exist and match the
-repository. Add `projectId` when more than one project matches. Missing local
-repositories are cloned; existing roots and origins are verified without
-resetting their files or branches. Use the native authentication configuration
-for credentials, keeping credentials out of repository URLs and argument lists.
-
-Paths are absolute or relative to the configuration file's directory, never
-the launch directory. Tilde expansion and drive-relative Windows paths are
-rejected. Repository identities, project IDs and paths cannot duplicate or
+These are the defaults for the optional runtime fields. A missing configuration
+file, an omitted `worker` mapping, and `worker: {}` use the same defaults.
+Omitting `repositories` selects an empty acquisition list; worker repositories
+are never inferred from review settings. Configuration reads do not create or
+rewrite configuration files. Explicit `null` in non-nullable fields, malformed
+settings, filesystem errors and cancellation remain errors; `model: null` keeps
+its documented clearing semantics.
+
+Each explicit repository entry requires `remote` and `path`, with optional
+`projectId`, `agent`, `model` and `args`. The
+service project must already exist and match the repository. Add `projectId`
+when more than one project matches. Missing local repositories are cloned;
+existing roots and origins are verified without resetting their files or
+branches. Use the native authentication configuration for credentials, keeping
+credentials out of repository URLs and argument lists.
+
+Repository entry paths are absolute or relative to the configuration file's
+directory, never the launch directory. They do not expand tilde and reject
+drive-relative Windows paths. Repository identities, project IDs and paths cannot duplicate or
 overlap, including the fixed Daynight state directory. Unknown worker fields,
 wrong types, invalid arguments and unsupported path shapes fail visibly.
 `maxConcurrent` is a positive integer, `recoveryLimit` is nonnegative and
@@ -859,15 +952,45 @@ it is not replayed. A pause still reserves capacity. Recovering missing original
 configuration, history or stop evidence requires inspection, without creating a
 replacement conversation to conceal the loss.
 
-For human input, copy the safe `attach` descriptor printed after the running
-worker has completed inventory and private managed-instance readiness.
-Invoke its `executable` with its `arguments` (`herdr --session w` for the default
-executable), apply exactly its `environment` overrides and remove the names in
-`unsetEnvironment` **only for that attach client process**. The descriptor's
-private XDG values select the worker's exact Herdr instance; the existing task
-pane keeps its original native XDG and private HISTFILE. The descriptor contains
-routing and native-home paths, not a dump of authentication values. Continue in
-the original task pane so the worker can observe the same execution.
+For human input, run this in another interactive terminal:
+
+```bash
+daynight worker attach
+```
+
+The command opens the existing private Herdr session with the correct directory
+and environment. Continue in the original task pane so the worker can observe
+the same execution. Detaching closes only the client connection; the worker,
+original agent and task keep running. This command needs no Daynight login or
+server request and does not take the worker lock. It connects only to an
+existing session; if it is unavailable, start `daynight worker run` first.
+Client startup and nonzero-exit errors remain visible.
+
+The worker prints the attach command after inventory and private
+managed-instance readiness. Its attachment descriptor remains the internal
+source of routing, native-home and history settings. Only the client process
+receives those settings and removal of inherited session identities; the
+existing task pane retains its original native XDG and private HISTFILE.
+
+Native startup can be waiting at a folder-trust or authorization screen even
+when Herdr reports idle/interactiveReady. The worker checks the current Codex
+input surface before automatic text and Enter, reports a blocking reason and
+keeps the first prompt unsent. It does not choose native trust or change global
+trust configuration. Configure that prerequisite normally in the native tool or
+use the original attached task pane to make the decision explicitly, then leave
+the business composer available for input. This check does not inspect arbitrary
+human draft meaning or prove that a model consumed previously submitted text.
+
+The checked Codex startup/restart layout is the standard/default business
+composer together with a loaded model/reasoning and current-directory footer
+(`model-with-reasoning · current-dir`). Ask text or a version header alone is
+insufficient because provisional startup can show them too. A custom footer,
+cropped footer or otherwise unrecognized visible layout remains unknown; the
+original Operation bounds observation and ends not-submitted if that supported
+surface never appears. In the original session, finish any blocking decision
+and restore the supported standard native layout before requesting public retry.
+The worker does not change the layout, infer arbitrary draft meaning or turn
+this screen check into a native consumption receipt.
 
 For started executions, a successful complete own-claim inventory from the
 original account makes the original claim's absence cause
@@ -915,13 +1038,143 @@ shutdown initialization is isolated so one bad record does not prevent known
 agents stopping. Untracked resources or unknown scope keep the private instance
 when its stop cannot be confirmed.
 
-Public worker release/transfer/resume/retry commands and the service's terminal
-management-protocol revision remain pending. Linux, Windows and macOS complete
-Goal acceptance is separate from the installed runtime and its component
-checks. The [worker requirements](../../docs/spec/daynight-worker.md) and
+Linux, Windows and macOS complete Goal acceptance is separate from the installed
+runtime and its component checks. The
+[worker requirements](../../docs/spec/daynight-worker.md) and
 [worker design](../../docs/design/daynight-worker.md) own the behavior and
 mechanisms, including native capability limits.
 
+## Worker manual management
+
+Manual commands select one task and its exact original claim. They use the same
+fixed SQLite and singleton lock as `worker run`. With a foreground worker, that
+process remains the sole agent controller and consumes the persisted decision;
+without one, the command acquires the same lock and advances the same coordinator
+for that execution. There is no separate control service. Current configuration
+and Daynight authentication are required, and the original service origin must
+match. Release, transfer and retry require the unfinished original local record;
+resume can use an explicit project with its configured repository.
+
+Read the current task before deciding a versioned operation:
+
+```bash
+daynight task show <task-id> --json
+daynight worker release <task-id> --claim-id <source-claim-id> --if-version <version>
+```
+
+Release and transfer first verify project access and source owner/admin
+permission, then persist the concrete source decision before cleanup. The
+controller requests the original agent's attributable temporary-resource cleanup,
+waits for its original deadline of at most 10 minutes, confirms that agent stopped,
+closes its task workspace and deletes its worktree. Only then can it submit the
+remote write at the exact supplied version. Other tasks keep their shared Herdr
+instance. Failed stopping or deletion retains the source responsibility and a
+visible error. Cleanup keeps its original deadline after restart; each HTTP
+request has an independent bounded scope, without a five-minute total command
+limit.
+
+Release returns the task to `todo` and clears its execution interval. The daemon
+skips released tasks until explicitly resumed. Resume starts a fresh execution
+on this worker:
+
+```bash
+daynight worker resume <task-id> --claim-id <released-claim-id> --if-version <version> \
+  --project <project-id>
+```
+
+The previous claim must still be released and the task ready. The original owner
+or a current project admin may resume it, retaining the explicit manual exception
+to automatic permission and platform filters. The new claim and worktree IDs are
+generated and persisted before submission. Its actual grant commits local
+`pending` with this repository's current effective agent/model/args; `worker run`
+then performs ordinary capacity checks and prepares a fresh native conversation.
+The deleted source worktree and native history are not required. Run
+`daynight worker run` if the foreground worker is stopped.
+
+Transfer explicitly identifies the target's current user, stable worker and
+machine descriptor, actual platform and selected agent:
+
+```bash
+daynight worker transfer <task-id> --claim-id <source-claim-id> --if-version <version> \
+  --target-user-id <user-id> --target-worker-id <worker-id> \
+  --target-machine-id <machine-id> --target-machine-name "target-machine" \
+  --target-platform linux --target-agent codex
+```
+
+Use the intended receiver's actual descriptor and the explicitly selected new
+agent type. A trace-free new transfer grant honors that agent even when the
+receiver's current repository defaults select the other type. It freezes
+`model: null` and `args: []` for that type, with the current recovery limit; a
+matching type uses the current effective model/args. Existing pending snapshots
+are retained. The source operator's owner/admin permission is checked separately
+from the target's
+current membership. Transfer still requires automatic execution permission,
+platform compatibility and completed dependencies. It preserves `in_progress`
+and the task's execution interval, installing a fresh target claim/worktree ID
+with empty runtime associations. The receiver discovers its actual grant through
+normal claim inventory and starts a new execution; an old task path still in use
+blocks preparation. No source files, SQLite snapshots or native history are
+transported. Target and source agents may differ. Public commands provide no
+claim/worktree-ID override or continuity confirmation option; the service and
+typed client reject deprecated `continuityConfirmed` input.
+
+For a paused execution that still belongs to the original owner, authorize one
+extra recovery attempt:
+
+```bash
+daynight worker retry <task-id> --claim-id <claim-id>
+```
+
+Retry preserves the original claim, worktree/native identity and frozen
+settings, retaining the cumulative recovery count rather than resetting it.
+Concurrent or repeated requests do not accumulate extra authorization or launch
+a second agent. The controller consumes the single permit for that original
+execution; a further failure remains visible. Retry cannot replace terminal
+cleanup or recreate an execution that has ended.
+
+A native launch acknowledged before a blocking startup screen has a specific
+continuation path when its first prompt is durably known unsent. Keep the
+original worker/native session running and use another terminal to attach to
+that original pane. Inspect the reported folder-trust/authorization requirement
+and make the native decision yourself. Once the business composer is available,
+run:
+
+```bash
+daynight worker retry <task-id> --claim-id <original-claim-id> --project <project-id>
+```
+
+The controller first checks the original worktree, full binding, frozen argv,
+workspace/launch evidence, same shell and every saved native key PID. Ordinary
+child-process changes do not replace the original proof. After that read-only
+identity check, it consumes one authorized recovery attempt (the cumulative
+count increases by one, without reset) and can deliver the first prompt once in
+the original native process without another agent.start or conversation. Missing
+an official native ID before the first turn does not by itself block this
+proven-unsent continuation. This is not permission to resend an earlier
+submitted/unknown prompt, infer loss from an empty-looking composer or restart
+an unproven missing-ID conversation. Legacy records with unknown native-process
+role remain fenced; migration does not construct identity from foreground PID
+order. Automated cleanup text and /exit use the same screen boundary; a blocking
+screen is not accepted with Enter merely to finish shutdown.
+
+Management diagnostics identify the original claim and report persisted waiting,
+completion, rejection or unknown results. Interrupting the command retains its
+intent so the foreground controller or a later management invocation can
+continue. An unknown release/transfer write is reconciled by reading the actual
+task and saved target claim; it is never resent or assigned replacement IDs,
+even when a read still shows the old value. Reinvoking that same decision can
+reconcile its result by targeted reads, including beside a running foreground
+worker, without taking over resource control or resubmitting. An already-cleaned
+source is not restarted. Only a definitely rejected submission can be replaced by a new explicit
+decision, with the supplied `--if-version` matching a fresh task observation. The
+numeric version may remain the same when the refusal did not change the task,
+including a definite pre-dispatch failure or permission refusal. An unknown
+submission cannot be reset or replayed; `--if-version` is never silently replaced.
+Unknown resume requests likewise retain their original claim/worktree/config
+until the actual grant can be confirmed. These targeted reads reconcile manual
+writes; automatic cleanup still relies only on a complete successful inventory
+for the original authenticated user and worker.
+
 ## Review configuration and startup
 
 Register a repository explicitly, or let the first review operation guide registration:
@@ -940,23 +1193,29 @@ cloning, authentication checks, GitHub calls, SQLite initialization and PR bound
 selection belong to review startup. An already running reviewer keeps its loaded
 configuration until its next startup.
 
-The same YAML also accepts the server client's `serverUrl` and optional
-`serverToken` fields. Review validates its own fields independently of server
-business values. The server projection requires a valid HTTP(S) origin and
+All review settings belong under the `review` mapping. The same YAML also
+accepts the server client's `serverUrl` and optional `serverToken` fields, the
+`worker` mapping and generated `workerId`. Review validates its own fields
+independently of server business values. The server projection requires a valid HTTP(S) origin and
 validates any configured token and its transport. The shared parser still rejects
 invalid YAML, duplicate keys and unknown root fields. Registration can add the
 first review repository to a server-only file while preserving its server
-settings and comments.
+settings and comments. Unknown fields inside `review` are rejected by review
+commands. Existing flat review settings must be moved together under `review`,
+including `repositoryRoot`, `repositories`, numeric options and Copilot options;
+remove their old root entries. The old root fields are rejected, with no automatic
+migration.
 
 A configuration with an explicit addition root is:
 
 ```yaml
-repositoryRoot: ~/daynights
-copilotModel: auto
-copilotReasoningEffort: high
-repositories:
-  - remote: https://github.com/OWNER/REPO.git
-    path: ../daynights/github.com/owner/repo
+review:
+  repositoryRoot: ~/daynights
+  copilotModel: auto
+  copilotReasoningEffort: high
+  repositories:
+    - remote: https://github.com/OWNER/REPO.git
+      path: ../daynights/github.com/owner/repo
 ```
 
 `copilotModel` and `copilotReasoningEffort` are independent optional fields for
@@ -968,11 +1227,11 @@ effort levels and model/effort compatibility; Daynight maintains no static lists
 corresponding override and preserves Copilot's choice, so neither, either or both
 may be configured. Changes take effect on the next `review run` startup. Guided configuration
 and repository registration preserve both fields and YAML comments. The server
-configuration projection recognizes these shared keys without validating their
+configuration projection recognizes the `review` section without validating its
 review-owned values.
 
-`repositoryRoot` defaults to `~/daynights`. It is used only when `add-repo` has no
-`--path`: the command derives filesystem-safe components from the normalized
+`review.repositoryRoot` defaults to `~/daynights`. It is used only when
+`add-repo` has no `--path`: the command derives filesystem-safe components from the normalized
 host/owner/name and saves the resulting absolute repository path. A configured
 root may be absolute, config-directory-relative, or begin with `~` for the current
 OS user's home. Other users' tilde forms are rejected. Changing the root affects

package/config.example.yml

@@ -0,0 +1,65 @@
+# Shared CLI configuration: ~/.daynight/config.yml.
+# Select the sections needed for your commands and replace the example repositories
+# and local paths. Merge settings into an existing file to retain credentials and
+# other configuration; this file is a reference, not an automatically loaded config.
+
+# Service origin only: no API path, query, credentials or fragment.
+serverUrl: https://daynight.cc
+# Prefer daynight login, which saves the credential for the selected service.
+# For unattended provisioning, replace this placeholder with that origin's secret.
+# serverToken: REPLACE_WITH_CREDENTIAL_FOR_THIS_ORIGIN
+# Remove or replace an old token before changing serverUrl manually. Keep secrets
+# out of repositories and logs; files containing a token need POSIX mode 0600.
+
+# Review configuration. The numeric values below are the defaults; all are positive
+# integers, and fields ending in Ms use milliseconds.
+# Only repositoryRoot expands ~. It selects paths for future review add-repo calls
+# without --path and does not relocate repositories already registered below.
+review:
+  repositoryRoot: ~/daynights
+  pollIntervalMs: 60000
+  maxConcurrentWorker: 1
+  agentTimeoutMs: 1800000
+  maxAttempts: 3
+  retryDelayMs: 30000
+  # Optional review overrides, not defaults. Omission preserves Copilot's choices.
+  # Copilot owns supported model names, effort levels and their compatibility.
+  # copilotModel: auto
+  # copilotReasoningEffort: high
+  repositories:
+    - remote: https://github.com/OWNER/REPO.git
+      # Repository paths are absolute or relative to ~/.daynight/, never the launch
+      # directory, and do not expand ~. Keep review clones outside ~/.daynight/.
+      path: ../daynights/github.com/owner/repo
+
+# Worker configuration. Omitted values use these defaults; an empty selection
+# makes interactive worker run guide Project registration. The selected native
+# agent and Herdr must already be configured.
+worker:
+  # Used only for new worker repo registrations; independent of review's root.
+  repositoryRoot: ~/daynights
+  maxConcurrent: 1
+  pollIntervalMs: 5000
+  recoveryLimit: 3
+  agent: copilot
+  model: null
+  args: []
+  # maxConcurrent and pollIntervalMs are positive integers; pollIntervalMs uses
+  # milliseconds. recoveryLimit is nonnegative and applies to the whole worker.
+  repositories:
+    - remote: https://github.com/OWNER/REPO.git
+      # Paths follow the same config-directory-relative rule as review paths.
+      # Worker repository paths must not overlap each other or ~/.daynight/.
+      path: ../code/repo
+      # The matching Daynight project must exist. Set its actual UUID when remote
+      # discovery matches more than one project.
+      # projectId: REPLACE_WITH_MATCHING_PROJECT_UUID
+      # Repository overrides inherit fields independently for the same agent.
+      # Switching agent clears inherited model and args unless set here. Explicit
+      # null model or [] args clears that field; args replaces the entire list.
+      # agent: codex
+      # model: null
+      # args: []
+
+# workerId is generated and saved by the CLI. Keep its existing value for this
+# worker; do not copy another machine's identity into this configuration.

package/dist/api/client.d.ts

@@ -1,5 +1,5 @@
 import type { Operation } from "./operation.js";
-import type { AttachmentConsumer, CreateProjectInput, CreateTaskInput, DeleteTaskInput, ErrorDetails, Project, PutTaskAttachmentInput, ReadyTaskFilters, ServerError, Task, SetTaskStatusInput, TaskAttachment, TaskFilters, TaskGraph, UpdateTaskInput, ClaimWorkerTaskInput, CompleteWorkerTaskInput, ReleaseWorkerClaimInput, ResumeWorkerTaskInput, TransferWorkerClaimInput, UpdateWorkerClaimInput, User, Page, TaskPageQuery } from "./types.js";
+import type { AttachmentConsumer, CreateProjectInput, CreateTaskInput, DeleteTaskInput, ErrorDetails, Project, ProjectMember, PutTaskAttachmentInput, ReadyTaskFilters, ServerError, Task, SetTaskStatusInput, TaskAttachment, TaskFilters, TaskGraph, UpdateTaskInput, ClaimWorkerTaskInput, CompleteWorkerTaskInput, ReleaseWorkerClaimInput, ResumeWorkerTaskInput, TransferWorkerClaimInput, UpdateWorkerClaimInput, User, Page, TaskPageQuery } from "./types.js";
 type Context = {
     readonly operation: string;
     readonly projectId?: string;
@@ -30,6 +30,7 @@ export type ApiClient = {
     createProject(input: CreateProjectInput): Promise<Project>;
     getProject(projectId: string): Promise<Project>;
     listProjects(): Promise<readonly Project[]>;
+    listProjectMembers(projectId: string): Promise<readonly ProjectMember[]>;
     createTask(projectId: string, input: CreateTaskInput): Promise<Task>;
     getTask(projectId: string, taskId: string): Promise<Task>;
     listTasks(projectId: string, filters?: TaskFilters): Promise<readonly Task[]>;

package/dist/api/client.js

@@ -2,7 +2,7 @@ import { performance } from "node:perf_hooks";
 import { parseApiJson, stringifyApiJson } from "./json.js";
 import { OperationError } from "./operation.js";
 import { validateServerToken, validateTokenTransport } from "../config/server-token.js";
-import { canonicalId, parsePage, parseProject, parseServerError, parseTask, parseTaskGraph, parseTaskAttachment, parseUser, ProtocolError, validateAttachmentPath } from "./parse.js";
+import { canonicalId, parsePage, parseProject, parseProjectMembers, parseServerError, parseTask, parseTaskGraph, parseTaskAttachment, parseUser, ProtocolError, validateAttachmentPath } from "./parse.js";
 export class ApiError extends Error {
     operation;
     phase;
@@ -354,6 +354,8 @@ export const createApiClient = (options) => {
     const herdrMatches = (actual, expected) => actual === null || expected === null ? actual === expected : actual.session === expected.session && actual.workspaceId === expected.workspaceId && actual.paneId === expected.paneId;
     const descriptorMatches = (worker, descriptor) => worker.claimId === canonicalId(descriptor.claimId) && worker.workerId === canonicalId(descriptor.workerId) && worker.machine.id === canonicalId(descriptor.machine.id) && worker.machine.name === descriptor.machine.name && worker.platform === descriptor.platform && worker.agent === descriptor.agent && worker.worktreeId === canonicalId(descriptor.worktreeId);
     const workerMutation = (projectId, taskId, action, suffix, method, input, matches, sameValue = false) => {
+        if (Object.hasOwn(input, "continuityConfirmed"))
+            throw new Error("continuityConfirmed is no longer accepted. New executions require fresh claim and worktree IDs.");
         const project = resourceId(projectId), task = resourceId(taskId);
         taskVersion(input.version);
         return exchange({ operation: action, projectId: project, taskId: task }, `/projects/${encodeURIComponent(project)}/tasks/${encodeURIComponent(task)}${suffix}`, method, { kind: "json", parse: (value) => {
@@ -372,6 +374,10 @@ export const createApiClient = (options) => {
             return request({ operation: "project.show", projectId: project }, `/projects/${encodeURIComponent(project)}`, "GET", (value) => parseProject(value, project));
         },
         listProjects: () => list({ operation: "project.list" }, "/projects", (value) => parseProject(value), (project) => project.id),
+        listProjectMembers: (projectId) => {
+            const project = resourceId(projectId);
+            return exchange({ operation: "project.members", projectId: project }, `/projects/${encodeURIComponent(project)}/members`, "GET", { kind: "json", parse: (value) => parseProjectMembers(value, project) }, [200], undefined, true);
+        },
         createTask: (projectId, input) => {
             const project = resourceId(projectId);
             writableProperties(input.properties);