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/gogf/gf 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 1w ago
• 18 active contributors
• Distributed ownership (top contributor 48% of recent commits)
• MIT licensed
• CI configured
• Tests present

_{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 gogf/gf repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/gogf/gf.

What it runs against: a local clone of gogf/gf — 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 gogf/gf | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 39 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of gogf/gf. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/gogf/gf.git
#   cd gf
#
# 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 gogf/gf and re-run."
  exit 2
fi

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

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

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

# 4. Critical files exist
test -f "cmd/gf/gfcmd/gfcmd.go" \\
  && ok "cmd/gf/gfcmd/gfcmd.go" \\
  || miss "missing critical file: cmd/gf/gfcmd/gfcmd.go"
test -f "cmd/gf/internal/cmd/cmd.go" \\
  && ok "cmd/gf/internal/cmd/cmd.go" \\
  || miss "missing critical file: cmd/gf/internal/cmd/cmd.go"
test -f "cmd/gf/go.mod" \\
  && ok "cmd/gf/go.mod" \\
  || miss "missing critical file: cmd/gf/go.mod"
test -f "cmd/gf/internal/cmd/cmd_gen.go" \\
  && ok "cmd/gf/internal/cmd/cmd_gen.go" \\
  || miss "missing critical file: cmd/gf/internal/cmd/cmd_gen.go"
test -f "cmd/gf/internal/cmd/cmd_build.go" \\
  && ok "cmd/gf/internal/cmd/cmd_build.go" \\
  || miss "missing critical file: cmd/gf/internal/cmd/cmd_build.go"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 39 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~9d)"
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/gogf/gf"
  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).

