# Judgement > Hub-owned checklist for judging task-lifecycle gate quality and intervening on process defects. Read by the hourly judgement process and by any operator inspecting why the hub stopped a task, held an agent, or redeployed the fleet. - Skill: `jordanhubbard/judgement` (Agent Skill) - Install (CLI): `npx skillmds@latest add jordanhubbard/judgement` - Raw SKILL.md: https://api.skillmd.com/api/skills/jordanhubbard/judgement/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: jordanhubbard (https://skillmd.com/u/jordanhubbard) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/jordanhubbard/judgement --- # Judgement This skill is the hub's process-quality checklist. The hourly judgement process (`src/mac/judgement.py`) reads it and acts. It does not run in a sandbox. It has the current mac checkout and the same privileged verbs an operator has: stop a task, hold an agent, stop the fleet, redeploy an image, and start the appropriate entities back up. It judges the **quality** of the gates on the claim/fix/deliver cycle, the **number** of those gates, and the **states** tasks have wound up in. It does not re-review the content of a task. Hub-verify (deterministic contract tests) is the only default review gate. There is no LLM semantic reviewer. ## Checklist Each item is a finding kind the process emits. If the evidence matches, it intervenes. ### 1. `review_rejection_loop` Work already passed its tests and was pushed, then a reviewer rejected it, then the next attempt did the same thing. Observed 2026-08-23 on `task_3b44296d` (docs audit): four passing, pushed attempts; a fleet reviewer and the hub-verify reviewer rejected each one; 17 million tokens; no publication. Same shape on `task_ae2fc223` (route-ladder ADR): two hub-verify rejections after a passing push, then a contract-gate failure that blocked two other P0 release tasks. **Intervene:** stop the looping task. If the assignee is still burning tokens on the same evidence, hold that agent. Do not assign another semantic reviewer — that gate is gone. ### 2. `high_token_without_publication` A task has spent a quarter-million tokens or more and produced no publication. The ledger already raises `high_token_work_without_publication`. **Intervene:** stop the task. If the owner is still in-flight on it, hold the owner until an operator or a later judgement cycle releases them. ### 3. `failed_dependency_deadlock` A task is blocked on a dependency that is `failed` (or otherwise terminal and unsuccessful) under `all_success`. The child can never dispatch. Two P0 release blockers (`task_529caba5`, `task_6086c172`) sat in this state behind `task_ae2fc223`. **Intervene:** stop the blocked child so it stops looking live. Do not reopen the failed parent automatically — that is how a broken ADR gets re-implemented. Record the pair and leave the parent for an operator or a code-level process fix. ### 4. `stuck_reviewing` A task has been in `needs_review` or `reviewing` longer than the stuck threshold (default two hours) without a publication. Twenty-two tasks were in `reviewing` on 2026-08-23, including a P0 titled "Diagnose why the hub self-tick fails to drain the 66 REVIEWING tasks". **Intervene:** a pending virtual review in the hub's active verification guard belongs to its bounded external runner; task age alone must not stop it. For genuinely stale reviews without an active runner, stop the task. If a non-virtual agent holds the review, hold that agent. ### 5. `semantic_reviewer_still_assigned` A pending review is assigned to a fleet agent (not the virtual hub-reviewer). That is the gate this skill exists to keep gone. **Intervene:** stop the task under review. If many such assignments are live, stop the fleet, redeploy the current mac image, and start only the hub-reviewer plus the workers that were not part of the defect. ### 6. `excessive_reviewing_population` Queue size alone does not establish a process failure. Fresh reviews and active hub verification are normal work, including large review queues. **Intervene:** address stuck reviews individually first. If the same stalled reviews persist into the next judgement cycle and meet both configured thresholds (default: at least twenty tasks and a tenth of non-terminal tasks), hold worker dispatch and pause registered projects so new work stops feeding the queue. Recheck after targeted recovery in that cycle; do not hold the fleet if recovery cleared the queue. This backpressure preserves healthy in-flight tasks and reviews. It does not cancel work or trigger an automatic redeploy. Reserve one intervention from the cycle budget for that hold so repeated individual recovery failures cannot exhaust the budget before backpressure. ### 7. `too_many_gates` A single attempt collected three or more distinct review or contract rejections after already presenting passing executor evidence. The claim/fix/deliver cycle has grown a gate that does not earn its keep. **Intervene:** stop the task. Treat the extra gate as a process defect — the same class of defect that made the semantic reviewer worth removing. ### 8. `orphaned_pull_request` An open PR identifies its owning task as already `completed` or `cancelled`, or the same task id already has a merged PR. Observed 2026-08-23: 56 open PRs against `main`, zero review decisions. Several were copies of work that later landed under another number (`#585` after `#577`, `#587` after `#580`, `#582`/`#612` after `#614`). **Intervene:** close the orphaned PR. Do not open a replacement. The branch is archaeology, not a second review queue. Ownership comes from a consistent task identity in the title, branch or `Task:` / `Task ID:` field. Investigation, dependency and other body references are supporting context. They do not authorize PR closure or task completion. Conflicting ownership declarations and ambiguous short ids authorize neither. Merged-task reconciliation additionally requires the full durable owning id. ### 9. `duplicate_pull_request` Two or more open PRs identify the same owning task. The deploy-generation retirement record was opened five times (`#485`, `#609`–`#613`). Task stop/restart was opened three times (`#514`, `#641`, `#642`). **Intervene:** close every older duplicate. Keep the newest. Do not ask another agent to re-implement the same change. ### 10. `unlanded_pull_request` A PR is still open, the task is `failed` / `blocked` / `waiting`, and nothing with that task id has merged. This is the good work that got stuck in semantic review and never landed — `#643` (docs audit), `#634` (route-ladder ADR), and dozens more. **Intervene:** stop a blocked task; retain failed or waiting work for recovery. An open PR is normal during `needs_review` or `reviewing` and does not justify stopping it. The age, repeated rejection and semantic reviewer checks above handle actual review stalls. Do **not** close the PR. The branch is the salvage. Hub-verify is the only gate left; a later operator or judgement cycle can land it. Closing it is how the work disappears a second time. ## Authority The process may: - `mac task stop` any live task - `mac agent hold` / `mac agent resume` any non-virtual agent - pause every registered project (fleet stop) and activate them again - invoke the fleet redeploy command against the current mac checkout - start stopped tasks and resume agents it held, after a redeploy It may not invent a new review gate. It may not restore the semantic reviewer. Every action is audited as `judgement.*` observability with the finding kind that licensed it. ## Bounds A runaway judge is worse than a silent one. - At most `MAC_JUDGEMENT_MAX_ACTIONS_PER_CYCLE` interventions per hour (default 20). - At most `MAC_JUDGEMENT_MAX_REDEPLOYS_PER_DAY` redeploys (default 2). - Holds it places are tagged `judgement:` so a later cycle can resume only what it held, not an operator hold. - Redeploy is injected in tests and fail-closed if the command is missing.