| name | zigrix-task-status |
| version | 0.3.0 |
| description | Inspect authoritative Zigrix Task metadata, pending recovery, requests, assignments, and result decisions. |
| metadata | {"openclaw":{"requires":{"bins":["zigrix"]},"cliHelp":"zigrix task status --help"}} |
zigrix task status
Use this skill only for read-only inspection.
zigrix task list --json
zigrix task status TASK-20260713-001 --json
zigrix task events TASK-20260713-001 --json
Source of truth
tasks/<taskId>.meta.json is the authoritative Task snapshot. Status output exposes that metadata plus resolved paths such as specPath, metaPath, and projectDir. Use the returned paths; do not construct paths from symbolic config keys.
tasks.jsonl is a typed audit diagnostic and index.json is a rebuildable projection. Neither overrides or reconstructs metadata. A stale index may be rebuilt, but a status mismatch must be resolved from the metadata snapshot.
What to inspect
Check all of these before deciding what can happen next:
- top-level
status, schema version, and current revision
- exact stored orchestrator
agentId, sessionKey, sessionId, and bindingEpoch
pendingCommit, command id, payload digest, expected revision, recovery stage, and any recoverable_in_doubt receipt
- unresolved
BLOCK_REQUEST or STALE_DETECTED records and orchestrator_action_required
- each unit's current immutable assignment epoch and
PREPARED, ACTIVE, EXPIRED, or SUPERSEDED state
- worker task/agent/session/sessionId/run/unit/assignment-epoch binding
- current submission id, ordinal, digest, artifact identity, and orchestrator approval/rejection
A submitted result is not an approved result. Only an immutable APPROVE_UNIT_RESULT decision by the exact stored orchestrator makes that unit eligible for FINALIZE. Rejection preserves evidence history; a valid resubmission receives the next ordinal on the same active assignment epoch.
Pending and request diagnostics
If pendingCommit exists, do not infer that the snapshot is unchanged. Once snapshot rename was attempted, the result is in-doubt and recovery must retry the same deterministic command id with the identical payload. Do not issue a different command, edit metadata/audit/evidence/index, or reset state around it.
BLOCK_REQUEST and STALE_DETECTED are request-only records. They do not change status or revision. Only the stored orchestrator can acknowledge/reject the block request and commit a top-level transition. If it is unavailable, leave the unresolved request visible for operator diagnosis.
This skill does not grant permission to call START, BLOCK, RESUME, FINALIZE, REPORT, assignment mutation, or result-decision commands.