rajudandigam/agent-inspect

Contribution lane: documentation / examples Difficulty: good first issue Ownership: community-owned Priority: p1 Milestone: Contributor Experience Labels: documentation, examples, good first issue, community-owned, status:ready, priority:p1 Baseline: [email protected] → 6.18.x Problem AgentInspect now has a substantial recipes catalog. The adoption problem is increasingly “which recipe should I use?” rather than “are there any examples?” Why it matters Partners need a scannable index by job, stack, maturity, and network behavior without reading every README. Proposed scope Improve examples/recipes/README.md (canonical recipe index) with a scannable matrix. Suggested columns: | Recipe | Developer job | Stack/integration | Key/API key required? | Network behavior | Support/maturity level | Difficulty | Main command/API | Example developer jobs: inspect a failed run understand tool retries validate observed outcomes CI trajectory regression build/verify Evidence LangGraph tr

Contribution lane: documentation Difficulty: good first issue Ownership: community-owned Priority: p1 Milestone: Contributor Experience Labels: documentation, area:mcp, community-owned, status:ready, good first issue, priority:p1 Baseline: [email protected] → 6.18.x Problem AgentInspect participates in several MCP-related workflows that are easy to confuse: MCP client tracing — an agent/client calls an MCP server; AgentInspect traces the client trajectory and client-side call. MCP server-side instrumentation — code inside an MCP server is instrumented; AgentInspect sees server internals. AgentInspect read-only MCP — a coding assistant reads existing local AgentInspect evidence through @agent-inspect/mcp-server; this is not automatic tracing of that assistant’s entire run. These are three different architectural roles. Why it matters Contributors and partners mis-route recipes, issues, and expectations when “MCP” is treated as one product surface. Proposed scope Add o

Contribution lane: documentation / community Difficulty: good first issue Ownership: community-owned Priority: p2 Milestone: Public Proof & Adoption Labels: documentation, good first issue, area:community, community-owned, status:ready, priority:p2 Baseline: [email protected] → 6.18.0 niche launch Problem There is no anonymized technical case-study template for partners to contribute public-safe proof narratives. Why it matters Public proof for 6.18 needs structured, anonymized write-ups — not raw traces. Proposed scope Add a markdown template for anonymized technical case studies. Required fields: version, stack, scenario, what broke, what Evidence/TraceContract caught, outcome. Explicit ban on secrets/customer identifiers/raw prompts if sensitive. Out of scope Fabricating case studies Marketing pages as product scope Uploading traces Suggested files docs/community/ template Link from OSS roadmap / contributing Acceptance criteria Template exists Privacy guidance expli

Contribution lane: documentation / examples Difficulty: good first issue Ownership: community-owned Priority: p2 Milestone: Public Proof & Adoption Labels: documentation, examples, good first issue, area:community, community-owned, status:ready, priority:p2 Baseline: [email protected] → 6.18.0 niche launch Problem Support responders lack a documented recipe for producing a share-safe reproduction Evidence bundle. Why it matters Faster, safer support loops without collecting secrets or production traces. Proposed scope Document a recipe to create a share-safe support reproduction bundle. Include redaction checklist and what not to attach. Link Evidence retention guidance (candidate #9). Out of scope Automatic upload to maintainers Collecting customer production data New runtime capture defaults Suggested files Support / contributing docs Optional example script Acceptance criteria Recipe is copyable Redaction checklist present Docs checks pass Validation commands pnpm do

Contribution lane: documentation Difficulty: good first issue Ownership: community-owned Priority: p2 Milestone: Public Proof & Adoption Labels: documentation, good first issue, area:community, community-owned, status:ready, priority:p2 Baseline: [email protected] → 6.18.0 niche launch Problem Contributors lack clear guidance on Evidence v2 retention, size limits, and when (not) to attach bundles to PRs. Why it matters Without guidance, PRs either omit needed proof or attach unsafe/huge artifacts. Proposed scope Document retention, size, and PR-attachment guidance for Evidence v2. Emphasize share-safe / redacted bundles and synthetic fixtures. Link CI artifact alternatives. Out of scope Changing default retention in runtime Hosted storage product Schema changes Suggested files Evidence / contributing docs Optional FAQ Acceptance criteria Guidance covers retention, size, PR attachment Privacy warnings explicit Docs checks pass Validation commands pnpm docs:check git diff