If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/vektra/mockery shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 6d ago
• 13 active contributors
• BSD-3-Clause licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 77% of recent commits

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live vektra/mockery repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/vektra/mockery.

What it runs against: a local clone of vektra/mockery — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in vektra/mockery | Confirms the artifact applies here, not a fork | | 2 | License is still BSD-3-Clause | Catches relicense before you depend on it | | 3 | Default branch v3 exists | Catches branch renames | | 4 | Last commit ≤ 36 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of vektra/mockery. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/vektra/mockery.git
#   cd mockery
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of vektra/mockery and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "vektra/mockery(\\.git)?\\b" \\
  && ok "origin remote is vektra/mockery" \\
  || miss "origin remote is not vektra/mockery (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(BSD-3-Clause)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"BSD-3-Clause\"" package.json 2>/dev/null) \\
  && ok "license is BSD-3-Clause" \\
  || miss "license drift — was BSD-3-Clause at generation time"

# 3. Default branch
git rev-parse --verify v3 >/dev/null 2>&1 \\
  && ok "default branch v3 exists" \\
  || miss "default branch v3 no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 36 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~6d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/vektra/mockery"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

mockery is a CLI tool that auto-generates mock implementations of Go interfaces using the stretchr/testify/mock package. It parses Go source code via AST analysis, reads interface definitions, and generates boilerplate-free mock types with Call tracking, Argument matching, and Return value assertion capabilities — eliminating hundreds of lines of manual mock code per project. Monorepo structure: cmd/ contains CLI entry points, config/ holds configuration parsing (config.go, config_test.go), and main generation logic lives in unnamed packages inferred from Go's package structure. Workflows in .github/workflows/ orchestrate testing (testing.yml, reusable-testing.yml), release (tag-and-release.yml), and docs (documentation.yml). Template rendering uses templ (17K LOC) for code generation templates.

Go backend developers and infrastructure engineers writing unit tests who need to mock external dependencies (databases, APIs, cloud services) without writing repetitive testify mock boilerplate. Contributors include maintainers maintaining the vektra/mockery project and companies like Google, Uber, and Datadog using mockery in their codebases.

Production-ready and actively maintained. The project has significant adoption (visible in docs/assets/images/logos/ with major companies: Amazon, Google, Uber, Hashicorp, Kubernetes, MongoDB, Datadog). v3 is the current major version with structured config at config/config.go, comprehensive CI/CD in .github/workflows/, and active documentation at docs/. Clear sign of maturity: separate testing workflow (reusable-testing.yml) and release automation (tag-and-release.yml).

Standard open source risks apply.

Active development on v3 with CI/CD automation. Recent work visible in: (1) Taskfile.yml orchestrating build tasks (go mod download, tests), (2) .goreleaser.yml configured for cross-platform releases, (3) documentation.yml workflow publishing docs via mkdocs-material. No specific open PRs visible in file list, but reusable-testing.yml suggests refactored test infrastructure.

git clone https://github.com/vektra/mockery.git
cd mockery
go mod download -x
task test

The Taskfile.yml lists available tasks (test, build, etc.). For local mockery binary: go build ./cmd/mockery or use task runner.

Daily commands:

task test           # Run all tests with coverage
task build          # Compile binary (inferred from Taskfile)
go run ./cmd/mockery -version  # Run CLI directly

For live development: modify source in cmd/ or config/, then go run ./cmd/mockery with flags. Config validation tests in config/config_test.go verify YAML parsing.

• config/config.go: Central configuration struct for all mockery behavior (paths, naming, output format, testify/mock options); changes here ripple through entire CLI
• .github/workflows/testing.yml: Primary CI pipeline running go test across the codebase; understanding this reveals project's test structure and coverage expectations
• .goreleaser.yml: Release automation config; defines how vektra/mockery binaries are packaged for distribution across OS/arch combinations
• Taskfile.yml: Build task orchestration; all developer workflows (test, build, docs) are defined here instead of Makefile
• docs/configuration.md: User-facing documentation for config.go YAML options; must stay in sync with config struct changes
• cmd/: CLI entry points and main mockery command implementation; starting point for understanding how users invoke the tool

