Review Method

For each advisory, decide:

• close
• keep open
• keep open but narrow

Default to one advisory at a time when comments/closures are involved:

1. Review exactly one GHSA.
2. Print the GHSA URL first.
3. Summarize the decision and evidence for discussion.
4. Draft one maintainer-ready comment.
5. Copy only that one comment to the clipboard.
6. Stop and wait for Peter to post/discuss before moving to the next GHSA.

Do not batch multiple close comments unless Peter explicitly asks for a batch.

Check in this order:

1. Trust model
   • Is the prerequisite already inside trusted host/local/plugin/operator state?
   • Does SECURITY.md explicitly call this class out as out of scope or hardening-only?
2. Shipped behavior
   • Is the bug present in the latest shipped tag or npm release?
   • Was it fixed before release?
3. Exploit path
   • Does the report show a real boundary bypass, not just prompt injection, local same-user control, or helper-level semantics?
   • If data only moves between trusted workspace-memory files called out in SECURITY.md, do not treat "injection markers" alone as a security bug.
   • In that case, frame sanitization as optional hardening only if it preserves expected memory workflows.
4. Functional tradeoff
   • If a hardening change would reduce intended user functionality, call that out before proposing it.
   • Prefer fixes that preserve user workflows over deny-by-default regressions unless the boundary demands it.
5. Hardening follow-up
   • Even when the GHSA should close, ask whether a narrow hardening change would reduce footguns without changing the documented trust boundary.
   • Separate hardening from vulnerability status. Phrase it as "not required for GHSA closure, but worth considering".
   • Bring up hardening only if it is concrete, low-risk, and preserves intended maintainer/operator workflows.
   • If hardening would require a product/security model change, say that explicitly and do not imply it is a required fix for closure.

Response Format

When preparing a maintainer-ready close reply:

1. Print the GHSA URL first.
2. Then draft a detailed response the maintainer can post.
3. Include:
   • exact reason for close
   • exact code refs
   • exact shipped tag / release facts
   • fix provenance or canonical duplicate GHSA when applicable
   • optional hardening note only if worthwhile and functionality-preserving

Keep tone firm, specific, non-defensive.

Public Wording Hygiene

• Keep raw commit hashes, PR titles/numbers, and fix-mechanism summaries out of public advisory text. Use the patched release/version field only.
• Keep exact commit SHAs, PRs, and implementation notes in internal notes and verification files.

…

tag-duplicate-prs-issues

帮助团队检索重复的 PR 与问题单，并自动分组同步重复状态。