# Complaint-Analysis Report Template

Master layout for the report `/multi-agent:complaint-analysis` renders at Phase 4 and dispatches at Phase 5. Single-language body: every heading and prose block is written in `outputLanguage` (`tr` or `en`); the TR / EN heading pairs below show both forms, render ONE. Verdict tokens, Graylog excerpts, and field names in routing entries stay English (SKILL Locked 9). The deterministic gate over an emitted instance is `scripts/validate-complaint-doc.mjs` - keep this file and that validator in sync.

Numbering is fixed 1..8. Section 4 (routing) is rendered only when at least one `core` verdict exists; numbering still re-flows sequentially when it is omitted (same omission style as the analysis template).

## YAML front-matter (required keys)

```yaml
---
run_name: complaints-20260810
generated_at: <UTC ISO8601>
language: tr | en
complaint_count: <N>
repos: "<name>:<layer>, <name>:<layer>, ..."
verdict_counts: "client=<X> bff=<Y> core=<Z> insufficient=<W>"
graylog_degraded: true | false
---
```

`run_name`, `generated_at`, `language`, `complaint_count`, `graylog_degraded` are validator-required; `repos` and `verdict_counts` are part of the template contract but advisory to the gate.

## 1. Özet / Summary

2-4 sentences: how many complaints, where they came from (source types only - never file contents), the verdict distribution, and whether Graylog was degraded for any of them. Follow with the count table:

```
| Verdict | Count |
|---|---|
| client | X |
| bff | Y |
| core | Z |
| insufficient-evidence | W |
```

Then the coverage table - every selected repo appears, including the ones that came back clean, so "only the client layer needed a fix" is visible at a glance:

```
| Repo | Layer | Evidence hits | Verdicts attributed |
|---|---|---|---|
| <owner>/my-ios-app | ios | 3 | C-01 |
| <owner>/my-mobile-bff | mobile-bff | 0 | - (incelendi, temiz / checked, clean) |
```

## 2. Triage Tablosu / Triage Table

One row per complaint. Verdict tokens are the English enum: `client:ios`, `client:android`, `client:web`, `bff:mobile-bff`, `bff:web-bff`, `core`, `insufficient-evidence`. The validator requires every row in this section whose FIRST cell is a `C-NN` id to carry one of these tokens in a cell of its own (cell-exact; the Section 1 coverage table citing ids in its last column is exempt by scope).

```
| Id | Özet (redakte) | trx/conv | Verdict | Confidence | Routing |
|---|---|---|---|---|---|
| C-01 | <redacted excerpt <= 80 chars> | trx-9f3a | client:ios | high | - |
| C-02 | ... | conv-77aa | core | medium | payment-core |
```

`Routing` column: the suspected core service for `core` rows, `-` otherwise.

## 3. Şikayet Detayları / Complaint Details

One `### C-NN` subsection per complaint:

- **Şikayet / Complaint**: the redacted text (full, not the excerpt).
- **Graylog**: status line (`ok: N messages` / `degraded: <reason>` / `skipped: user choice`), then up to 3 evidence lines, English, shape `timestamp source level message-excerpt`. Redact any PII the log itself carries before quoting.
- **Repo kanıtı / Repo evidence**: `file:line - signal (matchKind)` rows from the correlation phase; `-` when none.
- **Elenen katmanlar / Ruled out**: one line listing the repos/layers that were grepped for this complaint's signals and returned nothing (e.g. `mobile-bff, web-bff: sinyal yok`). This is what justifies a single-layer verdict.
- **Verdict + gerekçe / rationale**: the verdict token, confidence, and 1-3 sentences citing the evidence above (SKILL Locked 10: client/bff needs 1 Graylog + 1 repo citation; core needs the Graylog line naming the upstream).
- **Geliştirme planı / Fix plan** (client/bff only, SKILL Locked 13; validator-required for every client/bff verdict): 2-5 numbered steps grounded in the existing architecture - each step references a cited `file:line` or component, reuse-first, tests included. Never rendered for core / insufficient-evidence.
- **Dev prompt** (client/bff only): one fenced English block ready to paste into `/multi-agent` or a Jira description - complaint summary, root cause, cited files, fix plan steps, acceptance check, and the `[C-NN]` id.

## 4. Core Yönlendirme Önerileri / Core Routing Recommendations

Rendered only when `core` verdicts exist. One `### C-NN` subsection per core verdict (the validator checks each core id appears here):

```
suspectedService: <Graylog source>
endpoint: <path or -> 
errorCode: <code or ->
evidenceExcerpt: <short redacted EN excerpt>
suggestedQueue: <prefs.projects[*].routing.coreTeamLabel or ->
confidence: high | medium | low
```

No fix analysis, no code speculation about the core service (SKILL Locked 5). This block is what gets forwarded to the core team.

## 5. Açık Sorular / Open Questions

One bullet per `insufficient-evidence` verdict (what is missing: id, reproducible log, repo signal) plus any ambiguity worth a human decision (e.g. client-vs-bff attribution at low confidence).

## 6. Metodoloji / Methodology

Fixed short block: source types ingested, redaction applied (`parse-complaints.sh`), Graylog query window/limit actually used, repos + layers grepped, and a **degraded services** list (`graylog: <reason>` when any fetch degraded - a degraded payload is never silently dropped).

## 7. Referanslar / References

Input source names only - file basename + row count, Jira issue keys, Confluence page titles/URLs. Never inline the input contents. Then the repo list with layers.

## 8. (Footer)

One line: `Generated by /multi-agent:complaint-analysis - report only, no branches or commits.` (localized).