Engineer sub-agents: specialized implementers the Runner/Reviewer delegate to (both variants)

[danievanzyl]

Context

Named during the permissions grill on #52 / ADR-0004. A glossary stub for Engineer was added to CONTEXT.md; this issue tracks building it.

What

An Engineer is a specialized implementer sub-agent a Runner (or Reviewer) delegates a focused slice of work to — e.g. a language- or domain-expert that owns a risky edit. Spawned in-process via the pane agent's own Task tool, so it gets its own Trajectory nested under the Run.

This is the reason the herdr permission policy keeps Task available (denies web + MCP, not Task) — the seam is preserved; the capability isn't built yet.

Constraint — wire into BOTH variants together (Efficiency parity)

The in-process agent defs (agents/afk-task-runner.md, agents/code-reviewer.md) grant tools: with no Task, so the in-process afk-issue Runner currently can't nest. If pane agents (herdr) start nesting Engineers but the in-process ones can't, the two variants' Trajectories diverge and the Efficiency dimension comparison breaks (same reason --model is pinned per role).

So: grant Task in the agent defs and teach both prompts to delegate — never the pane path alone.

Scope to design later

• Which Engineer specializations, and how the Runner decides to delegate.
• Whether Engineers are their own agent defs (with pinned model/tools) discovered via Task.
• How a pane agent's --disallowedTools interacts with (or constrains) a Task-spawned Engineer's own frontmatter tool set.
• Eval: Engineer Trajectories nest under the Run — confirm the Rubric/Scorecard accounts for nested work.

Not part of the locked #52 pipeline; forward-referenced in skills/afk-issue-herdr/SKILL.md → "Sub-agent nesting".