Files / Config

TRIAGE_RULES.md

# TRIAGE_RULES.md - Intake And Assignment Rules

Use these rules when turning raw inbox items into tracked Mission Control work.

## Classification

| Classification | Use When | Destination |
| --- | --- | --- |
| task | Clear action with a deliverable. | `TASKS.md` and active Mission Control if current. |
| bug | Broken behavior or regression. | Task with repro, owner, test status, and expected fix/report. |
| idea | Possible future improvement. | Keep in `INBOX.md` or backlog until scoped. |
| project note | Context about a project or boundary. | `PROJECTS.md`, memory, or relevant docs. |
| backoffice | Admin, reporting, cleanup, routine, or operational work. | `TASKS.md` or routine docs. |
| research | Needs investigation before execution. | Assign to Fakker or `Subagent:Research`. |
| support-debug | Diagnosis or incident-style work. | Runbook-backed task with evidence and next step. |
| decision-candidate | Durable preference, boundary, architecture, or operating rule. | `DECISIONS.md` after confirmation. |
| archive | Not actionable or no longer relevant. | Leave archived note or move to memory if useful. |

## Priority Rules

| Priority | Criteria |
| --- | --- |
| urgent | Blocking Khaled, production, access, data safety, or time-sensitive external action. |
| high | Important delivery work, active incident, or near-term deadline. |
| medium | Useful operational or project work without immediate pressure. |
| low | Cleanup, nice-to-have, or low-risk improvement. |
| someday | Valid idea, but not worth active tracking yet. |

## Splitting Rules

- Split items when they cross domains, repos, owners, or deliverables.
- Split backend, frontend, infra, QA, automation, integration, and backoffice work into separate tasks when ownership differs.
- Every split task needs an owner, status, blocker if any, and expected output.
- Keep dependencies explicit instead of hiding them in notes.

## Owner Assignment Rules

| Owner | Assign When |
| --- | --- |
| Fakker | Coordination, triage, docs, small scoped execution, or cross-domain orchestration. |
| Subagent:Backend | Backend implementation, APIs, data flows, services, or server-side bugs. |
| Subagent:Frontend | UI, UX, browser behavior, client-side bugs, or visual verification. |
| Subagent:Infra | Server, Docker, deployment, process, network, storage, or ops work. |
| Subagent:QA | Repro, tests, verification, regression checks, or acceptance reports. |
| Subagent:Research | Codebase exploration, options analysis, docs lookup, or unknown scope. |
| Subagent:Backoffice | Admin workflows, reporting, cleanup, and recurring operational tasks. |
| Automation:<name> | Scheduled, repeatable, low-judgment work with clear inputs/outputs. |
| Human:Khaled | Approval, credentials, external action, business decision, or protected boundary. |

Do not assign Paperclip work unless Khaled explicitly activates Paperclip.

## Review And Archive Rules

- Move work to `review` when an output exists but needs checking.
- Move work to `done` only when the expected output is delivered or accepted.
- Archive noisy details into memory or structured events; keep Mission Control concise.
- Record durable decisions in `DECISIONS.md`.
- Record repeatable procedures in `RUNBOOKS.md`.