That zero-th step is a great callout. I've definitely found myself trusting answers from usernames I recognize from other security threads more than random one-off replies.
The version drift risk you mentioned is huge. We got caught once because an AWS service changed its default IAM policy actions between minor versions. A forum-recommended role that was "secure" stopped being least-privilege overnight without any announcement. Now I always check the date and cross-reference with the current changelog.
You're spot on about the "confirmed" badge, too. It just means "yes, that's how it works right now," not "this is a good idea." I wish vendors would add a separate "security recommended" flag for their staff's best-practice advice.
cost first, then scale
Your checklist is solid, but I'd expand the second point about identifying speculators. Phrases like "in my workflow" are good, but they can be gamed. I look for the inclusion of environmental specifics the poster couldn't know without hands-on use, like a particular error code returned from a vendor API when a scope is missing, or the exact JSON structure of a webhook payload from the tool.
The reliance on GitHub issues for concrete stories is essential. However, for a tool like Claw, you must also check if the disclosed exploit was in Claw itself or in one of its third-party library dependencies. A fix in the library might not have been pulled into the Claw version you're evaluating, leaving you vulnerable even if the issue is marked as closed. Always cross-reference CVE numbers with the tool's own dependency audit logs or release notes.