Skip to content

v1.22.0 — Analyze, Cache, CI & Middleware

Release Date: March 27, 2026

Version 1.22.0 is the largest feature release in Goca's history. It brings deep static self-analysis (goca analyze), Redis caching with the decorator pattern, CI pipeline generation, standalone middleware packages, an MCP server for AI assistant integration, and several code quality improvements.


Highlights

FeatureCommand / FlagWhat it does
Self-Analysisgoca analyze30 rules across 6 categories — architecture, quality, security, standards, tests, deps
Redis Cache--cache on feature, repository, diDecorator-pattern Cached<Entity>Repository + Redis client factory
CI Pipelinegoca ciGitHub Actions workflows (test, build, deploy)
Middlewaregoca middleware <name>internal/middleware/ with 7 composable HTTP middleware types
AI Integrationgoca mcp-serverMCP server exposing all Goca commands as AI-callable tools

goca analyze — Deep Project Self-Analysis

The headline feature of v1.22.0. goca analyze performs a comprehensive static audit of your generated Go project — going far beyond goca doctor's structural checks.

What it checks

CategoryRulesExamples
Architecture6Domain purity (no ORM imports), use-case/handler/repository import boundaries, DI container presence
Quality5Empty files, package naming, TODO detection, exported doc comments, main.go presence
Security5Hardcoded secrets (OWASP A03), SQL injection via fmt.Sprintf, unsafe package, TLS bypass, env var config
Standards5snake_case file naming, no init() in domain, valid go.mod, .goca.yaml presence, context.Context propagation
Tests4Test file presence per layer, table-driven patterns, mock directory, t.TempDir() vs hardcoded /tmp
Dependencies4go.sum presence, replace directive warning, Go version declaration, known-insecure modules

Usage

bash
# Full analysis (all 30 rules)
goca analyze

# Single category
goca analyze --arch
goca analyze --security
goca analyze --tests

# Machine-readable output (CI integration)
goca analyze --output json

# Fail pipeline on warnings
goca analyze --fail-on-warn

Sample output

Architecture
────────────
 ✓  layer-dirs        All 4 Clean Architecture layers present
 ✓  domain-purity     Domain layer imports only stdlib
 ✓  usecase-no-handler  Use cases do not import handler layer
 ✓  repo-impl-coverage  Implementations found for all 3 entities
 ✓  di-container      DI container present (1 files)
 ✓  handler-no-repo   Handlers do not import repository layer directly

ℹ Analyzed 6 rules — 6 passed, 0 warnings, 0 failed

Implementation

  • Uses Go's go/parser and go/ast stdlib for accurate import analysis — not string grep
  • findForbiddenImports() traverses AST import declarations for precise boundary checks
  • collectEntityNames() scans domain package via AST to enumerate entities for repo coverage checks
  • Exposed as goca_analyze MCP tool for AI assistant integration
  • New files: cmd/analyze.go, cmd/analyze_checks.go
  • 46 tests in cmd/analyze_test.go covering all 6 categories

Redis Cache Layer (--cache flag)

A new --cache / -c flag is available on three commands: goca feature, goca repository, and goca di.

Usage

bash
# Generate a full feature with Redis caching included
goca feature Product --fields "name:string,price:float64" --cache

# Add a cache decorator to an existing repository
goca repository Product --database postgres --cache

# Wire cache decorators in the DI container
goca di --features "Product,User" --cache

What gets generated

internal/
├── cache/
│   └── redis.go                          # Redis client factory (REDIS_URL, REDIS_PASSWORD, REDIS_DB env vars)
└── repository/
    └── cached_product_repository.go      # Decorator wrapping postgres repo with Redis

The Cached<Entity>Repository wraps any <Entity>Repository interface — reads check Redis first, misses delegate to the inner repo then cache the result, writes invalidate relevant keys.

DI wiring

go
// With --cache, the DI constructor accepts *redis.Client
func NewContainer(db *gorm.DB, redisClient *redis.Client) *Container {
    repo := repository.NewPostgresProductRepository(db)
    cachedRepo := repository.NewCachedProductRepository(repo, redisClient)
    uc := usecase.NewProductUseCase(cachedRepo)
    ...
}

CI Pipeline Generation (goca ci)

New goca ci command generates Continuous Integration workflow files for GitHub Actions.

bash
# Basic test + build workflows
goca ci

# With Docker build step
goca ci --with-docker

# With deployment workflow (tag-triggered)
goca ci --with-deploy

# Target provider (currently github-actions only)
goca ci --provider github-actions

Auto-detects Go version from go.mod and database driver from .goca.yaml to add the correct service container configuration.

Generated files

.github/workflows/
├── test.yml     # runs go test ./... on push and PR
├── build.yml    # compiles binary, uploads artifact
└── deploy.yml   # tag-triggered deploy (with --with-deploy)

Middleware Generation (goca middleware)

New goca middleware <name> command generates a composable middleware package at internal/middleware/.

bash
# Generate all 7 middleware types
goca middleware MyApp

# Specific types only
goca middleware MyApp --types "auth,cors,logging"

# Generate alongside a feature
goca feature Product --middleware-types "auth,cors"

Available types

TypeGenerated functionWhat it does
corsCORS()Cross-Origin Resource Sharing headers
loggingLogging()Request/response structured logging
authAuth()JWT Bearer token validation
rate-limitRateLimit()Token bucket rate limiting
recoveryRecovery()Panic recovery to 500 response
request-idRequestID()Injects X-Request-ID header
timeoutTimeout()Request context deadline

All middleware follows func(http.Handler) http.Handler. A Chain() helper composes them in order.


MCP Server — AI Assistant Integration (goca mcp-server)

goca mcp-server starts a Model Context Protocol server over stdio, exposing all Goca commands as AI-callable tools. Compatible with GitHub Copilot (VS Code), Claude Desktop, Cursor, and Zed.

bash
# Print config snippet for your editor
goca mcp-server --print-config vscode
goca mcp-server --print-config claude

13 tools exposed: goca_feature, goca_entity, goca_usecase, goca_repository, goca_handler, goca_di, goca_integrate, goca_interfaces, goca_messages, goca_mocks, goca_init, goca_doctor, goca_analyze.

2 MCP resources: goca://config (.goca.yaml) and goca://structure (project directory tree).


Code Quality Improvements

Domain Purity Fix

internal/domain/user.go previously imported gorm.io/gorm for the gorm.DeletedAt soft-delete type — a Clean Architecture violation (domain must not depend on ORMs). Fixed by switching to *time.Time:

go
// Before — domain depended on ORM type
DeletedAt gorm.DeletedAt `json:"deleted_at,omitempty" gorm:"index"`

// After — pure domain type, zero external dependencies
DeletedAt *time.Time `json:"deleted_at,omitempty" gorm:"index"`

This violation is now caught by goca analyze --arch (domain-purity rule).

Test Quality — t.TempDir() Everywhere

All hardcoded /tmp/... paths in test files replaced with t.TempDir() for proper isolation and automatic cleanup. The test-tempdir rule in goca analyze --tests verifies this automatically.


Migration Guide

No breaking changes. All new flags are additive (--cache, --middleware-types, --with-docker, --with-deploy). Existing commands and generated code continue to work unchanged.

If you use gorm.DeletedAt in your domain entities, consider migrating to *time.Time for clean architecture compliance.


What's Next

  • goca scaffold — full project scaffolding from a configuration template
  • Enhanced goca analyze rules for concurrency patterns and context propagation
  • PostgreSQL-specific repository optimizations (bulk insert, advisory locks)

Released under the MIT License.