sazardev/goca

This system is a Go-based command-line interface and scaffolding tool designed to generate and maintain projects following Clean Architecture principles. It provides infrastructure for initializing new Go applications with domain models, RESTful APIs, and database repositories, while offering a self-analysis command to audit code quality, security, and architectural compliance. The project also includes tooling for automated releases, development environment setup, and marketing asset generation.

The application now includes structured domain entities for Users, Products, and Orders, each equipped with validation logic to enforce data integrity. Users can now be managed with soft-delete capabilities, while Products and Orders include specific validation rules for their respective fields, ensuring that invalid data is caught early in the process.

github.com/sazardev/goca · high confidence

New symbolic links for Golang skills have been added to the .claude directory, pointing to the golang-patterns and golang-testing skill definitions located in the .agents/skills directory. This enables the assistant to apply specific Go best practices and testing strategies when working with Golang projects.

.claude · high confidence

New PowerShell (install-hooks.ps1) and Bash (install-hooks.sh) scripts have been added to the scripts directory to automate the setup of development tooling. These scripts detect prerequisites (Go 1.25+, Node.js 18+, npm), install specific Go-based linting and security tools (lefthook, gofumpt, gosec, nilaway, staticcheck, golangci-lint), install documentation dependencies, and configure git hooks via lefthook for pre-commit and pre-push stages.

scripts · high confidence

This change introduces the core domain models for Users, Products, and Orders, including validation logic, error definitions, and seed data for database initialization. It establishes a complete layered architecture for these entities: HTTP handlers and route configurations expose RESTful endpoints (CRUD operations) via Gorilla Mux, while GORM-based PostgreSQL repositories handle data persistence. A dependency injection container wires these components together, and comprehensive mock implementations are provided to support unit testing of the use cases and handlers.

internal · high confidence

The repository now includes essential configuration files for development and release workflows. A \.goca.yaml\ file defines default project settings for Clean Architecture generation, including database types, validation rules, and quality gates. A \.golangci.yml\ file configures the linter with specific rules and disabled checks. A \.goreleaser.yml\ file sets up automated binary releases for Linux, Windows, and macOS, including Homebrew tap integration. Additionally, a \.gitattributes\ file ensures consistent line endings across different file types, and a \Makefile\ provides standard commands for building, testing, linting, and releasing the CLI tool.

(repo-wide) · high confidence

A new command-line utility has been added to the tools directory that automates the setup of a GoCA project structure. This tool creates a temporary directory, initializes a new project with a specified module path, generates a sample entity (such as a User with defined fields), and displays the resulting source code, providing a quick way to scaffold and verify project generation logic.

cmd/tools · high confidence

The CLI now includes an \analyze\ command that performs a comprehensive audit of the generated Go project. It checks six categories—Architecture, Quality, Security, Standards, Tests, and Dependencies—verifying Clean Architecture layer boundaries, domain purity, OWASP A03 security patterns, Go conventions, test coverage, and dependency health. The command supports filtering by category, outputting results in text or JSON format, and failing on warnings via \--fail-on-warn\, providing actionable suggestions for any rule violations.

cmd · high confidence

The marketing folder now includes a complete, script-driven system for generating and rendering Goca's marketing assets. This introduces a shared brand token library (colors, fonts, icons) and Node.js scripts to automatically generate static SVG/PNG cards for all 21 CLI commands in multiple formats and themes, as well as animated SVG frames for a 23-second vertical explainer video and per-command command videos. Bash scripts (\generate.sh\, \render-video.sh\, \render-command-videos.sh\) orchestrate the rasterization and encoding pipeline, while the \README\ documents the brand guidelines and asset structure.

marketing · high confidence

