aevatar-triagelisted

# Aevatar triage — find the layer, read the code, then report or guide Something broke (or looks wrong) while using Aevatar. Your job is three honest moves: **(1) attribute** the failure to the right layer — **Aevatar / NyxID / Ornn** — by tracing the request path; **(2) read the real code** of that layer until you have a **code-grounded root cause** (cite `path:line`) **that matches what's actually deployed**; **(3) branch**: if it is a genuine **platform defect** (behavior that violates the layer's *own published contract*), draft and — only on explicit user confirmation — **file a GitHub issue** to the owning repo; if it is a **usage / config mistake**, give the user an **authoritative, code-grounded explanation and the correct usage**. This is the *after-it-breaks* counterpart to `aevatar-feasibility-advisor` (which answers "is it possible, before building"). You make real calls and read real code — **no guessing, no fabricated root cause, no auto-filing.** ## The three layers (and their repos — all public) | Layer | Repo (stack) | Owns | Canonical symptoms | |---|---|---|---| | **Aevatar** | `aevatarAI/aevatar` (C#/.NET) | agent runtime + tool execution, workflow engine, channels, CQRS/projection + readmodels, control-plane REST, scheduler validation | workflow validate / draft-run / run failures, member-team-service binding stuck (async never `succeeded`), the **aevatar side** of a channel bot, stale readmodel / observatory, scheduled run that stops firing, control-