# Triage Out-of-Scope

What this skill is NOT. Knowing the boundary prevents triage from
metastasizing into a catch-all decision-making surface.

## Out-of-scope concerns and where they belong

### Locking decisions
Triage moves a task between states; it does NOT lock design or
implementation decisions. Decisions live in
`.aperant/context/notes/{task-id}.md` (via `/apt:discuss`) or in
`docs/adr/NNNN-slug.md` (via `apt-tools adr write` if the Nygard
3-gate filter passes).

### Feature design
Triage does NOT design features. If a `needs-triage` task contains a
vision or vague intent ("we should have analytics"), the right move is
`ready-for-human` with a pointer to `/apt:discuss --brainstorm` — not
to invent the feature shape inside the triage agent's context.

### Multi-task prioritization
Triage assigns a state to one task at a time. It does NOT decide which
ready-for-agent task should be worked on first. That's the roadmap
surface (`apt-tools roadmap`) or the active-task surface (`apt-tools
active`).

### Implementation planning
Triage does NOT emit an `implementation_plan.json`. That's `/apt:plan`'s
job, invoked AFTER a task is in `ready-for-agent` state.

### Verification / review
Triage does NOT verify implementation quality. That's `/apt:verify` and
`/apt:review` AFTER the agent ships.

### Stakeholder communication
Triage's `needs-info` state surfaces a clarifying question to the
reporter via the configured backend's mention surface — it does NOT
own the conversation thread itself. Long back-and-forths belong in the
backend (GitHub Issues comments, app-inbox replies), not in the triage
record's `extra` field.

### Coordination layer
Triage does NOT atomically claim a task for a specific agent worker,
heartbeat, or coordinate cross-machine. That's the coordination layer
(team-task roundtable verdicts R1-R16). Triage and coordination share
data (the task ID, the lifecycle phase) but their surfaces are disjoint.

### Security incident response
Triage does NOT escalate security incidents through their own
pipeline. If a `needs-triage` task has a security-sensitive flag (set
in `extra.security_sensitive` once v2 ships), it routes immediately to
`ready-for-human` and stops — the human owns the incident response.

## What triage IS

A 5-state machine + bug/enhancement category + extensible metadata
record. That's it. Every concern above either belongs to a sibling
skill or stays in the backend that hosts the conversation.

## The metadata extension contract

Triage's v1 schema includes `extra: Record<string, unknown>` for v2 OSS
contributor primitives. The v1 schema MUST be forward-compatible: v1
readers MUST ignore unrecognized fields under `extra`, and v2 readers
MUST gracefully handle missing fields under `extra` (treat as
undefined; don't crash). This is the non-breaking schema extension
mechanism — it's what lets us ship v1 today and add v2 fields later
without a migration.
