Part of #656 (v0.10.0). Pipeline stage 2 of 4: vet.
Goal
TrustMyBot must vet what it installs. Before proposing a 3rd-party resource to the user, assess trust and surface the assessment — the product's name is a promise.
What to design
- Trust signals: source reputation (official Anthropic / well-known org vs unknown), repo popularity (stars/forks/recency), maintenance, license.
- Security surface: does the resource ship hooks, MCP servers, or scripts that run code? Network access? Filesystem writes outside workspace? Flag high-surface resources explicitly.
- Verdict: per candidate, a trust tier (e.g. trusted / caution / untrusted) + one-line rationale + the specific risks the user should weigh.
- Honesty: never present an unvetted resource as safe; if signals are thin, say so.
Relationship to other stages
Consumes the ranked candidates from #657; produces vetted candidates (with risk notes) for the permission/install stage (#NEXT_INSTALL). The trust tier should shape how the install is proposed (e.g. caution-tier requires a more explicit confirmation).
Acceptance
Each proposed candidate carries a trust tier, a rationale, and an explicit list of what it can do on the local machine (hooks/MCP/network/fs). High-surface resources are never auto-approved.
Part of #656 (v0.10.0). Pipeline stage 2 of 4: vet.
Goal
TrustMyBot must vet what it installs. Before proposing a 3rd-party resource to the user, assess trust and surface the assessment — the product's name is a promise.
What to design
Relationship to other stages
Consumes the ranked candidates from #657; produces vetted candidates (with risk notes) for the permission/install stage (#NEXT_INSTALL). The trust tier should shape how the install is proposed (e.g. caution-tier requires a more explicit confirmation).
Acceptance
Each proposed candidate carries a trust tier, a rationale, and an explicit list of what it can do on the local machine (hooks/MCP/network/fs). High-surface resources are never auto-approved.