@codetreker/daynight 0.37.2 → 0.39.0

package/README.md

@@ -161,6 +161,9 @@ daynight task create --title <title> [options]
 daynight task list [--all | --status <status>] [--ready] [--assigned-to <assignee>] [--json] [--project <project-id>]
 daynight task ready [--limit <N>] [--json] [--project <project-id>]
 daynight task show <task-id> [--json] [--project <project-id>]
+daynight task step
+daynight task step list <task-id> [--json] [--project <project-id>]
+daynight task step show <task-id> <step-id> [--json] [--project <project-id>]
 daynight task update <task-id> [options]
 daynight task set-status <task-id> <status> [--claim-id <claim-id>] [--if-version <version>] [--project <project-id>]
 daynight task delete <task-id> [--remove-depends] [--if-version <version>] [--project <project-id>]
@@ -194,7 +197,8 @@ dn --skill
 
 `--skill` prints one standalone English project/task usage manual from the
 current package. It covers project selection, task queries and writes,
-dependencies, properties and attachments. Other capabilities are discovered
+dependencies, properties, attachments and ordered Step list/show reads. Other
+capabilities are discovered
 through `daynight --help`, with exact options in each subcommand's help. The
 output preserves the manual's original bytes, including YAML
 frontmatter and the final newline. The document has no package-relative
@@ -773,8 +777,12 @@ case-equivalent duplicate/cross-declared UUIDs fail before configuration or
 network access. `--clear-dependencies` sends two empty sets and conflicts with
 either dependency option. An update needs at least one mutable
 field. Create/update accept `--assigned-to <user-uuid>`; update also accepts
-`--clear-assigned-to` to send null. Omission preserves an existing assignee; the
-set/clear options conflict, and invalid UUIDs or combinations fail before
+`--clear-assigned-to` to send null. CLI creation without `--assigned-to` reads
+the signed-in account through `/me` and submits its UUID. An explicit UUID skips
+that identity lookup. A failed or cancelled lookup prevents creation; the CLI
+does not substitute an unassigned task. Update omission preserves the existing
+assignee. Direct API callers retain optional assignment and may create unassigned
+tasks by omitting `assignedTo` or sending null. The set/clear options conflict, and invalid UUIDs or combinations fail before
 configuration, Git or HTTP access. Writes accept UUIDs, not the list tokens
 me/unassigned. A real assignment change atomically sets allowAgents=false; an
 equal assignment causes no permission reset; a pure equal update preserves
@@ -918,6 +926,58 @@ allowance. Creation/update expose ordinary metadata; property-specific PR
 options are not accepted. The native HTTP create/PATCH operations still support
 atomic fields/dependencies/properties mutations.
 