The main Go module now targets Go 1.25.1 and significantly expands its dependency graph, adding direct dependencies for the new CLI UX and AI features (charmbracelet/huh, charmbracelet/lipgloss, mark3labs/mcp-go, gorilla/mux, gorm.io/gorm) while upgrading core libraries like spf13/cobra to v1.10.1 and spf13/pflag to v1.0.10. Concurrently, the project introduces a new VitePress-based documentation site in the docs folder, establishing a new package.json and package-lock.json that install VitePress v1.0.0-rc.31, mermaid v11.14.0, and Vercel OG image generation tools.

(dependencies) · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 57 → 66 (+9.0)
• Rubric changed (rubric-2026.08.17 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 76 → 64 (-11.4)
• Architecture 100 → 95 (-4.8)
• Maturity 76 → 80 (+4.2)
• Readiness 50 → 63 (+13.1)
• Security 56 → 71 (+15.0)
• Domain Modelling 58 → 65 (+7.7)

• Coverage not included — suite not readable by the collector
• Dependency hygiene not measured — no supported dependency manifest was read
• Duplicated block (10 lines × 2) (cmd/handler_other.go)
• Duplicated block (10 lines × 2) (internal/testing/scenarios.go)
• Duplicated block (10 lines × 2) (internal/testing/scenarios.go)
• Duplicated block (10 lines × 3) (cmd/entity_test_generator.go)
• Duplicated block (10 lines × 3) (cmd/mcp_tools_util.go)
• Duplicated block (10 lines × 3) (internal/testing/scenarios.go)
• Duplicated block (10–11 lines × 2) (cmd/repository_impl.go)
• Duplicated block (10–11 lines × 4) (cmd/handler.go)
• Duplicated block (10–14 lines × 3) (cmd/cache_decorator.go)
• Duplicated block (10–14 lines × 3) (cmd/handler_other.go)
• Duplicated block (11 lines × 2) (cmd/entity.go)
• Duplicated block (11 lines × 2) (cmd/handler.go)
• Duplicated block (11 lines × 2) (cmd/mocks.go)
• Duplicated block (11 lines × 2) (cmd/repository_other_db.go)
• Duplicated block (11 lines × 2) (cmd/usecase.go)
• Duplicated block (11 lines × 2) (internal/testing/scenarios.go)
• Duplicated block (11 lines × 3) (internal/handler/http/order_handler.go)
• Duplicated block (11–12 lines × 2) (cmd/safety.go)
• …and 160 more

• Documentation: no usage examples (README.md)
• Duplicated block (10 lines × 2) (cmd/field_validator.go)
• Duplicated block (10 lines × 2) (cmd/handler_other.go)
• Duplicated block (10 lines × 2) (cmd/upgrade.go)
• Duplicated block (10 lines × 2) (internal/testing/suite.go)
• Duplicated block (10 lines × 3) (internal/handler/http/order_handler.go)
• Duplicated block (10 lines × 3) (internal/testing/architecture.go)
• Duplicated block (11 lines × 2) (cmd/handler.go)
• Duplicated block (11 lines × 2) (cmd/repository.go)
• Duplicated block (11 lines × 2) (cmd/repository_impl.go)
• Duplicated block (11 lines × 2) (cmd/usecase.go)
• Duplicated block (11 lines × 3) (internal/handler/http/order_handler.go)
• Duplicated block (12 lines × 2) (cmd/handler_other.go)
• Duplicated block (12 lines × 3) (internal/handler/http/order_handler.go)
• Duplicated block (12 lines × 3) (internal/handler/http/order_handler.go)
• Duplicated block (13 lines × 2) (cmd/repository_fields.go)
• Duplicated block (13 lines × 2) (internal/testing/validator.go)
• Duplicated block (15 lines × 3) (internal/handler/http/order_handler.go)
• Duplicated block (18 lines × 2) (cmd/messages.go)
• Duplicated block (18–19 lines × 2) (cmd/repository.go)
• …and 107 more

• Containers 0 added · 0 removed · contexts 0 added · 1 removed · edges 0 added · 0 removed

• testvalidation

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

sazardev/goca was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.