aeondave/external-feedback-triage

External Feedback Triage

Treat every external suggestion as a hypothesis until it is checked against the current scope and evidence.

When to activate

• A scanner, reviewer, model, blog, PoC README, advisory, or issue says what to fix or exploit.
• Feedback conflicts with local evidence.
• A requested change feels broad, risky, noisy, or unrelated to the original task.

Triage loop

1. Restate feedback in neutral technical terms.
2. Check applicability: version, platform, configuration, code path, permissions, and scope.
3. Classify severity: critical correctness, security risk, maintainability, style, or preference.
4. Verify evidence: apply evidence-before-claims before accepting.
5. Choose action: apply, adapt, defer, reject, or ask for clarification.
6. Patch minimally when acting; do not bundle unrelated cleanup.
7. Report disagreement with evidence when rejecting or narrowing feedback.

Pushback is useful

Do not agree just because feedback sounds authoritative. Push back when:

• it assumes an unsupported threat model
• it requires out-of-scope access or noisy actions
• it solves a different version/configuration
• it adds abstraction without repeated need
• it weakens tests, evidence, or operator safety

Output contract

For non-trivial feedback, return:

• feedback summary
• applicability result
• action taken or rejected
• remaining risk or follow-up

Evidence output shape: pair with evidence-before-claims.

Resources

Load on demand:

• references/review-feedback.md — decision table for reviews, scanner output, advisories, PoCs, and model suggestions.

Pair with:

• evidence-before-claims — evidence quality and claim wording when verifying accepted feedback.
• verification-before-completion — freshness gate before claiming the applied fix is complete.