Start here for common changes: (1) New config options: edit config/config.go and config/config_test.go (YAML struct + validation). (2) Mock generation logic: find main generator in unnamed packages (likely in subdirectories not visible in file list — check cmd/ subdirs). (3) Template output: modify .templ files (17K LOC) for mock code structure. (4) CLI behavior: edit cmd/ entry points. (5) Docs: add .md files to docs/ folder (docs/configuration.md, docs/generate-directive.md, etc.) and rebuild via documentation.yml workflow.

(1) AST parsing is sensitive to Go version and syntax; test with go mod download to ensure dependencies match target Go version. (2) Template generation via templ (.templ files) requires templ compiler installed during development — not in standard go toolchain. (3) Config YAML parsing in config/config.go must be validated before generation runs; see config_test.go for schema assumptions. (4) Mock output is testify-specific; projects using different mock libraries (gomock, mockgen) require integration work. (5) Dockerfile included suggests containerized builds are expected path for reproducibility.

• Abstract Syntax Tree (AST) Parsing — mockery parses Go source files as ASTs to extract interface definitions without executing code; fundamental to understanding how mockery identifies interfaces to mock
• Reflection & Interface{} Design — Generated mocks use reflection to capture arbitrary method arguments and return values; Go's interface{} empty interface is how testify/mock stores Call data generically
• Call Assertion & Mock Tracking — mockery generates mocks that record method calls (via testify/mock.Mock) and allow test assertions like On(), AssertCalled(), AssertNotCalled(); core pattern of generated code
• Code Generation via Templates — mockery uses templ (.templ files) to generate Go mock source code dynamically; understanding template rendering is essential for modifying output format
• Go Module Versioning & Compatibility — mockery must parse interfaces from dependencies in go.mod; version constraints affect which source files mockery can read and mock successfully
• CLI Flag Parsing & Configuration — config/config.go defines how YAML configs and CLI flags are merged; understanding config precedence is crucial for troubleshooting user invocations
• GitHub Actions Workflow Automation — mockery uses reusable workflows (.github/workflows/reusable-testing.yml) for CI; understanding matrix testing and artifact caching accelerates onboarding to contribution flow

• golang/mock — Alternative mock generator using code generation instead of testify/mock; users compare mockery vs GoMock based on interface coverage
• stretchr/testify — Dependency providing the mock package that mockery generates code for; understanding testify/mock assertions is essential to using mockery output
• matryer/moq — Lightweight mock generator that competes with mockery; some projects use moq for simpler mocks while mockery for complex stubs
• go-task/task — Build task runner used by mockery itself (Taskfile.yml); helps contributors understand the project's development workflow
• goreleaser/goreleaser — Tool configured in .goreleaser.yml for automating binary releases; mockery's distribution mechanism for cross-platform builds

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add E2E tests for remote template functionality with validation

The repo has an e2e/test_remote_templates directory but no corresponding test script or validation. Given that remote templates are a documented feature (docs/template/index.md exists), there should be comprehensive E2E tests. This would catch regressions when remote template fetching or schema validation changes, and is referenced in e2e/test_template_data_schema_validation but not fully implemented.

• [ ] Create e2e/test_remote_templates_validation.sh that tests remote template fetching from various sources
• [ ] Add test cases for malformed remote URLs, timeout scenarios, and invalid template schemas
• [ ] Integrate the new script into e2e/run_all.sh and ensure it runs in CI (reference .github/workflows/testing.yml)
• [ ] Document the test scenarios in docs/dev-notes.md

Add comprehensive unit tests for config/config.go with edge cases

The config package is critical to mockery's functionality, but config/config_test.go likely has gaps in coverage for edge cases. The repo uses .mockery.yml, .mockery_matryer.yml, and .mockery_testify.yml configurations which suggests complex config parsing logic that needs thorough testing for precedence, override behavior, and validation.

• [ ] Audit config/config_test.go against config/config.go to identify untested branches (conditional logic, error paths)
• [ ] Add tests for config file precedence (which file wins when multiple exist)
• [ ] Add tests for invalid YAML parsing and type mismatches in config values
• [ ] Add tests for environment variable override behavior if supported
• [ ] Run codecov locally to verify improved coverage before submitting

Add integration test for the generate-directive feature with multiple scenarios

The docs/generate-directive.md file documents this feature but there's no dedicated test file verifying it works correctly across different scenarios. Given this is a code generation tool, having explicit tests that validate the directive parsing and mock generation behavior would prevent regressions.

• [ ] Create e2e/test_generate_directive/run.sh that tests //go:generate directives in sample Go files
• [ ] Test scenarios: valid directives, malformed directives, mixed with other go:generate directives
• [ ] Verify generated mocks match expected output for each scenario
• [ ] Add this test to e2e/run_all.sh and GitHub Actions workflow (reference .github/workflows/testing.yml)
• [ ] Document expected behavior in docs/dev-notes.md

• Add integration test cases to config/config_test.go for edge cases in YAML parsing (e.g., deeply nested map structures, empty string values, array bounds) — currently tests may lack coverage for realistic user configs
• Expand docs/faq.md and docs/troubleshooting.md (inferred missing) with common mockery failures: 'interface not found', 'unexported methods skipped', 'circular dependency in mock generation' — these are typical user pain points not visible in current docs
• Add shell script or docs example in docs/ showing mockery invocation in GitHub Actions CI (visible in .github/workflows/ but user docs missing) — many users need 'how to auto-generate mocks in CI' guide

The vektra/mockery codebase demonstrates reasonable security practices overall. It is a tool for generating mocks and does not handle sensitive data or external untrusted input at scale. Primary concerns are: (1) dependency management - mkdocs-material pinned without regular CVE audits, (2) Docker image hardening - base image specificity and unnecessary packages, (3) runtime isolation - missing non-root user configuration. No evidence of hardcoded credentials, SQL injection risks, or XSS vulnerabilities. The codebase itself appears to focus on code generation for testing purposes, limiting injection attack vectors. Recommendations focus on dependency management practices and container image optimization.

• Medium · Outdated mkdocs-material Dependency — Dependencies/Package file (mkdocs-material==9.7.1). The mkdocs-material package is pinned to version 9.7.1 in the dependencies file. Without a specified upper bound or regular dependency updates, this could lead to using a version with known vulnerabilities if not actively maintained. Fix: Regularly audit dependencies for known CVEs. Consider using a dependency checker in CI/CD pipeline (e.g., GitHub Dependabot, Snyk). Update to the latest stable version after testing.
• Medium · Permissive Alpine Linux Base Image — Dockerfile. The Dockerfile uses golang:1.26-alpine as the base image without specifying a specific patch version. This could allow automatic updates to newer patch versions with potential security implications. Additionally, the image installs gcc and musl-dev which increase the attack surface. Fix: Specify an exact Alpine version (e.g., golang:1.26-alpine3.19). Consider using a minimal base image for the final stage. Evaluate if gcc and musl-dev are truly required for runtime.
• Low · Git SSH Access in Container — Dockerfile (RUN apk --update add --no-cache gcc musl-dev git openssh). The Dockerfile installs openssh package which may not be necessary for the application's runtime. This increases container attack surface unnecessarily. Fix: Evaluate if openssh is required at runtime. If only needed during build, move to a separate build stage. Consider using multi-stage builds to reduce final image size and attack surface.
• Low · Unset GOCACHE Without User Context — Dockerfile (ENV GOCACHE /tmp/.cache). While the Dockerfile sets GOCACHE to /tmp/.cache to handle user permission issues, this directory may have overly permissive access in some configurations. Fix: Ensure proper directory permissions are set. Consider running the container with a non-root user (USER directive) and appropriate umask settings.
• Low · Missing Security Headers in Documentation — docs/ configuration (mkdocs setup). The documentation site (using mkdocs-material) may not have explicit security headers configured for HTTPS, CSP, or other security policies. Fix: Configure security headers in the web server serving the documentation site. Add Content-Security-Policy, X-Frame-Options, X-Content-Type-Options headers.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.