+## Task Steps
+
+```bash
+daynight task step list <task-id>
+daynight task step list <task-id> --json --project <project-id>
+daynight task step show <task-id> <step-id> --json --project <project-id>
+```
+
+Steps are an independent ordered resource owned by a Task. The
+[resource contract](../../docs/spec/daynight-task-steps.md#cli-读取) owns their
+fields and read behavior. The CLI provides `list` and `show`; the parent Task's
+ordinary show/list/graph does not contain the full Steps collection. Step status
+is `todo`, `in_progress`, `done` or `skipped`, independent from Task status.
+
+Project and Task arguments are complete UUIDs. A Step argument is exactly eight
+hex characters, normalized to lowercase on input with leading zeros preserved;
+full UUIDs, prefixes and display numbers are invalid. Explicit `--project`
+works outside Git and sends the selected Steps GET directly, without hidden
+project or parent reads. Without it, normal repository project discovery runs.
+Group and operation help complete before configuration, Git or network work.
+
+List reads the complete collection once, retains saved order and prints the
+Task, exact parent Version and Steps count, followed by one-based display numbers,
+full short IDs, statuses and untruncated titles. Empty output reports zero Steps.
+Show prints the complete target title, description, status and created/updated
+timestamps with its Task/project scope and parent version. Both use visible
+terminal-control and bidi-control escapes and preserve all text. `--json` emits one complete
+StepsResource or StepResource with raw strings, every required field and exact
+int64 JSON numbers, followed by LF; it does not use a Task-list projection or
+output a bare Steps array.
+
+Typed reads validate complete fields, requested scope, canonical response IDs,
+collection uniqueness, four-state values, original text and UTC microsecond
+timestamp strings. They preserve array order and time spelling without sorting,
+rounding or filling missing values. Malformed or mismatched resources, duplicate
+IDs and read failures remain errors rather than empty collections. Reads retain
+the shared request/operation deadlines, cancellation and response-byte budgets.
+The endpoint body cap is 64 MiB, inclusive, and is combined with the configured
+response budget by taking the smaller bound. Stricter configured limits still
+win, total-operation bytes remain charged, and shared defaults do not change;
+no partial resource reaches stdout before full validation and rendering. An
+output failure can still leave partial stdout and is reported as a failure.
+Errors go to stderr with exit status 1; argument errors use 2 and success uses 0.
+A 401 includes `daynight login` guidance without automatic login or retry.
+Help, Bash/zsh completion and the standalone manual expose only these delivered
+read commands. The [server acceptance owner](../daynight-server/README.md#built-process-acceptance-and-ci-evidence)
+maps the real-service installed Node-entry read case, separate maximum-resource
+check and their normal fixture prerequisites. The packed CLI acceptance runner
+checks literal `daynight`/`dn` launchers through cross-spawn on native platforms.
+Manual copy/byte checks establish package resource fidelity separately from
+these complementary runtime and launcher checks.
+
 ## Task deletion
 
 Read the task and use its observed version when deleting it:
@@ -1317,13 +1377,25 @@ line separators and bidirectional display controls are escaped as visible text;
 Unicode titles and emoji remain readable. Full titles and owner IDs are retained,
 with Herdr responsible for fitting the label into its current terminal width.
 
-The local database has exactly these business fields:
+The local claim index has these business fields:
 
 ```text
 projects(project_id, repo_url, local_path)
 tasks(project_id, task_id, claim_id, status, agent, session_id, agent_control_mode)
 ```
 
+A separate `cleanup_schedules` table binds terminal cleanup responsibility to
+the original Project/task/claim/worktree. It retains the first deadline, failure
+count, next retry time, stage and error. It contains no notification-progress or
+resource-completion flags.
+These records preserve responsibility; they do not prove that resources stopped
+or disappeared. A cleanup target without a known worktree ID keeps its existing
+claim-index row and uses process-local backoff while rereading authoritative
+resources. It never invents an ID or another ledger. An ended row with no globally
+observed resources still enters a serialized cleanup job, which verifies actual
+absence and removes only an empty unregistered reservation. A recognized resource
+for another claim of that task remains untouched.
+
 Status is pending, active or done. Pending is an actual acquired claim waiting
 for startup; active owns startup, running, recovery or cleanup responsibility;
 done means the ended claim's resources have been cleaned. Completed rows remain,
@@ -1335,7 +1407,9 @@ The state directory belongs to the configured single service, Daynight account
 and workerId. Finish old executions before changing those identities and
 rebuilding local state. The running process pins its startup authenticated user;
 the claim-index database does not retain prior-service or prior-account recovery
-scopes. The claim index has its own `user_version=5`. All five business databases
+scopes. The claim index and cleanup schedule share `user_version=7`; upgrading
+version 5 preserves its Project and task rows, while version 6 to 7 removes
+notification submission flags and preserves the remaining cleanup schedule. All five business databases
 reset `user_version=0` after their ownership checks: the original schema and data
 are discarded, then the baseline and numbered upgrades rebuild the current
 format. This includes existing empty files and query access. Known valid nonzero
@@ -1393,8 +1467,10 @@ pane's retained reference is not saved as a newly observed session ID. A live
 agent keeps its current connection.
 
 Startup, recovery and continuation prompts require autonomous decisions within
-the task scope and existing authorization. When human intervention is necessary,
-the managed agent sets its own task's `paused` property to true with an observed
+the task scope and existing authorization. Human intervention requires specific
+information, a decision, authorization or an action that the agent cannot supply
+within that scope and authority. Before waiting for that intervention, the
+managed agent sets its own task's `paused` property to true with an observed
 exact version and confirms the same assignment and pause before waiting. It
 reports the issue and retains session context; the user chooses how to respond.
 After verifying resolution, the original assignment and permission to resume,
@@ -1402,10 +1478,13 @@ it clears the pause and confirms false or absence before continuing. Independent
 user restrictions still apply. The [managed workflow](src/commands/skill/skills/using-daynight/references/autopilot-managed-task.md#request-user-interaction)
 owns readback, failure and conflict handling.
 
-Ordinary review and CI waits remain ongoing execution: the agent waits, checks
-results and continues delivery without ending its turn or setting a pause just
-because a poll times out. Fixed native full access and folder trust apply to
-every fresh/resumed process; task delivery remains within its business authorization.
+Pending PR review, required reviewer approval and CI remain ongoing execution,
+including reviews performed by a person. Pending results and polling timeouts
+do not justify setting `properties.paused=true`, requesting user intervention
+or ending the turn. The agent monitors results and continues delivery while
+honoring independent user pauses, restrictions and revocations. Fixed native
+full access and folder trust apply to every fresh/resumed process; task delivery
+remains within its business authorization.
 
 For a still-owned active claim, each patrol observes the live agent. An
 interactive-ready agent that is not launching and has no first input pending
@@ -1437,10 +1516,12 @@ agent's ID may fill a NULL record; inactive pane references remain excluded.
 
 The NULL rule also covers interruption before a newly started native ID was saved.
 It retains the task, claim and worktree and requires no history scan or approval
-gate. A failed resume of a known ID remains an error. Launch/input receipts,
-process observations, retries and cleanup progress exist only in the current
-call or process. Recovery counts reset on restart; reaching recoveryLimit keeps
-the task active with a visible error until explicit retry or another run.
+gate. A failed resume of a known ID remains an error. Business launch/input
+receipts, process observations and execution retries remain local to the current
+call or process in Herdr mode. Terminal cleanup retains its separate persistent
+schedule. Herdr execution recovery counts reset on restart; reaching
+recoveryLimit keeps the task active with a visible error until explicit retry or
+another run. Web recovery follows the persistent rules below.
 
 For human input, use another interactive terminal:
 
@@ -1485,41 +1566,72 @@ lost across a process interruption.
 
 During normal reconciliation, when the original claim is absent from a
 successful complete inventory, the worker asks its agent to release attributable
-temporary files, services and processes outside the worktree. It waits at most
-ten minutes for this cleanup attempt, stops the agent, closes its workspace, removes the matching worktree
-and marks the local row done. Done, release and force withdrawal have the same terminal
-resource rule. Failed stop or deletion retains responsibility and the error.
-
-Known-target cleanup and shutdown observe that Herdr execution directly;
-worktree deletion validates only its target Git registration and directory.
-Unrelated repository or sibling-worktree registration errors are reported
-separately and do not prevent a healthy agent from stopping.
-
-After the cleanup message is successfully submitted, a subsequent patrol that
-observes idle completes the cleanup turn and proceeds to stop the agent and
-close its workspace. Sequence counters and interactive readiness are not
-required. A pre-notification observation or the submission receipt itself
-cannot finish cleanup. Failed or unknown notification results retain their error
-and the current bounded wait, without automatic replay. Reaching the deadline
-still proceeds through actual stop confirmation. Idle in this terminal cleanup
-phase does not complete the business task.
-
-Cleanup timing and progress are in memory. Polls do not extend the current
-attempt's deadline; after a crash, the next successful reconciliation observes
-remaining resources and starts a new cleanup attempt and timer. Cleanup prompts
-may repeat. Separate tasks have independent bounded jobs, so one held RPC does
-not postpone another task's cleanup. A cleanup already selected in the current
-process can continue during later service-read failures.
+temporary files, services and processes outside the worktree. It gives the
+original agent an advisory cleanup opportunity until fresh observations permit
+stopping or the original ten-minute deadline expires, then stops the agent,
+closes its workspace and reconciles the matching worktree. Actual resource
+absence permits marking the local row done. Done, release and force withdrawal have the same terminal
+resource rule. Cleanup observations, notification, stop/close, and worktree
+verification and deletion each have a five-minute operation budget, including
+their RPC, cleanup provenance HTTP verification, Controller cleanup requests
+and Git commands. Notification and
+Controller cleanup-response waits are also capped by the remaining ten-minute
+agent deadline. Ordinary execution keeps its existing operation budgets. Failed
+stop or deletion retains responsibility and the error.
+
+Known-target cleanup observes that Herdr execution directly; worktree deletion
+validates only its target Git registration and directory. Shutdown proves the
+original processes stopped without depending on Git discovery or cleanup retry
+backoff. Unrelated repository or sibling-worktree registration errors are
+reported separately and do not prevent a healthy agent from stopping.
+
+Each bounded Herdr cleanup call sends one advisory message to the still-live
+original agent, then reads fresh snapshots until idle permits stopping, resources
+disappear, or the original deadline expires. Sequence counters and interactive
+readiness are not required. Failed or unknown notification results retain their
+error and the same deadline without replay inside that call. Herdr provides no
+queryable per-input operation ID, so interruption or restart can notify the
+still-live agent again. The Worker keeps no notification progress ledger. Idle
+selects when to stop; only current process and workspace absence establishes
+resource cleanup. It does not complete the business task.
+
+Terminal cleanup responsibility is recorded before notification or resource
+removal. The original resource identity, deadline and retry policy survive
+failure, cancellation and restart. Resource completion is always observed from
+Herdr, the Controller journal, OS process instances, Git and the filesystem.
+A missing worktree directory is already removed; its owned Git administration
+is a separate remaining resource. Empty reservations and final-unlink residues
+can be removed nonrecursively, while unattributable nonempty directories remain
+protected. Worktree preparation can likewise remove an empty unregistered
+reservation left before Git add and then create the intended checkout. Such stray
+directories do not invalidate repository-wide discovery.
+Restart resumes the same claim's remaining resources without starting business
+execution. Previously confirmed cleanup responsibility can continue during later
+service-read failures.
+
+Failed claims retry independently after 1, 2, 4, 8, 16, 32 and then at most 60
+seconds, when normal reconciliation next observes eligibility. Backoff does not
+spend execution recovery budget or release a capacity slot. Other eligible
+cleanup and healthy execution continue under the existing capacity limit. Errors
+identify the failed stage and next retry time, distinguishing unconfirmed native
+stop from a stopped agent awaiting backend closure, archive upload or worktree
+removal. If a retry-state write fails, the current process retains bounded
+backoff and both errors without claiming that the latest decision is durable.
 
 Ctrl+C stops acquisition and scheduling, cancels all running jobs including
 terminal cleanup, and joins them before directly stopping agents and closing
-their workspaces. Process exit sends no cleanup prompt and does not wait for a
-cleanup turn. It preserves claims, worktrees, native session IDs and all
-unfinished active/pending rows, including those whose ownership has ended. The
-next run uses normal inventory reconciliation to re-enter terminal cleanup for
-ended claims. External temporary resources may remain after direct interruption.
-Normal completion, release, withdrawal and manual-control cleanup retain their
-notification and removal sequence. Pending stop confirmations must settle before the private
+their workspaces. Process exit sends no cleanup prompt, does not wait for a
+cleanup turn or retry backoff, and does not repeat archive upload or worktree
+removal. It preserves claims, worktrees, native session IDs, unfinished
+active/pending rows and existing terminal cleanup schedules, including ended
+claims. The next run restores each saved responsibility and original deadline, then
+verifies remaining resources. A retained Herdr cleanup
+still requires its original backend even if current configuration uses Web;
+backend initialization and retries remain local to that cleanup job and cannot
+block unrelated Web execution. External temporary resources may remain after
+direct interruption.
+Normal completion, release, withdrawal and manual-control cleanup use the same
+advisory notification and observed resource-removal targets. Pending stop confirmations must settle before the private
 Herdr instance stops; stop errors remain visible, and uncertain stopping retains
 that instance and the affected resources. Before closing a verified orphan
 workspace with no local task row, cleanup and exit save its observed native
@@ -1575,22 +1687,46 @@ required separately from protocol tests.
 
 The primary worker database retains its claim and native-session index. Web
 execution state lives separately in `~/.daynight/worker/web-executions.sqlite`
-with its own format version 1. Version 0 resets its schema and data through the
-common SQLite policy; current-version CRUD retains the existing JSON parser and
-default-field behavior. Private launch tickets and Controller
+with its own format version 2. The version 1 upgrade removes redundant cleanup
+input/results and stopped/closed/deleted flags, preserving cleanup intent,
+identity and deadline. Version 0 resets its schema and data through the common
+SQLite policy. Private launch tickets and Controller
 journals live under `~/.daynight/controller/`; journals retain their independent
-format version 5. Both Worker stores must open successfully before scheduling.
+format version 6. Both Worker stores must open successfully before scheduling.
 Web restart reconnects to a surviving Controller. Starting a new generation
 requires proof that the original native processes stopped and the exact native
 session ID. A missing journal or ID cannot authorize a replacement conversation.
 Unknown initial inputs and operations are reconciled without replay.
 
-Normal Web terminal cleanup keeps its original cleanup operation and deadline,
-then proves native stop before deleting the task worktree. Worker shutdown stops
+Web recovery counts and diagnostic pause reasons persist across worker restarts.
+Exhausted automatic recovery or the execution failure threshold pauses the
+original execution before worktree preparation, Controller initialization,
+launch or native input. An older exhausted stopped record without a pause reason
+or orderly-shutdown provenance is reconciled from its journal and complete
+process-stop proof before any launch;
+uncertain stop evidence retains a diagnostic wait. A healthy final recovery
+and its orderly shutdown restart are not paused merely because the count has
+reached its limit.
+
+A paused execution keeps its active claim, native session ID, worktree and
+capacity slot. The worker continues publishing `waiting` with `herdr:null` even
+when execution is blocked. A failed summary update is retried using a newly read
+task version without consuming native recovery budget; an unchanged confirmed
+summary is not written again. Ordinary restart and shutdown cannot clear this
+pause. It is separate from `task.properties.paused`, which controls Herdr
+continuation pings.
+
+Normal Web terminal cleanup keeps its original cleanup operation identity and
+deadline. Every attempt reads its operation receipt from the original Controller
+journal, checks original process instances against the OS, reconciles the IPC
+endpoint and remaining Git resources, and uses the resulting current observations
+to determine completion. A recorded done status never suppresses these checks.
+Native stop and the service's ready archive receipt precede worktree removal. Worker shutdown stops
 owned processes while preserving unfinished claims, worktrees and native history.
 The [session design](../../docs/design/task-session-protocol.md) owns stopping,
-recovery and relay details; the Herdr lifecycle above retains its process-local
-recovery and cleanup semantics.
+recovery and relay details. Herdr business recovery remains process-local; both
+modes retain terminal cleanup responsibility, its original deadline and retry
+policy in the independent schedule, without resource-completion flags.
 
 The worker starts `daynight controller codex|claude|copilot --launch-id <uuid>`
 from a private immutable launch ticket. Its cwd, profile, claim, generation,
@@ -1684,11 +1820,22 @@ Retry performs one attempt for an active claim still owned by this worker:
 daynight worker retry <task-id> --claim-id <claim-id> --project <project-id>
 ```
 
-It connects the live agent or resumes its recorded native session. A NULL ID
-starts a fresh conversation in the same task worktree with an `info` event. The
-claim and agent type remain; pending rows are started through normal run
-scheduling. After the attempt, run connects to the actual surviving resource. Retry does not
-persist a permit or a cumulative cross-restart budget.
+In Herdr mode, retry connects the live agent or resumes its recorded native
+session. A NULL ID starts a fresh conversation in the same task worktree with an
+`info` event. Its extra attempt and recovery count remain process-local.
+
+In Web mode, retry persists one authorization to recover the original native
+session. It still requires the original active claim, matching generation and
+complete proof that the old processes stopped. Missing native identity or stop
+evidence cannot authorize a replacement conversation or a repeated initial
+assignment. Authorization does not report successful execution: the summary
+remains waiting through initialization until a ready or working observation, and failure
+pauses again. The attempt remains bound to that generation across ticks and
+worker restarts; initialization cannot authorize another generation.
+
+Both modes retain the claim and agent type; pending rows are started through
+normal run scheduling. After the attempt, run reconciles the actual surviving
+resource and any persistent Web pause.
 
 Release validates current Project access, source owner/admin, original claim
 and exact supplied version. Its ordering is:

package/dist/api/client.d.ts

@@ -1,10 +1,11 @@
-import type { ThreadReadQuery, PostThreadMessageInput, ThreadMessage, ThreadPage } from "./types.js";
+import type { StepsResource, StepResource, ThreadReadQuery, PostThreadMessageInput, ThreadMessage, ThreadPage } from "./types.js";
 import type { Operation } from "./operation.js";
-import type { AttachmentConsumer, CreateProjectInput, CreateTaskInput, DeleteTaskInput, ErrorDetails, Project, ProjectAccess, ProjectMember, PutTaskAttachmentInput, ReadyTaskFilters, ServerError, Task, SetTaskStatusInput, TaskAttachment, TaskFilters, TaskGraph, UpdateTaskInput, ClaimWorkerTaskInput, CompleteWorkerTaskInput, ReleaseWorkerClaimInput, ResumeWorkerTaskInput, WithdrawWorkerClaimInput, UpdateWorkerClaimInput, User, Page, TaskPageQuery, WorkerReport, WorkerReportReceipt, TaskPropertyResource, TaskPropertySchema, SetTaskPropertyInput, RemoveTaskPropertyInput } from "./types.js";
+import type { AttachmentConsumer, CreateProjectInput, CreateTaskInput, DeleteTaskInput, ErrorDetails, Project, ProjectAccess, ProjectParticipant, PutTaskAttachmentInput, ReadyTaskFilters, ServerError, Task, SetTaskStatusInput, TaskAttachment, TaskFilters, TaskGraph, UpdateTaskInput, ClaimWorkerTaskInput, CompleteWorkerTaskInput, ReleaseWorkerClaimInput, ResumeWorkerTaskInput, WithdrawWorkerClaimInput, UpdateWorkerClaimInput, User, Page, TaskPageQuery, WorkerReport, WorkerReportReceipt, TaskPropertyResource, TaskPropertySchema, SetTaskPropertyInput, RemoveTaskPropertyInput } from "./types.js";
 type Context = {
     readonly operation: string;
     readonly projectId?: string;
     readonly taskId?: string;
+    readonly stepId?: string;
 };
 export type ApiPhase = "prepare" | "request" | "response" | "protocol" | "pagination";
 export declare class ApiError extends Error {
@@ -12,6 +13,8 @@ export declare class ApiError extends Error {
     readonly phase: ApiPhase;
     readonly projectId?: string;
     readonly taskId?: string;
+    readonly stepId?: string;
+    readonly serverMessage?: string;
     readonly status?: number;
     readonly code?: string;
     readonly requestId?: string;
@@ -29,6 +32,8 @@ export declare class ApiError extends Error {
     });
 }
 export type ApiClient = {
+    listTaskSteps(projectId: string, taskId: string): Promise<StepsResource>;
+    getTaskStep(projectId: string, taskId: string, stepId: string): Promise<StepResource>;
     readTaskThread(projectId: string, taskId: string, query: ThreadReadQuery): Promise<ThreadPage>;
     postTaskThreadMessage(projectId: string, taskId: string, input: PostThreadMessageInput): Promise<ThreadMessage>;
     getCurrentUser(): Promise<User>;
@@ -37,7 +42,7 @@ export type ApiClient = {
     getProject(projectId: string): Promise<Project>;
     getProjectAccess(projectId: string): Promise<ProjectAccess>;
     listProjects(): Promise<readonly Project[]>;
-    listProjectMembers(projectId: string): Promise<readonly ProjectMember[]>;
+    listProjectMembers(projectId: string): Promise<readonly ProjectParticipant[]>;
     createTask(projectId: string, input: CreateTaskInput): Promise<Task>;
     getTask(projectId: string, taskId: string): Promise<Task>;
     getTaskPropertySchema(): Promise<TaskPropertySchema>;

package/dist/api/client.js

@@ -1,17 +1,20 @@
 import { parseTaskPropertyResource, parseTaskPropertySchema, readWorkerClaim } from "./task-properties.js";
 import { resourcePath } from "./resource-path.js";
+import { canonicalStepId, decodeStepsJsonSource, parseStepResource, parseStepsResource, TASK_STEPS_RESPONSE_BYTES } from "./task-steps.js";
 import { decodeThreadJsonSource, parseThreadMessage, parseThreadPage, THREAD_MESSAGE_BYTES, THREAD_PAGE_BYTES } from "./thread.js";
 import { isNonemptyText } from "../platform/text.js";
 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, parseProjectAccess, parseProjectMembers, parseServerError, parseTask, parseTaskGraph, parseTaskAttachment, parseUser, parseWorkerReportReceipt, ProtocolError, validateAttachmentPath } from "./parse.js";
+import { canonicalId, parsePage, parseProject, parseProjectAccess, parseProjectParticipants, parseServerError, parseTask, parseTaskGraph, parseTaskAttachment, parseUser, parseWorkerReportReceipt, ProtocolError, validateAttachmentPath } from "./parse.js";
 export class ApiError extends Error {
     operation;
     phase;
     projectId;
     taskId;
+    stepId;
+    serverMessage;
     status;
     code;
     requestId;
@@ -20,7 +23,7 @@ export class ApiError extends Error {
     confirmedRefusal;
     confirmedMessageId;
     constructor(context, phase, options) {
-        const target = [context.projectId === undefined ? "" : ` project=${context.projectId}`, context.taskId === undefined ? "" : ` task=${context.taskId}`].join("");
+        const target = [context.projectId === undefined ? "" : ` project=${context.projectId}`, context.taskId === undefined ? "" : ` task=${context.taskId}`, context.stepId === undefined ? "" : ` step=${context.stepId}`].join("");
         const server = options.serverError;
         const reason = server === undefined
             ? options.cause instanceof OperationError ? options.cause.message : phase === "protocol" || phase === "pagination" ? "Invalid server response." : "Local HTTP request failed."
@@ -35,11 +38,14 @@ export class ApiError extends Error {
             this.projectId = context.projectId;
         if (context.taskId !== undefined)
             this.taskId = context.taskId;
+        if (context.stepId !== undefined)
+            this.stepId = context.stepId;
         if (options.status !== undefined)
             this.status = options.status;
         if (server !== undefined) {
             this.code = server.code;
             this.requestId = server.requestId;
+            this.serverMessage = server.message;
         }
         if (details !== undefined)
             this.details = details;
@@ -413,6 +419,22 @@ export const createApiClient = (options) => {
             } }, [200], { kind: "json", value: input }, true);
     };
     return {
+        listTaskSteps: (projectId, taskId) => {
+            const project = resourceId(projectId), task = resourceId(taskId);
+            return exchange({ operation: "task.step.list", projectId: project, taskId: task }, resourcePath("projects", project, "tasks", task, "steps"), "GET", {
+                kind: "json", requirePrincipal: true, responseBytes: TASK_STEPS_RESPONSE_BYTES, decodeJsonSource: decodeStepsJsonSource,
+                parse: (value) => parseStepsResource(value, project, task),
+            }, [200], undefined, true);
+        },
+        getTaskStep: (projectId, taskId, stepId) => {
+            const project = resourceId(projectId), task = resourceId(taskId), step = canonicalStepId(stepId);
+            if (step === null)
+                throw new Error("Step ID must contain exactly eight hexadecimal characters.");
+            return exchange({ operation: "task.step.show", projectId: project, taskId: task, stepId: step }, resourcePath("projects", project, "tasks", task, "steps", step), "GET", {
+                kind: "json", requirePrincipal: true, responseBytes: TASK_STEPS_RESPONSE_BYTES, decodeJsonSource: decodeStepsJsonSource,
+                parse: (value) => parseStepResource(value, project, task, step),
+            }, [200], undefined, true);
+        },
         readTaskThread: (projectId, taskId, query) => {
             const project = resourceId(projectId), task = resourceId(taskId);
             if (!Number.isInteger(query.count) || query.count < 1 || query.count > 100 || typeof query.details !== "boolean" || query.beforeId !== undefined && query.afterId !== undefined)
@@ -460,7 +482,7 @@ export const createApiClient = (options) => {
         },
         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);
+            return exchange({ operation: "project.members", projectId: project }, `/projects/${encodeURIComponent(project)}/members`, "GET", { kind: "json", parse: (value) => parseProjectParticipants(value, project) }, [200], undefined, true);
         },
         createTask: (projectId, input) => {
             const project = resourceId(projectId);