GoFrame is a comprehensive Go web framework providing rapid development tools for building enterprise applications with built-in support for ORM, caching, validation, logging, and microservices. It solves the problem of Go backend developers needing a batteries-included framework similar to Laravel or Django, offering code generation (gf cmd tools in cmd/gf/v2), multiple database drivers (MySQL, PostgreSQL, SQLite, Oracle, MSSQL, ClickHouse via contrib/drivers/), and a CLI toolchain for scaffolding. Monorepo structured as: github.com/gogf/gf/v2 is the core framework (9.8MB Go code), cmd/gf/v2 contains the CLI toolchain, contrib/drivers/* holds database driver implementations (each separately versioned at v2.10.0). Parallel structure at github.com/gogf/gf-site for documentation, and the .agents/ folder indicates AI-assisted proposal and review workflows are integrated into the repo itself.

Go developers building REST APIs, web applications, and microservices who want rapid scaffolding and a cohesive ecosystem without assembling disparate libraries. Specifically teams that prefer convention-over-configuration frameworks and need enterprise features like distributed tracing, config management (Apollo, Consul support visible in CI workflows), and ORM with automatic migrations.

Highly mature and production-ready. The project has 9.8MB of Go code, comprehensive CI setup (.github/workflows with ci-main.yml, codeql.yml, golangci-lint.yml), OpenSSF security scorecard badge, CII Best Practices certification, and active development indicated by v2.10.0 release. The .agents directory shows ongoing AI-assisted development tooling, indicating sustained investment.

Low technical risk: extensive test coverage (codecov integration), strong governance (issue templates, PR templates, multiple workflows). Slight organizational risk: while not single-maintainer (contributors.svg shown), the monorepo structure with driver contrib packages (clickhouse, mssql, mysql, oracle, pgsql, sqlite) means updates to the core can affect all drivers. No major breaking changes apparent in v2 versioning.

Active development on v2.10.0 with recent CI workflow refinements (format-code-on-push.yml, issue lifecycle automation with issue-labeled.yml, issue-check-inactive.yml, issue-close-inactive.yml). The .agents/ directory with skills (gf-feedback, gf-review, openspec-explore, openspec-propose) and git-worktree automation indicates recent investment in developer experience and AI-assisted code review tooling.

Clone and build: git clone https://github.com/gogf/gf.git && cd gf && go mod download. Install the CLI tool: go install github.com/gogf/gf/cmd/gf/v2@latest. Verify: gf --version. Create a new project: gf gen http my-app (scaffolds a web application using the gf command in cmd/gf/v2).

Daily commands: For the framework library itself: go test ./... to run tests. For the CLI tool: go run ./cmd/gf/v2 --help to see available commands. Create a new web app: go run ./cmd/gf/v2 gen http my-project && cd my-project && go run main.go (starts HTTP server, typically on :8080).

• cmd/gf/gfcmd/gfcmd.go — Entry point for the GF CLI tool—initializes and executes all command handlers
• cmd/gf/internal/cmd/cmd.go — Core command dispatcher and base structure for all gf CLI subcommands
• cmd/gf/go.mod — Defines all dependencies for the gf CLI including database drivers and framework version constraints
• cmd/gf/internal/cmd/cmd_gen.go — Central code generation orchestrator—routes to DAO, service, controller, and other generators
• cmd/gf/internal/cmd/cmd_build.go — Build and compilation pipeline for GoFrame projects—handles versioning and binary creation
• .github/workflows/ci-main.yml — Primary CI/CD pipeline defining test, build, and release stages for the framework
• Makefile — Project-wide build targets and development tooling orchestration

Add a New CLI Command

1. Create a new handler function in cmd/gf/internal/cmd/ following the naming convention cmd_<command>.go (e.g., cmd_mycommand.go). Implement the command struct and Exec() method matching existing patterns. (cmd/gf/internal/cmd/cmd_mycommand.go)
2. Register the command in cmd/gf/internal/cmd/cmd.go by adding it to the main command registry/dispatch logic in the command struct. (cmd/gf/internal/cmd/cmd.go)
3. Test the command locally by running gf mycommand and ensure help text is generated via standard flag definitions. (cmd/gf/gfcmd/gfcmd.go)

Add Code Generation for a New Artifact Type

1. Create a new generator file cmd/gf/internal/cmd/cmd_gen_<artifact>.go (e.g., cmd_gen_migration.go) that parses input (schema, config, template) and outputs generated code. (cmd/gf/internal/cmd/cmd_gen_artifact.go)
2. Hook the new generator into cmd_gen.go by adding a case/branch that calls your generator function with proper output routing. (cmd/gf/internal/cmd/cmd_gen.go)
3. Update documentation in README or docs to explain the new generator's flags and usage patterns. (README.MD)

Extend CI/CD Pipeline with a New Test Stage

1. Add a new job or step to .github/workflows/ci-main.yml under the appropriate section (build, test, or lint) that invokes your test or validation logic. (.github/workflows/ci-main.yml)
2. Create or update a corresponding shell script in .github/workflows/scripts/ (e.g., ci-new-test.sh) that encapsulates the test logic and environment setup. (.github/workflows/scripts/ci-main.sh)
3. Verify the workflow runs correctly on a feature branch and produces expected success/failure signals. (.github/workflows/ci-main.yml)

Support a New Database Driver in Code Generation

1. Update cmd/gf/go.mod to include the new database driver dependency (e.g., contrib/drivers/newdb/v2). (cmd/gf/go.mod)
2. Extend cmd_gen_dao.go to recognize and handle the new database driver's schema introspection dialect and code generation templates. (cmd/gf/internal/cmd/cmd_gen_dao.go)
3. Add integration tests in the CI pipeline to validate code generation against the new database type. (.github/workflows/ci-main.yml)

• Go 1.23+ — Type safety, built-in concurrency, fast compilation, and cross-platform binary support for a CLI tool used by millions of developers
• Protocol Buffers & gRPC — Code generation targets proto and gRPC services; the CLI must support multi-language stub generation and service definitions
• GitHub Actions CI/CD — Native GitHub integration, matrix testing across multiple databases (MySQL, PostgreSQL, SQLite, Oracle, MSSQL, ClickHouse) and Go versions
• Self-update mechanism (github.com/gogf/selfupdate) — CLI distribution and automatic updates without requiring package manager reimplementation

• Monorepo structure (cmd/ for CLI, main framework modules separate)

  • Why: Centralize framework and tooling together for easier dependency management and coordinated releases
  • Consequence: Larger repo size and more complex versioning; requires careful go.mod coordination across modules

• Code generation over runtime reflection for DAO/service/controller

  • Why: Pre-computed code enables type safety, IDE autocomplete, and fast query execution without reflection overhead
  • Consequence: Developers must re-run generation when schemas change; more artifacts in version control

• Multi-database driver support in single codebase

  • Why: GoFrame targets enterprise users who migrate between databases; unified interface reduces lock-in
  • Consequence: Larger go.mod, more complex CI matrix, and longer test cycles

• Language-agnostic code generation (Go-only output)
• Interactive UI for CLI (terminal text-based only)
• Real-time project monitoring or hot-reload (build-time tooling, not runtime daemon)
• Cloud-native deployment orchestration (generates code; does not deploy containers)

1. Database driver versions: each contrib driver (clickhouse, mssql, mysql, oracle, pgsql, sqlite) is separately versioned at v2.10.0 and has its own go.mod; updating core gf may require coordinated updates across all drivers. 2) CLI self-updating: gogf/selfupdate dependency means the gf tool can auto-update; verify checksum validation in SKILL.md files (.agents/skills/git-commit-push/SKILL.md hints at deployment concerns). 3) Code generation is framework-opinionated: gf gen http creates scaffold following specific patterns; deviating from these patterns may break tool integration. 4) Multiple mirrors: README lists goframe.org, goframe.org.cn, pages.goframe.org, and offline PDF docs; ensure docs are in sync if following tutorials.

• Code Generation (Scaffolding) — GoFrame's cmd/gf/v2 tool uses code generation extensively (gf gen http, gf gen model, etc.); understanding how templates and generators work is essential for extending GoFrame and customizing scaffolds
• ORM with Database Drivers — The contrib/drivers/ architecture shows pluggable database support (MySQL, PostgreSQL, Oracle, MSSQL, SQLite, ClickHouse); learning the driver interface pattern is critical for database-heavy applications
• Plugin Architecture — GoFrame supports pluggable drivers and middleware; the contrib/ folder structure demonstrates how to extend functionality without modifying core, essential for building maintainable large applications
• Monorepo Package Management — GoFrame uses Go module versioning across multiple packages (gf/v2, cmd/gf/v2, contrib/drivers/*/v2) with coordinated releases; understanding go.mod dependencies across monorepos prevents version conflicts
• Self-Updating CLI Tools — The gogf/selfupdate dependency in cmd/gf/v2 shows how the gf CLI can auto-update securely; relevant for understanding deployment and distribution of Go tools
• Configuration Management (Apollo/Consul Integration) — .github/workflows contain Apollo and Consul test fixtures; GoFrame supports remote config management patterns used in distributed systems, critical for microservices deployments
• OpenSSF Security Practices — GoFrame holds CII Best Practices and OpenSSF Scorecard badges; the codeql.yml workflow and security badges indicate how to build secure Go frameworks and what best practices to follow

