Skip to main content
Glama

aiworkhub_task_recover_blocked_rework

Recover a blocked task for rework with manager feedback, optional validation changes, or an audited resolution of a scope rejection.

Instructions

Recover one exact blocked task through the canonical transaction.

scope_rejection_resolved is the manager's explicit, audited clean-root resolution of a scope_rejected card; it requires feedback_reason. A feedback_reason over 8000 UTF-8 bytes is refused with feedback_reason_too_large:<bytes>><cap>; it is never truncated.

When the core result's stdout parses to a card dict the reply is the shared _lifecycle_receipt projection (aiworkhub.recover_blocked_rework_receipt.v1, include_card="none"): task_id/status/worker_status plus card_sha256/card_bytes from the canonical _card_identity (the same basis as aiworkhub_task_show), the card's runner/recovery_epoch/recovery_predecessor when present, a detail_request for aiworkhub_task_show, and every extra top-level key the core call attached -- never the whole recovered card (NF-2026-01566). command is never echoed: its argv carries feedback_reason (up to 8000 bytes). A not-ok or card-less result is returned unchanged minus the argv echo, so error text is never hidden.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "task_id": "<task_id>"
    },
    "name": "aiworkhub_task_recover_blocked_rework"
  }
}

Input Schema

NameRequiredDescriptionDefault
task_idYesId of the blocked card to recover.
feedback_reasonNoManager feedback for the rework, at most 8000 UTF-8 bytes (longer is refused, never truncated); required with scope_rejection_resolved. Default empty.
validation_amendmentNoValidation commands to amend the recovered card with, checked by the same rules as validation on aiworkhub_task_create, e.g. pytest -q tests/test_target.py; omit for no amendment.
validation_only_replayNoSet true to authorize a validation-only replay of the retained candidate; refused unless the retained predecessor has a request id and changed-path hashes. Default false.
allowed_writes_amendmentNoRepo-relative paths to add to the card's allowed_writes (add-only, reject_review's path rules), e.g. tests/test_target.py; refused with validation_only_replay; omit for no amendment.
scope_rejection_resolvedNoSet true to record the manager's audited clean-root resolution of a scope_rejected card; requires feedback_reason and is not combinable with validation_only_replay. Default false.
validation_amendment_modeNoHow validation_amendment changes the card's validation: append (default, add new deduplicated commands), replace (the amendment becomes the whole list) or remove (drop each listed command, which must exactly equal an existing one, else validation_amendment_remove_unknown, plus its role); the result must keep the work_kind role gate (e.g. bugfix needs reproduction and regression) and not be empty; anything else is refused with validation_amendment_mode_invalid.append
validation_roles_amendmentNoRoles for a replace, one per validation_amendment command in the same order (each a quality_evidence validation role such as reproduction, regression or generic); required when the card carries validation_roles and refused with validation_amendment_roles_invalid outside replace or when misaligned.
clean_root_if_predecessor_missingNoSet true to recover from a clean root when the hash-pinned predecessor workspace was removed; not combinable with validation_only_replay. Default false.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.12.85
    • addedInput schema / properties / validation_amendment_mode
      Added value: +{
      +  "default": "append",
      +  "description": "How validation_amendment changes the card's validation: append (default, add new deduplicated commands), replace (the amendment becomes the whole list) or remove (drop each listed command, which must exactly equal an existing one, else validation_amendment_remove_unknown, plus its role); the result must keep the work_kind role gate (e.g. bugfix needs reproduction and regression) and not be empty; anything else is refused with validation_amendment_mode_invalid.",
      +  "title": "Validation Amendment Mode",
      +  "type": "string"
      +}
    • addedInput schema / properties / validation_roles_amendment
      Added value: +{
      +  "anyOf": [
      +    {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Roles for a replace, one per validation_amendment command in the same order (each a quality_evidence validation role such as reproduction, regression or generic); required when the card carries validation_roles and refused with validation_amendment_roles_invalid outside replace or when misaligned.",
      +  "title": "Validation Roles Amendment"
      +}
  2. Changed7 schema fields changedv0.12.67
    • addedInput schema / properties / allowed_writes_amendment
      Added value: +{
      +  "anyOf": [
      +    {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Repo-relative paths to add to the card's allowed_writes (add-only, reject_review's path rules), e.g. tests/test_target.py; refused with validation_only_replay; omit for no amendment.",
      +  "title": "Allowed Writes Amendment"
      +}
    • addedInput schema / properties / clean_root_if_predecessor_missing / description
      Added value: +"Set true to recover from a clean root when the hash-pinned predecessor workspace was removed; not combinable with validation_only_replay. Default false."
    • addedInput schema / properties / feedback_reason / description
      Added value: +"Manager feedback for the rework, at most 8000 UTF-8 bytes (longer is refused, never truncated); required with scope_rejection_resolved. Default empty."
    • addedInput schema / properties / scope_rejection_resolved / description
      Added value: +"Set true to record the manager's audited clean-root resolution of a scope_rejected card; requires feedback_reason and is not combinable with validation_only_replay. Default false."
    • addedInput schema / properties / task_id / description
      Added value: +"Id of the blocked card to recover."
    • addedInput schema / properties / validation_amendment / description
      Added value: +"Validation commands to amend the recovered card with, checked by the same rules as validation on aiworkhub_task_create, e.g. pytest -q tests/test_target.py; omit for no amendment."
    • addedInput schema / properties / validation_only_replay / description
      Added value: +"Set true to authorize a validation-only replay of the retained candidate; refused unless the retained predecessor has a request id and changed-path hashes. Default false."
  3. First observedv0.1.0

TDQS

B3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only say readOnlyHint=false, destructiveHint=false, openWorldHint=false. The description goes well beyond that: it states the reply is the shared _lifecycle_receipt projection with task_id/status/worker_status plus card_sha256/card_bytes from the same identity basis as aiworkhub_task_show, that the whole recovered card is never returned, that argv is never echoed because it carries feedback_reason, and that not-ok or card-less results are returned unchanged so error text is not hidden. What is missing is precondition disclosure (required manager role/state, reversibility), which keeps it below 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in one sentence, which is good, but the remainder is a dense, backtick-heavy wall of internal identifiers (aiworkhub.recover_blocked_rework_receipt.v1, _lifecycle_receipt, _card_identity, NF-2026-01566) whose projection detail overlaps with the existing output schema. Nothing is grammatically wasteful, yet the reader must parse a lot of internals to extract the small number of actionable facts.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter mutation with an output schema, the description covers error semantics and the receipt envelope well. It leaves out the two things an agent most needs before invoking it: what preconditions/authorization make recovery legal, and how this differs from the recovery-adjacent siblings, so it is adequate but incomplete for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3, and the description largely restates schema facts (the 8000-byte cap, scope_rejection_resolved requiring feedback_reason). It does add a little beyond the schema: the literal refusal token feedback_reason_too_large:<bytes>><cap> and the guarantee that the value is never truncated and never echoed back.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Recover one exact blocked task through the canonical transaction" gives a verb and a resource, so the object is identifiable. But "canonical transaction" is internal jargon that never says operationally what recovery does (re-open the card? reset the worker? replay the candidate?), and no sibling such as aiworkhub_task_retry_terminal or aiworkhub_task_stale_recovery_recommend is named as the alternative, so an agent cannot rank this tool against its near neighbours.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use or when-not-to-use guidance at the tool level. The only routing logic given is intra-parameter (scope_rejection_resolved needs feedback_reason, validation_only_replay is incompatible with allowed_writes_amendment and clean_root_if_predecessor_missing), which constrains the call but does not tell an agent which blocked-state warrants this tool versus retry/reroute/reconcile siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools