goca analyze

goca analyze performs a deep static self-analysis of the project generated by Goca. It audits architecture correctness, code quality, security patterns, Go standards, test coverage, and dependency hygiene — all in one command.

Syntax

goca analyze [flags]

Purpose

Unlike goca doctor (which checks project health at a structural level), analyze inspects the content of your generated Go code:

• Enforces Clean Architecture layer boundaries using Go's AST parser
• Detects OWASP A03 security anti-patterns (SQL injection, hardcoded secrets, unsafe packages)
• Validates Go naming and documentation conventions
• Checks test quality patterns (table-driven, mocks, t.TempDir())
• Audits dependency hygiene in go.mod

Flags

Flag	Type	Default	Description
--arch	bool	false	Only run architecture checks
--quality	bool	false	Only run code quality checks
--security	bool	false	Only run security checks
--standards	bool	false	Only run Go standards checks
--tests	bool	false	Only run test quality checks
--deps	bool	false	Only run dependency checks
--output	string	text	Output format: text or json
--fail-on-warn	bool	false	Exit with code 2 when warnings are present

When no category flag is set, all 6 categories run.

Exit Codes

Code	Meaning
0	All checks passed
1	One or more checks failed
2	Warnings present with --fail-on-warn

Usage Examples

Full analysis

goca analyze

Security-only for CI

goca analyze --security --fail-on-warn

Architecture check only

goca analyze --arch

JSON output for tooling

goca analyze --output json | jq '.[] | select(.status == "✗")'

Strict CI pipeline (fail on any warning)

goca analyze --fail-on-warn

Check Categories

Architecture (6 rules)

Rule	Description
layer-dirs	All 4 CA layers (domain, usecase, repository, handler) must exist
domain-purity	internal/domain must not import ORMs or external frameworks
usecase-no-handler	Use cases must not depend on the handler layer
repo-impl-coverage	Each domain entity should have a repository implementation
di-container	A DI container must exist in internal/di
handler-no-repo	Handlers must not import repositories directly (must go through use cases)

Quality (5 rules)

Rule	Description
no-empty-files	No .go files with only a package declaration
package-naming	Packages must be lowercase single words (no underscores)
no-todos	No // TODO or // FIXME comments in generated code
exported-docs	All exported functions must have godoc comments
main-go	An entry point main.go must exist

Security (5 rules)

Rule	Description
no-hardcoded-secrets	No string assignments that look like passwords/tokens/secrets
no-sql-injection	No fmt.Sprintf("SELECT/INSERT/UPDATE/DELETE patterns (OWASP A03)
no-unsafe	No import "unsafe" in generated application code
no-tls-skip	No InsecureSkipVerify: true in TLS config
env-config	Sensitive config should be read from os.Getenv()

Standards (5 rules)

Rule	Description
file-naming	Go files must use snake_case (no kebab-case)
no-init-in-domain	No init() functions in domain layer
go-mod-valid	go.mod must have a valid module declaration
goca-yaml	.goca.yaml must be present and non-empty
context-propagation	context.Context must be used in repository and use case layers

Tests (4 rules)

Rule	Description
test-files-exist	Each non-empty layer must have *_test.go files
table-driven-tests	At least one []struct{...} table-driven test must exist
mocks-exist	A mocks directory must be present
test-tempdir	Tests must use t.TempDir(), not hardcoded /tmp paths

Dependencies (4 rules)

Rule	Description
go-mod-tidy	go.sum must exist when go.mod has require blocks
no-replace	No replace directives (local dev artifact)
go-version	go.mod must declare a Go version
no-insecure-modules	No known-insecure or deprecated modules (e.g., dgrijalva/jwt-go)

Sample Output

Goca Analyze — Deep Project Self-Analysis

Step 1 — Architecture analysis
Step 2 — Code quality analysis
Step 3 — Security analysis
Step 4 — Standards analysis
Step 5 — Test coverage analysis
Step 6 — Dependency analysis

Architecture
 ✓  layer-dirs           project   All 4 Clean Architecture layers present      —
 ✓  domain-purity        project   Domain layer imports only stdlib              —
 ✓  usecase-no-handler   project   Use cases do not import handler layer         —
 ✓  repo-impl-coverage   project   Repository implementations found for 3 ents  —
 ✓  di-container         project   DI container present (2 files)               —
 ✓  handler-no-repo      project   Handlers do not import repository directly   —

Security
 ✓  no-hardcoded-secrets  project  No hardcoded secret patterns detected         —
 ✗  no-sql-injection       internal/repository/user.go
                                   SQL query built with fmt.Sprintf              Use parameterised queries

Analyzed 29 rules — 28 passed, 0 warnings, 1 failed

MCP Integration

goca analyze is exposed as the goca_analyze tool in the MCP server, allowing AI assistants (GitHub Copilot, Claude, Cursor) to audit your project and suggest fixes automatically.

{
  "tool": "goca_analyze",
  "arguments": {
    "security": true,
    "output": "json"
  }
}

Related Commands

• goca doctor — Structural health check (directories, build, DI)
• goca upgrade — Upgrade .goca.yaml to current format
• goca mcp-server — Run goca_analyze as an AI assistant tool