• gin-gonic/gin — Lightweight Go HTTP router and framework; GoFrame builds on similar HTTP patterns but adds ORM, code generation, and microservices features
• gorm/gorm — Industry-standard Go ORM; GoFrame includes its own ORM but developers familiar with GORM can compare patterns and migration strategies
• gogf/gf-site — Official documentation source repository for GoFrame; contributors often work across both repos when updating docs alongside code changes
• go-kit/kit — Go microservices toolkit providing patterns for distributed tracing and service orchestration; complementary to GoFrame's microservices support
• beego/beego — Comparable full-stack Go framework with similar ORM and admin panel features; represents the category of batteries-included frameworks GoFrame targets

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 comprehensive CI workflow for database driver integration tests

The repo has multiple database drivers (clickhouse, mssql, mysql, oracle, pgsql, sqlite) but the CI workflows (.github/workflows/ci-main.yml, ci-sub.yml) don't show explicit integration test coverage for all drivers. Given the docker-compose files exist for apollo, consul, nacos, and redis, a dedicated workflow should test each driver against its corresponding database service. This is critical for a framework targeting production use.

• [ ] Review .github/workflows/ci-main.yml and ci-sub.yml to identify missing driver test coverage
• [ ] Create .github/workflows/ci-database-drivers.yml that spins up docker services for each driver (using existing docker-compose patterns)
• [ ] Add test matrix for all 6 drivers: clickhouse, mssql, mysql, oracle, pgsql, sqlite
• [ ] Configure workflow to run on PR and push to master, ensuring backward compatibility

Implement OpenSpec proposal workflow automation for driver contributions

The repo has OpenSpec agent skills (.agents/skills/openspec-propose, openspec-explore) and OpSx prompts (propose.md, apply.md) but these appear unused in current CI. For a framework accepting driver contributions, automating the proposal/specification phase could significantly improve code quality. This would guide contributors through a structured spec-first approach for new drivers or major features.

