@codetreker/daynight 0.32.1 → 0.38.0

package/README.md

@@ -1,15 +1,24 @@
 # Daynight CLI
 
 The `@codetreker/daynight` package provides the `daynight` command and its `dn`
-alias. Use it to manage server-backed projects, tasks and attachments, install
-the `using-daynight` skill for coding agents, run foreground task workers through
+alias. Use it to manage server-backed projects, tasks, discussion threads and
+attachments, install the `using-daynight` skill for coding agents, run foreground
+task workers through
 Herdr or browser-connected native Controllers, and run a local GitHub PR reviewer through Copilot CLI. Both command names
-share configuration and behavior.
+share configuration and behavior. Supported native platforms are Linux, Windows
+and Apple Silicon (ARM64) macOS. Intel macOS is unsupported.
 
 See the [project overview](../../README.md) for the browser workspace and service,
 and the [development guide](../../docs/development.md) for source builds,
-validation, package versions and npm publication. Each command's `--help` owns
-its exact usage. Review execution additionally requires Git, an authenticated
+validation, package versions and npm publication. Ordinary test and installed
+acceptance suites exclude stress workloads. From this package, `pnpm test:stress`
+builds the CLI and runs the rendering and full Session-v2 `.stress.ts` suites;
+`pnpm test:stress:budgets` runs the server validation gate with the four full
+128 MiB/256 MiB installed-CLI byte probes. The latter requires an isolated
+`DAYNIGHT_TEST_DATABASE_URL` and the [server validation prerequisites](../daynight-server/README.md#validate).
+Both commands are explicit local-only validation and refuse CI. The
+[local stress guide](../../docs/development.md#local-stress-validation) owns
+selection and receipt interpretation. Each command's `--help` owns its exact usage. Review execution additionally requires Git, an authenticated
 GitHub CLI and Copilot CLI on `PATH`.
 
 - [Install and update](#install-and-update)
@@ -22,6 +31,7 @@ GitHub CLI and Copilot CLI on `PATH`.
 - [Project management](#project-management)
 - [Task management](#task-management)
 - [Task deletion](#task-deletion)
+- [Task discussion threads](#task-discussion-threads)
 - [Task attachments](#task-attachments)
 - [Worker configuration and startup](#worker-configuration-and-startup)
 - [Worker manual management](#worker-manual-management)
@@ -148,13 +158,15 @@ daynight project list [--json]
 daynight project show <project-id> [--json]
 daynight task
 daynight task create --title <title> [options]
-daynight task list [--all | --status <status>] [--ready] [--json] [--project <project-id>]
+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 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>]
 daynight task graph <task-id> [--depends-only] [--json] [--project <project-id>]
+daynight task thread read <task-id> [--before-id <message-id> | --after-id <message-id>] [--count=N] [--details] [--project <project-id>]
+daynight task thread post <task-id> --body <text> [--reply-to <message-id>] [--claim-id <claim-id>] [--project <project-id>]
 daynight task attachment
 daynight task attachment put <task-id> <file> [--path <relative-path>] [--project <project-id>]
 daynight task attachment list <task-id> [--tree | --json] [--project <project-id>]
@@ -417,9 +429,7 @@ keep the credential name within 100 characters. The credential never expires by
 The Web account's token manager can set a future expiration, restore “Never expires”, or
 revoke it. Changing expiration keeps the same credential, so the saved CLI login
 continues without replacing its secret. Expired or revoked credentials cannot be
-revived. The [token manager mockup](../../packages/daynight-web/tests/mockups/tokens.html)
-shares the production components and styles for creating tokens and editing
-expiration, including conflict and uncertain-result states. A credential
+revived. A credential
 represents the account's current project permissions. `daynight logout` revokes the current credential and removes
 its local value after a confirmed response; an already invalid credential is
 removed locally. Network or unconfirmed failures remain visible. Configuration
@@ -553,6 +563,8 @@ daynight task list --allow-agents false --ready
 daynight task list --ready
 daynight task list --all --json
 daynight task list --status in_progress --json
+daynight task list --ready --assigned-to me --json
+daynight task list --assigned-to unassigned --json
 daynight task show <task-id> --json
 daynight task properties <task-id> --json
 daynight task properties --schema --json
@@ -563,6 +575,9 @@ daynight task update <task-id> --allow-agents true --if-version <version>
 daynight task create --title "Check Windows build" --required-platform windows
 daynight task update <task-id> --required-platform macos --if-version <version>
 daynight task update <task-id> --clear-required-platform --if-version <version>
+daynight task create --title "Review installation" --assigned-to <user-uuid>
+daynight task update <task-id> --assigned-to <user-uuid> --if-version <version>
+daynight task update <task-id> --clear-assigned-to --if-version <version>
 daynight task set-status <task-id> <status> [--claim-id <claim-id>] [--if-version <version>] [--project <project-id>]
 daynight task update <task-id> --depends-on <task-a> --depends-on <task-b>
 daynight task update <task-id> --clear-dependencies
@@ -600,7 +615,7 @@ in the root `.gitignore`. A cached binding is verified against the server on eac
 use and remains stable if another project later shares that repository.
 
 Creation starts in `todo` with `allowAgents=false` and unrestricted
-`requiredPlatform=null` unless explicitly set. Unset properties remain absent;
+`requiredPlatform=null` and `assignedTo=null` unless explicitly set. Unset properties remain absent;
 creation does not inject a PR array or worker null. `task set-status <id> <status>`
 sets `todo`, `in_progress` or `done`, including reopening and direct completion.
 Every project member may use ordinary status setting. Active worker completion
@@ -622,7 +637,7 @@ Entering in_progress or done requires all direct prerequisites, ordinary and
 external, to be done. Reopening done requires no direct in-progress or done
 dependents. Refusals return sorted blocking task IDs without cascading changes.
 The project transaction serializes status and dependency writes and preserves
-materials, properties/PRs, permission, both dependency sets and attachments.
+materials, assignedTo, properties/PRs, permission, both dependency sets and attachments.
 
 Migration `014_task_status_assignment.sql` converts historical proposed rows
 to todo, increments only those versions and updates their update time while
@@ -728,7 +743,26 @@ service order across all pages. This order applies to human and JSON results.
 `task ready` accepts neither `--status` nor `--cursor`. `task list` supports the
 same permission and compatibility filters across every matching page. Both are
 automatic-selection conditions independent of readiness; explicitly designated
-execution retains the manual exception.
+execution retains the manual exception. List also accepts
+`--assigned-to <user-uuid|me|unassigned>`, combined with its other filters and
+preserved across every page. `task ready` has no assignee option; use
+`task list --ready --assigned-to me` for that intersection. Automatic acquisition
+requires the task to be assigned to the worker's authenticated account, in addition
+to permission and other eligibility checks. Existing claim inventory and manual
+control remain execution-based; the
+[self-assigned acquisition decision](../../.agents/notes/implemented/architecture/2026-11-03-worker-self-assigned-claims.md)
+owns the runtime rule.
+
+For `me`, each successful task-page response must carry one canonical
+Daynight-User-ID, even when its items array is empty. A complete list traversal
+binds its first successful page to that identity and rejects a different later
+principal or a task assigned to someone else. The binding is per traversal, not
+a global client cache. UUID and unassigned filters also verify every result;
+mismatches are protocol errors, not locally discarded rows. No extra `/me`
+request is issued. Non-me requests without a configured expectedUserId retain
+their existing optional-header behavior. Error responses retain the existing
+service-error and configured-principal admission behavior; me adds no new
+error-response header requirement.
 
 Updates preserve omitted fields; an empty description clears it. Repeated
 `--depends-on` and `--external-depends-on` declare the complete ordinary and
@@ -738,8 +772,22 @@ only those external edges. IDs are canonicalized and sorted; malformed and
 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. `--allow-agents true|false` explicitly changes automatic-execution
-permission; omitted preserves it. Creation rejects the option. Existing tasks
+field. Create/update accept `--assigned-to <user-uuid>`; update also accepts
+`--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
+version and timestamps. Other supplied fields keep their ordinary mutation
+rules. Actual changes are refused while in_progress. Assignment grants neither project access nor
+control of another worker, Session or archive.
+
+`--allow-agents true|false` explicitly changes automatic-execution permission;
+omission preserves it when assignment does not change. Creation rejects the option. Existing tasks
 receive true through migration without changing versions or business timestamps.
 A matching same-value permission PATCH retains version and time, while a stale
 version still conflicts and an actual in-progress toggle fails atomically.
@@ -752,8 +800,12 @@ are refused atomically. Explicit manual status setting remains available for eve
 requirement. The query platform selects candidates; it does not configure or
 prove the environment of a future worker.
 By default the CLI reads the task version before PATCH; `--if-version <n>`
-uses that exact positive int64 version. Conflicts and failed writes are reported
-without automatic retries.
+uses that exact positive int64 version without a task pre-read. Existing project
+resolution/admission still applies. Null clearing is serialized literally; only
+undefined fields are omitted. A normal write consumes the full Task response
+without a post-write GET or a name lookup. A combined update may advance its
+version for other fields, so v+1 alone does not establish an assignee change.
+Conflicts and failed writes are reported without automatic retries.
 
 Text options accept both separated values and `--option=value`. Inline assignment
 splits at the first equals sign and supports leading dashes, such as
@@ -764,29 +816,35 @@ inline assignment. Attachment `put` declares its `--path` as text, accepting
 paths starting with a dash. Property set/remove also accept this terminator for
 literal property/value positionals; other operations retain their declared syntax.
 
-The internal typed ApiClient accepts optional `workerId` on TaskFilters and
-TaskPageQuery. It requests only the authenticated user/worker active claims and
-validates active state and matching worker ID in responses. `listTasks` returns
+The internal typed ApiClient accepts optional `assignedTo` and `workerId` on
+TaskFilters and TaskPageQuery. Assignment selectors accept `me`, `unassigned` or
+a user UUID; the worker uses `me` for new candidates across every page. With
+workerId, the client requests only the authenticated user/worker active claims
+and validates active state and matching worker ID in responses. `listTasks` returns
 only after every page succeeds; `listTaskPage` remains partial. A workerId-only
 traversal across all relevant projects provides ownership inventory; extra filters
-or incomplete pages cannot authorize cleanup. This field is not a public task CLI
-option.
+or incomplete pages cannot authorize cleanup. These filters are not public task
+CLI options.
 
 Human task lists use labeled blocks containing ID, project, title, complete
 properties, status, readiness, automatic-execution permission, required platform,
-dependencies and blocking. Property rows are ordered by name and rendered as
+assignee, dependencies and blocking. Property rows are ordered by name and rendered as
 terminal-safe JSON; missing keys are not replaced with default values.
 Description, version and timestamps
 remain available in show, ready, create and update output. Graph nodes include
-state, permission, required platform, dependencies, blocking and title-preview truncation flags.
+state, permission, required platform, assignee, dependencies, blocking and
+title-preview truncation flags.
 Task and graph decoders require a boolean `allowAgents`; missing, null or
 nonboolean values are protocol errors. They also require `requiredPlatform`
 as null or one of the three platform enums; missing keys or other values fail
 without a runtime default. Human output uses `Required platform: any` for null
-and the enum otherwise. Queries support
+and the enum otherwise. `assignedTo` is also required as null or a canonical
+local user UUID on every Task and graph node; missing, malformed or noncanonical
+values fail instead of defaulting. Human output adds `Assigned to: USER_UUID` or
+`Assigned to: unassigned`, with no profile request or rule narration. Task metadata queries support
 `--json`: task `list` returns every matching task in one array, omitting only
-`description` while retaining every other API field, including raw PR strings,
-version and timestamps. This applies to the default list and every filter,
+`description` while retaining every other API field, including explicit nullable
+assignedTo, raw PR strings, version and timestamps. This applies to the default list and every filter,
 including `--all`. Project lists retain all API fields. Task `ready` returns its
 selected full tasks as an array, details return one full resource, and graphs
 return the selected task-chain API object unless `--depends-only` projects the
@@ -904,6 +962,68 @@ outcome unknown. The [deletion requirements](../../docs/spec/daynight-task-delet
 and [design](../../docs/design/daynight-task-deletion.md) own retained history,
 reference removal and cache invalidation.
 
+## Task discussion threads
+
+```bash
+daynight task thread read <task-id>
+daynight task thread read <task-id> --after-id <last-read-message-id> --count=20
+daynight task thread read <task-id> --before-id <first-shown-message-id> --count=20
+daynight task thread read <task-id> --details --project <project-id>
+daynight task thread post <task-id> --body 'What should the retry policy be?'
+daynight task thread post <task-id> --body 'Use an explicit retry decision.' --reply-to <message-id>
+daynight task thread post <task-id> --body 'The check passed.' --claim-id <active-claim-id>
+```
+
+A Thread holds durable discussion independently of task execution. Reads and
+posts work before execution, while its original environment is offline, and
+after completion. Messages are immutable and replies refer to messages in the
+selected task. Posting neither changes task metadata nor wakes an Agent.
+Descriptions and attachments remain the owners of effective requirements,
+solutions and formal results; Sessions hold execution content.
+
+Read fetches one page, defaulting to the latest messages. `--count=N` accepts
+1 through 100 and defaults to 20; the CLI always sends that value explicitly.
+`--before-id` and `--after-id` are mutually exclusive. Messages display from old
+to new with complete Id, Author and account Id, millisecond UTC CreatedAt,
+optional ReplyTo, and complete Message. Agent authors also have `Agent: True`.
+`--details` expands verified claim, worker and provider attribution. Thread
+commands provide readable text and do not accept `--json`.
+
+`... Has more messages before` appears above a page with earlier messages;
+`Has more messages after...` appears below a page with later messages. Continue
+history with the first displayed Id and incremental reading with the last
+fully consumed displayed Id. The 256 KiB output budget can reduce the page
+below its requested count; complete messages remain contiguous and bodies are
+never truncated. A post receipt cannot advance the read position: after reading
+A, another person's B and a local post C must still be read from A.
+
+Post requires nonblank `--body`, preserving its original whitespace. For text
+beginning with a dash, use `--body=-example`. The service generates the message
+Id and authenticates the author. Omit `--claim-id` for an ordinary account post;
+provide a current claim explicitly for verified Agent attribution. The CLI does
+not infer a claim or accept a client message Id, version or submission token.
+`--reply-to` is optional and must identify a message in the same task.
+
+Terminal text escapes dangerous controls. Multiline Message lines are indented,
+retain LF and TAB, and encode literal backslashes before visible control
+escapes; DEL is `\x7f`, CR is `\r`, and other unsafe controls use `\uXXXX`.
+The representation preserves the full body without executing terminal escapes.
+Success prints `Message posted.`, the complete Id and optional ReplyTo, without
+repeating the body. An uncertain post exits with a clear unknown-outcome message.
+Read the Thread before deciding whether to send again; equal text cannot prove
+that a particular request succeeded. The CLI never automatically repeats POST.
+
+The [Thread requirements](../../docs/spec/daynight-task-thread.md) own the
+service contract; the [CLI design](../../docs/design/task-thread-cli.md) owns
+source validation, rendering and submission confirmation. Explicit `--project`
+uses the supplied UUID directly for the Thread request; otherwise the existing
+Git binding resolves the project. Origin and credential remain fixed for one
+invocation. Argument errors exit 2 before configuration or network access;
+other failures exit 1. Diagnostics remain on stderr and exclude message bodies
+and untrusted server text. A confirmed post followed by a local receipt-output
+or cleanup failure retains its confirmed message Id and is not reported as an
+unknown remote result.
+
 ## Task attachments
 
 Attachment commands use the existing project selection and server configuration:
@@ -951,10 +1071,11 @@ records binary transport and output ownership.
 ## Worker configuration and startup
 
 `daynight worker run` is a foreground reconciler. It claims eligible ready tasks
-across configured repositories, runs native agents through the claim's Herdr or
+assigned to its authenticated account across configured repositories, runs native agents through the claim's Herdr or
 Web backend, and cleans resources when the original claim leaves its complete
 inventory. The agent owns delivery, acceptance, evidence and final claim-bound
-completion.
+completion. Worker follows the CLI platform support policy: Linux, Windows and
+Apple Silicon (ARM64) macOS.
 
 The running worker reports an account-owned runtime snapshot immediately after
 identity and authentication are ready, every 30 seconds, and after complete task
@@ -1200,13 +1321,19 @@ 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,
+notification submission state, failure count, next retry time, stage and error.
+These records preserve responsibility; they do not prove that resources stopped
+or disappeared.
+
 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,
@@ -1218,7 +1345,8 @@ 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=6`; upgrading
+version 5 preserves its Project and task rows. 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
@@ -1229,7 +1357,13 @@ its migration sequence; the [SQLite migration requirements](../../docs/spec/cli-
 define atomicity, ownership blockers and supported starting formats.
 
 Each reconciliation obtains the complete own-claim inventory for configured and
-saved Projects. Still-owned local active tasks are queued for fresh target
+saved Projects using only workerId. Assignment does not filter this inventory:
+existing executions retain their recovery and cleanup authority. New candidates
+combine assignedTo=me, ready, automatic permission and actual platform before
+server pagination; the claim transaction rechecks the assignee against the
+authenticated user ID. Unassigned tasks and tasks assigned to another account
+are ineligible for automatic acquisition. Explicit manual resume retains its
+original execution-owner/admin rules. Still-owned local active tasks are queued for fresh target
 observation and recovery before global Git discovery, so a sibling checkout's
 filesystem error does not block an already-reserved task. New pending startup
 and new claims still require complete global resource discovery. Failed or
@@ -1270,8 +1404,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,
@@ -1279,10 +1415,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
@@ -1314,10 +1453,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:
 
@@ -1362,15 +1503,23 @@ 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.
+temporary files, services and processes outside the worktree. It waits until
+cleanup completes or the original ten-minute deadline expires, then 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. 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.
 
 After the cleanup message is successfully submitted, a subsequent patrol that
 observes idle completes the cleanup turn and proceeds to stop the agent and
@@ -1381,20 +1530,35 @@ 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.
+Terminal cleanup is recorded before notification or resource removal. The
+original deadline and notification submission state survive failure, cancellation
+and restart; a cleanup notification with an unknown submission result is not
+replayed. Restart restores the
+same claim's responsibility and observes actual remaining resources without
+starting business execution. Previously confirmed cleanup 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.
+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, original deadline and
+notification state, 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 retain their
 notification and removal sequence. Pending stop confirmations must settle before the private
 Herdr instance stops; stop errors remain visible, and uncertain stopping retains
@@ -1462,12 +1626,31 @@ 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.
 
+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 and deadline,
 then proves native stop before deleting the task worktree. 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
+notification state in the independent schedule.
 
 The worker starts `daynight controller codex|claude|copilot --launch-id <uuid>`
 from a private immutable launch ticket. Its cwd, profile, claim, generation,
@@ -1561,11 +1744,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:
@@ -1594,6 +1788,10 @@ daynight worker resume <task-id> --claim-id <released-claim-id> --if-version <ve
 ```
 
 Resume requires the previous released claim, ready task and original owner/admin.
+Remote Worker control reads the caller's current `/projects/{id}/access`
+projection for administrator authority and verifies its project/principal binding;
+member profile reads retain their separate directory responsibility. Grant
+versions preserve the full positive int64 range.
 It preserves the explicit manual permission/platform exception, obtains fresh
 claim/worktree identities with current settings, and registers pending with a
 NULL native session ID. Start run to execute it.

package/dist/api/client.d.ts

@@ -1,5 +1,6 @@
+import type { ThreadReadQuery, PostThreadMessageInput, ThreadMessage, ThreadPage } from "./types.js";
 import type { Operation } from "./operation.js";
-import type { AttachmentConsumer, CreateProjectInput, CreateTaskInput, DeleteTaskInput, ErrorDetails, Project, 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, 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";
 type Context = {
     readonly operation: string;
     readonly projectId?: string;
@@ -17,19 +18,24 @@ export declare class ApiError extends Error {
     readonly details?: ErrorDetails;
     readonly outcomeUnconfirmed: boolean;
     readonly confirmedRefusal: boolean;
+    readonly confirmedMessageId?: string;
     constructor(context: Context, phase: ApiPhase, options: {
         readonly cause: unknown;
         readonly status?: number;
         readonly serverError?: ServerError;
         readonly outcomeUnconfirmed?: boolean;
         readonly confirmedRefusal?: boolean;
+        readonly confirmedMessageId?: string;
     });
 }
 export type ApiClient = {
+    readTaskThread(projectId: string, taskId: string, query: ThreadReadQuery): Promise<ThreadPage>;
+    postTaskThreadMessage(projectId: string, taskId: string, input: PostThreadMessageInput): Promise<ThreadMessage>;
     getCurrentUser(): Promise<User>;
     reportWorker(workerId: string, input: WorkerReport): Promise<WorkerReportReceipt>;
     createProject(input: CreateProjectInput): Promise<Project>;
     getProject(projectId: string): Promise<Project>;
+    getProjectAccess(projectId: string): Promise<ProjectAccess>;
     listProjects(): Promise<readonly Project[]>;
     listProjectMembers(projectId: string): Promise<readonly ProjectMember[]>;
     createTask(projectId: string, input: CreateTaskInput): Promise<Task>;