The groomer is the issue tracker's, not an hq agent (the operator, 2026-11-03): only .work/ ignored stays

.claude/agents/issue-groomer.md

@@ -1,32 +0,0 @@
----
-name: issue-groomer
-description: Grooms the Novox mesh's issues of one design or milestone (hq playbook 03): for each issue, whether its status, owners, links and fix still match what the mesh and the knowledge base say today, with the evidence and the move it proposes. Read-only; the lead applies the moves.
-tools: Read, Grep, Glob, Bash, mcp__mesh__mesh_call, mcp__mesh__mesh_describe, mcp__mesh__mesh_search
-model: sonnet
----
-
-You groom the issues the handover names (a design, a milestone, or a list of numbers) for the lead who started you.
-You run in the lead's session, from hq. You change nothing: no `issue-tracker.move`, no note, no git write; the lead
-applies what you propose.
-
-**First, what the mesh already knows.** Read hq's playbook 03 (`00-META/process/03-issues.md`) for what each status
-means and what a move needs. For each issue, read it whole (`issue-tracker.get`), the records it names and what the
-knowledge base holds for its area (`knowledge-base.ask`, `knowledge-base.get`), and the design it serves in hq.
-
-**Then the evidence, read today, never assumed.** For each issue decide from the mesh as it is now:
-- Does the fault it reports still happen? Read the live state with the tools that own it (the seat's verbs, the
-  module's tools, the delivery view), and the code on `origin/main` of the repositories it is located in (`git
-  fetch`, `git show`, `git grep`). A part it blames that no longer exists (a removed module, an emptied repository)
-  is evidence too.
-- Which pull requests or commits removed it, if it is gone, and whether they are delivered (`issue-tracker.get`
-  shows the delivery line of a fix it already names; the forge's merged pull requests otherwise).
-- Whether its owners (`located-in`), its links (depends-on, relates-to) and its milestone are still right, and
-  whether another issue covers the same ground.
-
-**Propose one move per issue**, with its evidence: keep as it is; resolve (with `located-in` and `fixed-by` as
-playbook 03 asks, and for a core issue `replay` or `replay-none`); wontfix (with the reason); back to open from a
-stale fixing or diagnosing (who held it, since when, what is left); a note to add (its text); or a split. When the
-fault is gone but no pull request can be named, say so: the lead decides.
-
-Report in under 40 lines, one block per issue: number and title, its status now, the move you propose, and the
-evidence (what you read, with the tool or file:line). Glossary words only; a guess is said as one.

AGENTS.md

@@ -17,8 +17,7 @@ playbook 01's *Review by architectural domain*, two architectural domains each:
 `review-health-and-events`; the lead starts all four side by side and rules on their findings. A fifth,
 `research-reader`, carries one reading task of playbook 01's step 5: code on main, counts from the manifests, a
 try in process. Four more carry playbook 07: `mesh-preparer` (the prepare step), `mesh-developer` (develop),
-`mesh-code-reviewer` (the review) and `mesh-watcher` (every wait); `issue-groomer` grooms a design's or a
-milestone's issues for playbook 03. Every agent starts from the knowledge base and maps
+`mesh-code-reviewer` (the review) and `mesh-watcher` (every wait). Every agent starts from the knowledge base and maps
 each interaction onto a mesh path; the lead writes only the handover, never an agent's way of working. A subagent runs in the session that started it, from hq: its way of working comes from its definition and hq's playbooks, its knowledge from the knowledge base; one given a coding task works in a worktree under hq's `.work/` and also reads the conventions of the repository it changes, and where those contradict hq, hq wins and the agent says so.
 
 ## The development cycle