• [ ] Examine .agents/skills/openspec-propose/SKILL.md and .agents/prompts/opsx/propose.md to understand current specification
• [ ] Create .github/workflows/openspec-pr-check.yml that triggers on PRs touching cmd/gf/* or contrib/drivers/*
• [ ] Integrate OpenSpec skill to auto-comment on PRs requesting a spec document (SPEC.md) for new drivers
• [ ] Document expected spec template in CONTRIBUTING.md referencing the OpenSpec prompt patterns

Add framework compatibility matrix documentation and validation

The go.mod shows Go 1.23.0 requirement and dependencies on multiple driver versions (v2.10.0). There's no visible compatibility matrix documentation or automated validation. Contributors need to know which Go versions, database versions, and driver combinations are tested and supported. Add a compatibility matrix document and corresponding validation.

• [ ] Create docs/COMPATIBILITY.md documenting tested Go versions, database versions, and driver version matrix
• [ ] Add .github/workflows/compatibility-matrix.yml that tests against multiple Go versions (1.21, 1.22, 1.23) and key databases
• [ ] Update .github/ISSUE_TEMPLATE/03-question.yml to reference compatibility matrix when users report issues
• [ ] Document the matrix in README.md with a reference table or badge system

• Add test coverage for contrib/drivers/clickhouse/v2: currently v2.10.0 release present but testing infrastructure not visible in file list; adding clickhouse-specific integration tests would improve reliability
• Enhance CLI help messages: cmd/gf/v2 commands likely need better examples; adding runnable examples to gf gen subcommand help text (e.g., gf gen http --help showing actual generated project structure) would aid developers
• Document driver selection guide: README lists 6 database drivers but .github/ISSUE_TEMPLATE/*.yml files don't include decision tree; create docs/DRIVER_SELECTION.md explaining when to use Oracle vs MSSQL vs PostgreSQL for specific use cases

The GoFrame project demonstrates a reasonable security posture with active maintenance, CI/CD workflows, and security badges (OpenSSF Scorecard, CII Best Practices). However, several areas require attention: (1) Regular dependency updates are critical, particularly for golang.org/x packages; (2) The self-update mechanism requires strong cryptographic validation; (3) CLI tool error handling should be reviewed to prevent information disclosure; (4) Multiple database drivers increase attack surface and require ongoing monitoring. The project shows good security awareness with defined issue templates, workflows, and contributor guidelines, but dependency management and regular security audits should be prioritized.

• Medium · Outdated Dependency: golang.org/x/tools — cmd/gf/go.mod. The repository uses golang.org/x/tools v0.26.0. This package is frequently updated with security fixes. Using an older version may expose the codebase to known vulnerabilities in code analysis and generation tools. Fix: Regularly update golang.org/x/tools to the latest stable version. Run 'go get -u golang.org/x/tools' and test thoroughly.
• Medium · Outdated Dependency: golang.org/x/mod — cmd/gf/go.mod. The golang.org/x/mod package (v0.25.0) is used for module operations. Outdated versions may contain security vulnerabilities or bugs affecting module resolution and integrity checks. Fix: Update golang.org/x/mod to the latest stable version. Run 'go get -u golang.org/x/mod' and verify all tests pass.
• Low · Self-Update Mechanism Risk — cmd/gf/go.mod. The dependency 'github.com/gogf/selfupdate' (v0.0.0-20231215043001-5c48c528462f) is a self-update utility for CLI tools. While useful, such mechanisms require careful implementation to prevent man-in-the-middle attacks or signature verification bypasses. Fix: Ensure the selfupdate package validates cryptographic signatures (minisign dependency noted) on all updates. Implement certificate pinning where possible and ensure updates use HTTPS only.
• Low · Potential Information Disclosure via Help/Error Messages — cmd/gf/gfcmd/gfcmd.go. The gf CLI tool structure suggests command-line usage. CLI tools can inadvertently expose sensitive information through verbose error messages, stack traces, or version information if not properly sanitized. Fix: Review error handling to ensure sensitive paths, internal IPs, or system details are not exposed in error messages. Implement proper logging levels (debug vs. production).
• Low · Multiple Database Driver Dependencies — cmd/gf/go.mod. The project includes multiple database drivers (MySQL, PostgreSQL, MSSQL, Oracle, ClickHouse, SQLite). While necessary for flexibility, each driver introduces potential attack surface. Some older versions may have unpatched vulnerabilities. Fix: Regularly audit and update all database drivers to their latest stable versions. Consider using only the drivers your application actually needs. Monitor CVE databases for driver-specific issues.

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.