Conciseness

The body is mostly efficient — it explains only Absurd-specific concepts (queue/task/run/step) and no general knowledge — but it could be tightened: the "Good copy-paste playbooks" section repeats commands verbatim from earlier sections (e.g. "uvx absurdctl list-tasks --queue=default --status=failed --limit=20" appears twice, and the "Reproduce" and "Fast path" blocks are near-identical), and "Extra reference" restates "dump-task --task-id is usually the best starting point" already established in the debugging workflow. This matches the 3 anchor (some unnecessary content that could be tightened) rather than the 4 anchor's minor trimmable instances.

Actionability

Guidance is fully executable and copy-paste ready with realistic flag combinations: "uvx absurdctl spawn-task my-task -q default -P count:=42 -P enabled:=true", "--params '{"foo":"bar","count":42}'", properly escaped search patterns ("rg -n \"registerTask\(|name:\\s*['\\\"]<task-name>['\\\"]\" .\"), and clearly parameterized placeholders (<task-id>, <run-id>). Specific examples cover the common cases, matching the 5 anchor.

Workflow Clarity

The debugging workflow is a clear numbered sequence ("1) Discover queues" through "4) Inspect one workflow... in detail") with state-conditioned decision flows and pre-action checkpoints ("prefer understanding the failure before retrying", "If a spawned task moves from pending to sleeping... a worker is already active", "If the environment is ambiguous, ask which database / queue is safe to operate on"). The destructive-operation cap does not bind because validation guidance is present; the gap keeping it below 5 is the absence of explicit post-action verification after retry-task/emit-event/cancel-task.

Progressive Disclosure

Authoring detail is appropriately split into a real, verified one-level-deep reference that is clearly signaled with its scope and when to read it ("For code changes, read [authoring and recovery](references/authoring-and-recovery.md) before editing. It covers replay, decomposed checkpoints, immutable events, external idempotency, fan-out, and process-recovery tests"), while the inline body remains the operational playbook. Navigation is easy via clear section headers, matching the 5 anchor.

Specificity

"Author, test, debug, and operate Absurd durable workflows" lists four concrete actions on a named domain, matching the anchor for several specific actions with minor gaps. It falls short of the 5 anchor because all four verbs act on the same broad object rather than a comprehensive list of fine-grained actions (cf. "extract text and tables... fill forms, merge documents, convert pages to images"), and is clearly above the 3 anchor's 1-2 actions.

Completeness

It explicitly answers "what" ("Author, test, debug, and operate Absurd durable workflows") and "when" ("Use when working with WorkflowContext, ... or uvx absurdctl") with concrete trigger phrases, exactly matching the anchor-5 example pattern. The explicit 'Use when...' clause is present, so the completeness cap does not apply.

Trigger Term Quality

The trigger list "WorkflowContext, tasks-orchestrator, parallelTasks, issue-lifecycle, Absurd queues, checkpoints, events, retries, idempotency, worker recovery, absurd-sdk, or uvx absurdctl" covers twelve natural terms a user of this system would actually say, spanning concept nouns (queues, events, retries, worker recovery) and specific identifiers (absurd-sdk, uvx absurdctl) that function like the anchor's file extensions. This is comprehensive coverage, clearly above the 4 anchor where natural terms are missing.

Distinctiveness Conflict Risk

"Absurd durable workflows", "WorkflowContext", "absurd-sdk", and "uvx absurdctl" establish a clear niche with distinct triggers, but generic terms in the trigger list ("checkpoints, events, retries, idempotency") could fire for other durable-workflow tooling, which is the minor overlap risk of the 4 anchor rather than the minimal conflict risk of the 5 anchor.