@rosthq/cli 0.7.81 → 0.7.82

package/dist/generated/command-manifest.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"command-manifest.d.ts","sourceRoot":"","sources":["../../src/generated/command-manifest.ts"],"names":[],"mappings":"AAIA,OAAO,KAAK,EAAE,oBAAoB,EAAE,MAAM,gCAAgC,CAAC;AAE3E,eAAO,MAAM,gBAAgB,EAAE,SAAS,oBAAoB,EAmQ3D,CAAC"}
+{"version":3,"file":"command-manifest.d.ts","sourceRoot":"","sources":["../../src/generated/command-manifest.ts"],"names":[],"mappings":"AAIA,OAAO,KAAK,EAAE,oBAAoB,EAAE,MAAM,gCAAgC,CAAC;AAE3E,eAAO,MAAM,gBAAgB,EAAE,SAAS,oBAAoB,EAqQ3D,CAAC"}

package/dist/index.js

@@ -45985,6 +45985,9 @@ var taskListOutputSchema = external_exports.object({
 var taskAcceptInputSchema = external_exports.object({
   id: uuidSchema19
 }).strict();
+var taskConfirmProposalInputSchema = external_exports.object({
+  id: uuidSchema19
+}).strict();
 var taskMutationOutputSchema = external_exports.object({
   task: external_exports.object({
     id: uuidSchema19,
@@ -47384,7 +47387,7 @@ The dry run is a real sandbox rehearsal, not a stamp. It executes a mock-provide
     order: 80,
     title: "Sync rhythm playbook",
     summary: "How Signal, Friction, Cascade, and Sync Briefs turn weekly meetings into decision time.",
-    version: "2026-07-04.1",
+    version: "2026-07-15.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["operating_rhythm"],
@@ -47718,7 +47721,7 @@ External connectors are being rolled out provider by provider, conservatively (r
     order: 48,
     title: "CLI and MCP installation guide",
     summary: "Install the public CLI, register remote token-backed MCP clients, and find the full command and tool catalog.",
-    version: "2026-07-15.1",
+    version: "2026-07-15.2",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "staffing"],
@@ -48174,7 +48177,7 @@ The signed-in app exposes the same Skill command surface at **Skills**, linked f
 
 | Command | Command ids | Purpose | Scope | Safe example |
 |---|---|---|---|---|
-| \`{{cli}} task list|accept|decline|complete|create\` | \`task.list\`, \`task.accept\`, \`task.decline\`, \`task.complete\`, \`task.create\` | Operate a seat's task queue. | Seat | \`{{cli}} task list --json\` |
+| \`{{cli}} task list|accept|decline|complete|create\` | \`task.list\`, \`task.accept\`, \`task.decline\`, \`task.complete\`, \`task.create\`, \`task.confirm_proposal\`, \`task.decline_proposal\` | Operate a seat's task queue and target-side proposal decisions. | Seat / tenant | \`{{cli}} task list --json\`; \`{{cli}} command task.confirm_proposal --json '{"id":"<task-id>"}'\` |
 | \`{{cli}} status record\` | \`status.record\` | Record measurable readings and goal status as a status event. | Seat | \`{{cli}} status record --measurable-id <id> --value 42\` |
 | \`{{cli}} signal list|get|confirm|correct\` | \`signal.list\`, \`signal.get\`, \`signal.confirm_reading\`, \`signal.correct_reading\` | Read and confirm Signal measurables. | Seat | \`{{cli}} signal list --json\` |
 | \`{{cli}} goal list|create|update|status|reparent|drop\` | \`goal.list\`, \`goal.create\`, \`goal.update\`, \`goal.set_status\`, \`goal.reparent\`, \`goal.drop\` | Manage Cascade goals. Scope varies by verb: \`status\` is seat-scoped, \`list\`/\`create\` need a tenant token, and \`update\`/\`reparent\`/\`drop\` require tenant-admin. | Seat to tenant-admin | \`{{cli}} goal list --json\` |
@@ -48418,7 +48421,7 @@ Several rows here are seat-operating commands (\`task.create\`, the \`signal.*\`
 | \`rost_update_friction_issue_status\` | \`friction.update_status\` | Move a non-terminal issue between open and diagnosing. | Seat or tenant-admin | Call with \`issue_id\` and \`status\`. |
 | \`rost_resolve_friction_issue\` | \`friction.resolve\` | Resolve an issue with a root cause and remediation task. | Tenant | Human decision; expect confirmation. |
 | \`rost_link_task_to_friction_issue\` | \`friction.link_task\` | Attach an existing task as an issue's action task. | Seat or tenant-admin | Call with \`issue_id\` and \`task_id\`. |
-| \`rost_create_task\` | \`task.create\` | Create a task (a commitment between seats). | Seat or tenant-admin | \`none\` \u2014 created directly; the owning seat accepts or declines. |
+| \`rost_create_task\` | \`task.create\` | Create a task (a commitment between seats). | Seat or tenant-admin | \`none\` \u2014 human-created tasks go live directly; ordinary agent-created tasks become draft proposals; bounded Trusted proposals become offered or, for same-Steward live agent seats, in progress. |
 | \`rost_update_task\` | \`task.update\` | Reschedule, reassign, or edit a non-terminal task. | Owner (tenant-admin) | Pass \`task_id\` plus at least one of \`due_on\`/\`owner_seat_id\`/\`title\`/\`description\`; terminal tasks reject. |
 | \`rost_compile_sync_brief\` | \`sync.brief.compile\` | Compile the weekly Sync Brief (idempotent per period). | Tenant | Call with \`{}\`. |
 | \`rost_get_sync_brief\` | \`sync.brief.get\` | Read the latest or a specific Sync Brief and agenda. | Seat or tenant-admin | Call with \`{}\` or \`{"sync_brief_id":"<id>"}\`. |
@@ -49222,7 +49225,7 @@ Agents may record readings when the Charter allows it. Agent-reported readings s
     order: 62,
     title: "Friction guide",
     summary: "How to capture issues with evidence, rank them, and resolve them without losing ownership.",
-    version: "2026-07-04.1",
+    version: "2026-07-15.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["operating_rhythm"],
@@ -49237,6 +49240,8 @@ Agents may record readings when the Charter allows it. Agent-reported readings s
       "friction.resolve",
       "friction.link_task",
       "task.create",
+      "task.confirm_proposal",
+      "task.decline_proposal",
       "task.list",
       "task.accept",
       "task.decline",
@@ -49282,7 +49287,7 @@ The Friction page opens with one computed line \u2014 how many issues are open,
 Friction, tasks, and escalations are the issue-to-action loop. A seat files, a task carries the work, and an escalation routes a decision a seat cannot make alone.
 
 - File and triage: \`{{cli}} friction file ...\` / \`friction.file_issue\` (seat) / \`rost_file_issue\`; list with \`{{cli}} friction list --status open --json\` / \`friction.list\` / \`rost_list_friction_issues\`; move between open and diagnosing with \`friction.update_status\` / \`rost_update_friction_issue_status\`.
-- Carry the work as a task: \`task.create\` / \`rost_create_task\` (a commitment between seats). \`task.create\` is \`none\` (no confirmation gate), so an agent can file one directly; an agent's task lands as a **draft** proposal (\`origin: agent_proposal\`) for a human to review and hand off \u2014 not a live offer in the owning seat's accept/decline queue. A seat runs its queue with \`{{cli}} task list|accept|decline|complete\` (\`task.list\`, \`task.accept\`, \`task.decline\`, \`task.complete\`). Link a task to an issue with \`friction.link_task\` / \`rost_link_task_to_friction_issue\`.
+- Carry the work as a task: \`task.create\` / \`rost_create_task\` (a commitment between seats). \`task.create\` is \`none\` (no confirmation gate), so an agent can file one directly; an ordinary agent task lands as a **draft** proposal (\`origin: agent_proposal\`) for a target-side human to confirm or decline through \`task.confirm_proposal\` / \`task.decline_proposal\` in \`/approvals\` or the CLI \u2014 not MCP, and not a live offer in the owning seat's accept/decline queue. A bounded Trusted task-create grant may skip that draft card: it creates an **offered** handoff by default, and only creates **in_progress** when both proposing and target seats are live agent seats resolving to the same current accountable human Steward. A seat runs its live queue with \`{{cli}} task list|accept|decline|complete\` (\`task.list\`, \`task.accept\`, \`task.decline\`, \`task.complete\`). Link a task to an issue with \`friction.link_task\` / \`rost_link_task_to_friction_issue\`.
 - Route a decision: \`escalation.raise\` (seat) / \`rost_escalate\` sends approval-scope or must-escalate work to the Steward queue. Reads are \`escalation.list\` / \`escalation.get\`. See the steward queue guide for resolution.
 
 In the app, the Tasks surface exposes the same queue operations for a seat's visible work. Offered handoffs show Accept and Decline actions; Decline opens a reason field and records the reason through \`task.decline\`. Edit opens a separate task form for title, owner, due date, and description changes on non-terminal tasks. These controls are standard focusable disclosures so keyboard and pointer users can operate the queue without dropping to CLI.
@@ -49293,7 +49298,7 @@ In the app, the Tasks surface exposes the same queue operations for a seat's vis
 
 ## When to stop for confirmation
 
-\`friction.resolve\` is \`human_required\`; resolving an issue is a human decision. \`friction.link_task\`, \`task.create\`, \`task.accept\`, \`task.decline\`, and \`task.complete\` are \`none\`, so a seat files issues, creates commitments, and runs its own task queue directly. \`friction.update_status\`, \`escalation.raise\`, \`friction.file_issue\`, and \`friction.list\` are also not gated. An agent files Friction, proposes the task, and escalates; a human resolves.
+\`friction.resolve\` is \`human_required\`; resolving an issue is a human decision. \`friction.link_task\`, \`task.create\`, \`task.accept\`, \`task.decline\`, \`task.confirm_proposal\`, \`task.decline_proposal\`, and \`task.complete\` are \`none\`, so they do not mint pending confirmations. The proposal decision commands still require a human actor with target-side authority and are app/CLI-only, not MCP-exposed; they are not agent-callable approval shortcuts. \`friction.update_status\`, \`escalation.raise\`, \`friction.file_issue\`, and \`friction.list\` are also not gated. An agent files Friction, proposes the task, and escalates; a human resolves or decides the proposed commitment.
 
 ## Resolution rule
 
@@ -49374,11 +49379,11 @@ Keep agent scope tight at first. Approve more autonomy only after evidence. Use
     order: 71,
     title: "Confirmations and human gates guide",
     summary: "How {{brand}} routes authority-changing work through human confirmation, and why agents never approve their own requests.",
-    version: "2026-07-14.2",
+    version: "2026-07-15.2",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["graph_design", "charter_design", "staffing", "operating_rhythm"],
-    relatedCommandIds: ["confirmation.approve", "confirmation.list", "confirmation.reject", "confirmation.remint", "charter.approve", "agent.go_live", "credential.ingress", "mcp_token.create", "staffing.assign_user", "goal.reparent", "friction.resolve"],
+    relatedCommandIds: ["confirmation.approve", "confirmation.list", "confirmation.reject", "confirmation.remint", "charter.approve", "agent.go_live", "credential.ingress", "mcp_token.create", "staffing.assign_user", "goal.reparent", "friction.resolve", "task.confirm_proposal", "task.decline_proposal"],
     legal: { publicRisk: "low", notes: ["{{brand}}-native human-gate guidance."] },
     sources: [
       {
@@ -49424,11 +49429,11 @@ A held tool call actuates the same way regardless of which command backs it \u20
 
 ## The approvals queue
 
-The \`/approvals\` page is one place a human clears every pending decision across the company. It unions still-pending confirmations with open steward escalations into a single queue, each item shown with its risk, the source seat, and redacted arguments \u2014 secret material is never displayed. You see only items for seats you have authority over: an owner sees all of them; a member sees confirmations for the seats they occupy and escalations routed to their steward chain, and nothing else. Approve and reject route through the same \`confirmation.approve\` / \`confirmation.reject\` and escalation decision commands the CLI and per-seat surfaces use, so the audit trail and the agents-recommend-humans-decide rule are identical wherever you act. The queue also unions pending Forge software-credential requests (owner-scoped, read-only, deep-linking to \`/forge\`) \u2014 it surfaces the ask and links to the vault-backed fulfillment flow, never collecting the secret itself. A confirmation that fails on approval shows the actual execution error inline as a \`failed\` card instead of a dead generic banner, and its Retry re-runs \`confirmation.approve\` against current state; re-minting the same request supersedes the older card instead of leaving a duplicate behind.
+The \`/approvals\` page is one place a human clears every pending decision across the company. It unions still-pending confirmations, open steward escalations, and agent-proposed draft tasks into a single queue, each item shown with its risk or proposal type, the source or proposing seat, and redacted arguments \u2014 secret material is never displayed. You see only items for seats you have authority over: an owner sees all of them; a member sees confirmations for the seats they occupy, escalations routed to their steward chain, and task proposals where they occupy or steward the target seat. Confirming a task proposal runs \`task.confirm_proposal\` and moves the draft to Offered; declining runs \`task.decline_proposal\` and records a human reason. Neither action accepts the task, schedules a run, or executes agent work. Approve and reject route through the same \`confirmation.approve\` / \`confirmation.reject\` and escalation decision commands the CLI and per-seat surfaces use, so the audit trail and the agents-recommend-humans-decide rule are identical wherever you act. The queue also unions pending Forge software-credential requests (owner-scoped, read-only, deep-linking to \`/forge\`) \u2014 it surfaces the ask and links to the vault-backed fulfillment flow, never collecting the secret itself. A confirmation that fails on approval shows the actual execution error inline as a \`failed\` card instead of a dead generic banner, and its Retry re-runs \`confirmation.approve\` against current state; re-minting the same request supersedes the older card instead of leaving a duplicate behind.
 
 ## The rule for agents
 
-An agent never approves or rejects its own request. \`decisions.decided_by\` is always a human. The steward decision commands (\`escalation.resolve\`, \`escalation.reject\`) are not even exposed over MCP. When an agent hits a gate, it prepares the evidence and the recommended action, returns the approve link, and waits for a human.
+An agent never approves or rejects its own request. \`decisions.decided_by\` is always a human. The steward decision commands (\`escalation.resolve\`, \`escalation.reject\`) and proposal decision commands (\`task.confirm_proposal\`, \`task.decline_proposal\`) are not exposed over MCP. When an agent hits a gate, it prepares the evidence and the recommended action, returns the approve link, and waits for a human. Draft task proposals follow the same rule: the agent can propose the commitment, but a target-side human confirms or declines it unless a bounded Trusted grant applies.
 
 ## When to stop
 
@@ -49548,7 +49553,7 @@ Do not claim that a live charge happened unless Stripe test/live evidence proves
     order: 72,
     title: "Settings guide",
     summary: "How to use Settings as the control plane for company access, channels, providers, tokens, and operating defaults.",
-    version: "2026-07-14.1",
+    version: "2026-07-15.1",
     public: true,
     audiences: ["human", "cli", "mcp", "in_app_agent"],
     stages: ["company_setup", "staffing"],
@@ -49648,7 +49653,7 @@ The company autonomy ceiling is a single tenant-wide dial that caps how much ANY
 The CLI confirmation mode is a separate tenant-wide dial. It does not change what an agent may do (that is the company autonomy ceiling above); it changes whether the {{cli}} CLI tool itself may stand in for a human at an already-gated confirmation.
 
 - \`careful\` is the strict default for every company, including internal ones. The server refuses the CLI's silent auto-replay of a pending confirmation \u2014 a human must review it before it is approved.
-- \`trusted_operator\` is a deliberate tenant_admin opt-in (an ADR-0018 \xA76 standing authorization) that lets the CLI silently auto-approve a non-\`dangerous\` confirmation. A \`dangerous\`-risk confirmation always requires interactive human review, in either mode.
+- \`trusted_operator\` is a deliberate tenant_admin opt-in (an ADR-0018 \xA76 standing authorization) that lets the CLI silently auto-approve only confirmations whose command is explicitly classified Trusted-eligible. Always-human, not-applicable, missing, unknown, and \`dangerous\`-risk confirmations still require interactive human review in either mode.
 - Read it with \`settings.confirmation_policy.get\` (CLI: \`{{cli}} settings confirmation-mode get\`). Set it with \`settings.confirmation_policy.update\` (CLI: \`{{cli}} settings confirmation-mode set --mode trusted_operator\`). Owner-only and human-gated.
 - Stored at \`tenants.settings.confirmation_policy\`; enforced server-side in \`confirmation.approve\`, so a stale or modified local CLI cannot bypass it.
 
@@ -51971,8 +51976,10 @@ var COMMAND_MANIFEST = [
   { "id": "system.health", "namespace": "system", "action": "health", "title": "System health", "description": "Return a scoped health snapshot for agent runs, errors, Signals, Cascade setup, work loop, integrations, runners, notifications, and Sync Brief readiness.", "requiredScope": "tenant", "confirmation": "none", "exposeOverMcp": true, "fields": [{ "name": "seat_id", "flag": "seat-id", "type": "string", "required": false }], "hasComplexInput": false, "help": "Read a scoped system health snapshot across agent runs, errors, Signals, Cascade setup, work loop, integrations, runners, notifications, and Sync Brief readiness." },
   { "id": "task.accept", "namespace": "task", "action": "accept", "title": "Accept task", "description": "Accept an offered handoff task owned by the acting seat.", "requiredScope": "seat", "confirmation": "none", "exposeOverMcp": true, "fields": [{ "name": "id", "flag": "id", "type": "string", "required": true }], "hasComplexInput": false, "help": "Accept an offered task only when the seat can deliver it within its Charter." },
   { "id": "task.complete", "namespace": "task", "action": "complete", "title": "Complete task", "description": "Complete an accepted handoff task and emit a handoff event back to the requesting seat.", "requiredScope": "seat", "confirmation": "none", "exposeOverMcp": true, "fields": [{ "name": "id", "flag": "id", "type": "string", "required": true }, { "name": "summary", "flag": "summary", "type": "string", "required": true }], "hasComplexInput": true, "help": "Complete an accepted task with a summary so the requesting seat receives the handoff." },
-  { "id": "task.create", "namespace": "task", "action": "create", "title": "Create task", "description": "Create a task (a commitment between seats). Agent-created tasks land in draft for human confirmation; human-created tasks are offered (handoff) or in progress.", "requiredScope": "tenant", "confirmation": "none", "exposeOverMcp": true, "fields": [{ "name": "owner_seat_id", "flag": "owner-seat-id", "type": "string", "required": true }, { "name": "from_seat_id", "flag": "from-seat-id", "type": "string", "required": false }, { "name": "title", "flag": "title", "type": "string", "required": true }, { "name": "description", "flag": "description", "type": "string", "required": true }, { "name": "goal_id", "flag": "goal-id", "type": "string", "required": false }, { "name": "acceptance_criteria", "flag": "acceptance-criteria", "type": "array", "required": false, "itemType": "string" }, { "name": "due_on", "flag": "due-on", "type": "string", "required": false }], "hasComplexInput": false, "help": "Create a task as a commitment between seats; agent proposals land in draft for human confirmation.", "example": { "owner_seat_id": "0190dddd-dddd-7ddd-8ddd-dddddddddddd", "from_seat_id": "0190eeee-eeee-7eee-8eee-eeeeeeeeeeee", "title": "Reconcile the March vendor statements", "description": "Match every March vendor statement line to a recorded invoice and flag discrepancies.", "goal_id": "0190ffff-ffff-7fff-8fff-ffffffffffff", "acceptance_criteria": ["All March statements reconciled", "Discrepancies filed as Friction issues"], "due_on": "2026-04-15" } },
+  { "id": "task.confirm_proposal", "namespace": "task", "action": "confirm_proposal", "title": "Confirm proposed task", "description": "Confirm an agent-proposed draft task when the current human has target-side authority.", "requiredScope": "tenant", "confirmation": "none", "exposeOverMcp": false, "fields": [{ "name": "id", "flag": "id", "type": "string", "required": true }], "hasComplexInput": false, "help": "Confirm an agent-proposed draft task when the current human has authority for the target seat." },
+  { "id": "task.create", "namespace": "task", "action": "create", "title": "Create task", "description": "Create a task (a commitment between seats). Agent-created tasks land in draft for human confirmation; human-created tasks are offered (handoff) or in progress.", "requiredScope": "tenant", "confirmation": "none", "exposeOverMcp": true, "fields": [{ "name": "owner_seat_id", "flag": "owner-seat-id", "type": "string", "required": true }, { "name": "from_seat_id", "flag": "from-seat-id", "type": "string", "required": false }, { "name": "title", "flag": "title", "type": "string", "required": true }, { "name": "description", "flag": "description", "type": "string", "required": true }, { "name": "goal_id", "flag": "goal-id", "type": "string", "required": false }, { "name": "acceptance_criteria", "flag": "acceptance-criteria", "type": "array", "required": false, "itemType": "string" }, { "name": "due_on", "flag": "due-on", "type": "string", "required": false }], "hasComplexInput": false, "help": "Create a task as a commitment between seats; ordinary agent proposals land in draft for target-side human confirmation, while bounded Trusted proposals may become offered or in progress.", "example": { "owner_seat_id": "0190dddd-dddd-7ddd-8ddd-dddddddddddd", "from_seat_id": "0190eeee-eeee-7eee-8eee-eeeeeeeeeeee", "title": "Reconcile the March vendor statements", "description": "Match every March vendor statement line to a recorded invoice and flag discrepancies.", "goal_id": "0190ffff-ffff-7fff-8fff-ffffffffffff", "acceptance_criteria": ["All March statements reconciled", "Discrepancies filed as Friction issues"], "due_on": "2026-04-15" } },
   { "id": "task.decline", "namespace": "task", "action": "decline", "title": "Decline task", "description": "Decline an offered handoff task owned by the acting seat with a reason.", "requiredScope": "seat", "confirmation": "none", "exposeOverMcp": true, "fields": [{ "name": "id", "flag": "id", "type": "string", "required": true }, { "name": "reason", "flag": "reason", "type": "string", "required": true }], "hasComplexInput": false, "help": "Decline an offered task with a clear reason when it is out of scope for the seat." },
+  { "id": "task.decline_proposal", "namespace": "task", "action": "decline_proposal", "title": "Decline proposed task", "description": "Decline an agent-proposed draft task with a target-side human reason.", "requiredScope": "tenant", "confirmation": "none", "exposeOverMcp": false, "fields": [{ "name": "id", "flag": "id", "type": "string", "required": true }, { "name": "reason", "flag": "reason", "type": "string", "required": true }], "hasComplexInput": false, "help": "Decline an agent-proposed draft task with a target-side human reason." },
   { "id": "task.import", "namespace": "task", "action": "import", "title": "Import Tasks from a ninety To-Dos export", "description": "Bulk-import a ninety To-Dos export into Tasks. Owners are seat names resolved to seats; each to-do becomes a seat-owned task with provenance origin_kind:manual. Idempotent \u2014 re-importing the same export is a no-op, and an existing non-terminal task with the same seat + title is skipped.", "requiredScope": "tenant_admin", "confirmation": "none", "exposeOverMcp": true, "fields": [{ "name": "dry_run", "flag": "dry-run", "type": "boolean", "required": false }], "hasComplexInput": true, "help": "Import a ninety To-Dos export into Tasks (origin_kind:manual); owners resolve to seats, idempotent by file + seat/title." },
   { "id": "task.list", "namespace": "task", "action": "list", "title": "List seat tasks", "description": "List open handoff tasks owned by the acting seat.", "requiredScope": "seat", "confirmation": "none", "exposeOverMcp": true, "fields": [], "hasComplexInput": false, "help": "List the seat's open handoff tasks before accepting, declining, or completing work." },
   { "id": "task.update", "namespace": "task", "action": "update", "title": "Update task", "description": "Reschedule (due date), reassign (owner seat), or edit a non-terminal task's title, description, or acceptance criteria. Terminal tasks cannot be edited \u2014 a correction is a new task.", "requiredScope": "tenant_admin", "confirmation": "none", "exposeOverMcp": true, "fields": [{ "name": "task_id", "flag": "task-id", "type": "string", "required": true }, { "name": "owner_seat_id", "flag": "owner-seat-id", "type": "string", "required": false }, { "name": "due_on", "flag": "due-on", "type": "string", "required": false }, { "name": "title", "flag": "title", "type": "string", "required": false }, { "name": "description", "flag": "description", "type": "string", "required": false }, { "name": "acceptance_criteria", "flag": "acceptance-criteria", "type": "array", "required": false, "itemType": "string" }], "hasComplexInput": false, "help": "Reschedule, reassign, or edit a non-terminal task; terminal tasks are immutable (a correction is a new task)." },