Mentor review і remediation backlog

Mentor review як feedback loop

Mentor review має перетворити спостереження на рішення, а не на загальний список побажань. Для кожного finding потрібні evidence anchor, severity, owner, next action, acceptance signal і статус. Це дозволяє відрізнити Must fix від Should fix та Later без маскування невизначеності.

Remediation backlog не є доказом, що mentor review відбувся. У навчальному пакеті findings і пріоритети заповнюються як documented example, а фактичні оцінки та ownership залишаються Unknown, якщо вони не підтверджені записом review.

Від finding до remediation item

1. Зафіксувати observed finding і посилання на evidence, не замінюючи його гіпотезою.
2. Визначити severity та decision impact: Must fix, Should fix або Later.
3. Призначити owner лише після фактичного рішення; інакше записати owner як Unknown.
4. Сформулювати одну next action і acceptance signal.
5. Оновити статус після перевірки або залишити Needs verification із причиною.

Remediation backlog

# REMEDIATION_BACKLOG.md
Source review: <mentor/reviewer note or Unknown>

| Priority | Finding | Evidence | Owner | Acceptance signal | Status |
| --- | --- | --- | --- | --- | --- |
| Must fix | <blocking gap> | <anchor or Unknown> | <role or Unknown> | <observable check> | Needs verification |
| Should fix | <quality improvement> | <anchor or Unknown> | <role or Unknown> | <observable check> | Planned documented example |
| Later | <deferred improvement> | <reason> | <role or Unknown> | <future signal> | Deferred |

Boundary: this backlog does not prove mentor approval or completed remediation.