Skip to content
CAI
Software that uses CAICheck a score

ThreeDotsLabs/wild-workouts-go-ddd-example

64.1

Adequate · 21 September 2026

3.8k

lines of production code

Go

primary language

4

measurements over time

CAI band scale
CAI trend line
CAI lens gauges

What this system is

Wild Workouts is a multi-service backend system for managing personal training sessions, structured around Trainer, Trainings, and Users domains. It employs a Clean Architecture with CQRS patterns to handle business logic for scheduling, availability management, and user profiles, persisting data via both Google Cloud Firestore and MySQL. The system exposes functionality through HTTP and gRPC endpoints, supported by a Vue.js web client for end-user interactions.

Features

Add C4 architecture diagram generation tool

A new Go-based tool in the \tools/c4\ directory has been added to automatically generate C4-style PlantUML diagrams of the application's architecture. The tool uses the \go-structurizr\ library to scrape the \trainer\ and \trainings\ service codebases, applying configuration rules from \scraper.yml\ to map internal components (such as application commands/queries, domain logic, and adapters) to C4 model elements. The resulting diagrams, saved as \view-trainer.plantuml\ and \view-trainings.plantuml\, visualize the system structure including dependencies on Firestore and gRPC services, and can be rendered to PNG images using PlantUML via the provided \Taskfile.yml\ tasks.

tools · high confidence

Added hours availability schema

A new database table named \hours\ has been introduced to track hourly availability. This table stores a timestamp as the primary key and an availability status field that can be set to 'available', 'not\_available', or 'training\_scheduled'.

sql · high confidence

Added local Firestore emulator container for development

Developers can now run a local Firestore emulator via Docker to test application features without using production resources. This change introduces the necessary configuration files (firebase.json, .firebaserc) and a Dockerfile based on Node 16 to containerize the Firebase Emulator Suite (version 10.9.2), enabling local development workflows.

docker/firestore-emulator · high confidence

Initial Terraform infrastructure for Wild Workouts on Google Cloud

This change introduces the complete Terraform configuration to provision the Wild Workouts application infrastructure on Google Cloud Platform. It defines resources for Cloud Run services (trainer, trainings, users) supporting both gRPC and HTTP protocols, a Firebase Web App, and a Firestore database with a specific composite index for the trainings collection. The setup includes an Artifact Registry for Docker images, IAM roles for the owner and GitHub Actions (via Workload Identity Federation), and a Taskfile to automate the deployment workflow, including interactive environment variable configuration and CI/CD variable setup.

terraform · high confidence

Initial release of the Wild Workouts Vue.js web client

This change introduces the complete frontend application for Wild Workouts, built with Vue.js and Vue Router. It provides the user interface for managing personal training sessions, including a login page with demo account support, a training list view, a calendar for viewing sessions, and forms for scheduling or rescheduling trainings. Trainers can use the 'Set Schedule' page to define their availability. The app features a custom 'editorial athletic' design system with specific typography and color variables, integrates with Firebase for hosting and authentication, and configures Firebase Hosting rewrites to proxy API requests to backend services.

web · high confidence

Introduce Firestore, MySQL, and in-memory repositories for trainer hours

The trainer domain now supports persistence of hour availability data through three new repository implementations: a Firestore adapter, a MySQL adapter, and an in-memory adapter. These adapters implement the domain repository interface, allowing the application to retrieve and update hour records (including availability and training scheduling status) using either Google Cloud Firestore, a MySQL database, or an in-memory map. The MySQL implementation includes logic to handle deadlocks and transactions, while the Firestore implementation handles date ranges and missing hours. A comprehensive test suite validates the behavior of all three repository types, including parallel update scenarios.

internal/trainer/adapters · high confidence

New hour availability management and repository interface

The trainer domain now introduces a structured \Hour\ entity with strict availability states (available, not available, training scheduled) and a dedicated repository interface. Users can now schedule, cancel, or modify training hours with enforced business rules, such as preventing modifications to hours that already have scheduled training. The \Hour\ factory validates inputs to ensure hours are full, not in the past, and within configured time windows, providing clearer error messages for invalid scheduling attempts.

internal/trainer/domain · high confidence

New internal common infrastructure for CQRS, API clients, and error handling

This change introduces a foundational set of internal utilities to support a Clean Architecture and CQRS (Command/Query Responsibility Segregation) pattern. It adds generated HTTP clients for the Trainer, Trainings, and Users APIs (using oapi-codegen v2.8.0) and generated gRPC stubs for the Trainer and Users services (using protoc-gen-go-grpc). To support the CQRS pattern, it provides generic command and query handler interfaces along with decorator middleware that automatically applies logging and metrics collection to all commands and queries. Additionally, it standardizes error handling by introducing a \SlugError\ type that allows domain errors to be mapped to specific HTTP status codes and error slugs, and adds a \.golangci.yml\ configuration to enforce code quality standards across the project.

internal/common · high confidence

Trainer service exposes HTTP and gRPC ports for hour management and availability queries

The trainer module now provides concrete server implementations for its external interfaces. The new HTTP server (http.go) exposes endpoints to retrieve a trainer's available hours within a date range, and to make specific hours available or unavailable, enforcing that only users with the 'trainer' role can perform the latter actions. A new gRPC server (grpc.go) implements corresponding methods for scheduling, canceling, and checking hour availability, utilizing the standard google.protobuf.Empty type for command responses. These ports are wired to the application's CQRS layer, routing HTTP/gRPC requests to specific Commands (MakeHoursAvailable, MakeHoursUnavailable, ScheduleTraining, CancelTraining) and Queries (HourAvailability, TrainerAvailableHours).

internal/trainer/ports · high confidence

Removals

Removal of legacy linting and OpenAPI code-generation scripts

The repository has removed the \scripts/lint.sh\ and \scripts/openapi-js.sh\ shell scripts. This eliminates the previous mechanism for running \go vet\ on individual services and generating JavaScript client code from OpenAPI specifications, indicating a shift in how code quality checks and client generation are handled within the project.

scripts · high confidence

Behavioural changes

API updates: new reschedule request endpoint and gRPC service simplification

The API now exposes a new PUT /trainings/{trainingUUID}/request-reschedule endpoint, allowing users to request a change to their training time. In the gRPC layer, the custom EmptyResponse message has been replaced with the standard google.protobuf.Empty across the Trainer and Users services, and the TrainerService has been refactored to expose distinct methods for scheduling, canceling, and making hours available. Additionally, the userUuid field in the OpenAPI schema is no longer validated as a UUID, reflecting that it stores the auth provider's user ID.

api · high confidence

Refactored development environment to support multi-service architecture with MySQL and gRPC

The project has transitioned from a single-service setup to a multi-service architecture (trainer, trainings, users) with distinct HTTP and gRPC endpoints, replacing the legacy Makefile with a Taskfile for automated code generation (OpenAPI, gRPC) and linting. The local development environment now includes a MySQL database alongside the existing Firestore emulator, requiring new environment variables for database credentials. Additionally, gRPC code generation has been updated to use the separate protoc-gen-go-grpc plugin, and Docker Compose configurations have been adjusted to support multiple service instances, caching, and new infrastructure services.

(repo-wide) · high confidence

Trainer service refactored to Clean Architecture with CQRS

The trainer service has been restructured to follow Clean Architecture and Domain-Driven Design principles, introducing a Command Query Responsibility Segregation (CQRS) pattern. Application logic is now organized into distinct command handlers (for actions like scheduling, canceling, and updating hour availability) and query handlers (for retrieving availability data), supported by a new linter configuration and component tests to ensure stability.

internal/trainer · high confidence

Trainings service adopts Clean Architecture with CQRS and Firestore persistence

The internal/trainings module has been restructured to follow Clean Architecture principles, introducing a Command/Query (CQRS) separation for handling business logic. Users can now schedule, cancel, and reschedule trainings through dedicated command handlers that enforce a 24-hour free cancellation window and manage credit balances via a gRPC user service. Rescheduling requires a proposal and approval workflow between trainers and attendees. Data persistence has shifted to a Firestore repository, and the service exposes HTTP endpoints via a new port layer, supported by comprehensive integration tests for the repository and unit tests for command handlers.

internal/trainings · high confidence

Updated Go base image and refined development watch patterns

The Docker development environment now uses the golang:1.25 base image instead of 1.14, and installs the reflex tool via Go modules rather than \go get\. The development watch configuration has been updated to monitor specific service directories (\common\ and \$SERVICE\) and Go/mod files, replacing the previous broad pattern. Additionally, the startup process now uses a new entrypoint script that substitutes the service name in the configuration before launching reflex, and the start script explicitly changes into the service directory before running the application.

docker/app · high confidence

Updated web container to use Node 24 and Yarn

The web container now runs on Node 24 (Alpine) instead of Node 13.11.0, requiring the NODE\_OPTIONS=--openssl-legacy-provider environment variable to support legacy hashing algorithms used by webpack 4. Additionally, the startup script has been updated to use Yarn for dependency installation and service execution, and the script permissions have been corrected to ensure it is executable.

docker/web · high confidence

Users service now tracks last login IP and exposes current user details via HTTP

The internal users service has been updated to store and retrieve the user's last known IP address, which is automatically recorded whenever the \GET /users/current\ HTTP endpoint is called. This change introduces a new \LastIP\ field in the user model and adds an \UpdateLastIP\ database operation in Firestore. Additionally, the service now provides a new HTTP endpoint that returns the authenticated user's display name, role, and training balance, leveraging the existing gRPC infrastructure for balance queries while adding a dedicated HTTP interface for user profile retrieval.

internal/users · high confidence

Dependencies

Initial Go module setup with Go 1.25 and multi-module workspace

The project initializes its Go dependency management by introducing a root \go.mod\ and \go.work\ file, setting the language version to 1.25.0 and configuring a multi-module workspace that includes the \internal/common\, \internal/trainer\, \internal/trainings\, \internal/users\, and \tools/c4\ sub-modules. The dependency graph includes core libraries such as \go-chi/chi/v5\ for HTTP routing, \go-sql-driver/mysql\ for database access, \oapi-codegen\ for OpenAPI code generation, and \google.golang.org/grpc\ for gRPC communication, alongside testing tools like \stretchr/testify\ and \onsi/ginkgo\.

(dependencies) · high confidence

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

How this codebase got here

This is the PUBLIC form of this artifact. Findings are listed in full, but the details of SECURITY findings — which rule fired, in which file, on which line, and how to fix it — are deliberately withheld, and any secret-scanner results are excluded entirely. Where detail is absent here it was REMOVED FOR PUBLICATION; it is not missing from the analysis. The complete artifact is available from the repository owner.

Score

  • CAI 50 → 64 (+13.8)
  • Rubric changed (rubric-2026.08.18 → rubric-2026.09.15) — scores are not directly comparable.

Lenses

  • Code Health 99 → 98 (-0.9)
  • Architecture 70 → 78 (+8.0)
  • Maturity 67 → 69 (+2.8)
  • Readiness 34 → 58 (+24.1)
  • Security 93 → 71 (-22.4)
  • Domain Modelling 100 → 100 (+0.0)
  • Accessibility 51 → 63 (+12.1)

Resolved (12)

  • Coverage not included — suite not readable by the collector
  • Dependency hygiene not measured — dependency manifest found but not parsed for hygiene
  • Duplicated block (11 lines × 2) (internal/common/client/grpc.go)
  • Duplicated block (12 lines × 2) (internal/trainings/ports/http.go)
  • Duplicated block (16 lines × 2) (internal/trainer/ports/http.go)
  • Duplicated block (7 lines × 2) (internal/common/server/http.go)
  • Medium: security finding (details withheld)
  • No exposed public API
  • OSV Dependency Vulnerabilities not included (check did not complete)
  • Off-boarding risk: anonymized user #1
  • Test reliability not included
  • main.createFirebaseUsers (cognitive 19) (internal/users/fixtures.go)

New (162)

  • Critical CVE: [GHSA redacted] (web/package-lock.json)
  • Critical CVE: [GHSA redacted] (web/package-lock.json)
  • Critical CVE: [GHSA redacted] (web/package-lock.json)
  • Critical CVE: [GHSA redacted] (web/package-lock.json)
  • Critical CVE: [GHSA redacted] (web/package-lock.json)
  • Critical CVE: [GHSA redacted] (web/package-lock.json)
  • Critical CVE: [GHSA redacted] (web/package-lock.json)
  • Critical CVE: [GHSA redacted] (web/package-lock.json)
  • Critical CVE: [GHSA redacted] (web/package-lock.json)
  • Critical CVE: [GHSA redacted] (go.mod)
  • Critical CVE: [GHSA redacted] (web/package-lock.json)
  • Critical CVE: [GHSA redacted] (web/package-lock.json)
  • Critical CVE: [GHSA redacted] (web/package-lock.json)
  • Critical CVE: [GHSA redacted] (web/package-lock.json)
  • Critical vulnerability: [GHSA redacted] (web/package-lock.json)
  • Deprecated module: github.com/golang/protobuf
  • Deprecated module: github.com/golang/protobuf
  • Deprecated module: github.com/golang/protobuf
  • Documentation: no contributor guidance (README.md)
  • Documentation: no installation or build instructions (README.md)
  • …and 142 more

Changes since last survey

  • 4 commits — 3 feature/other, 1 fixes

By area

  • (root) — 1 commit
  • .github/login.png — 1 commit
  • internal/common — 1 commit
  • terraform/Taskfile.yml — 1 commit

Notable commits

  • fix: Minor deploy fixes
  • change: Update dev environment (#81)
  • change: Update screenshots
  • change: Updates to terraform

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

Survey your own repository

ThreeDotsLabs/wild-workouts-go-ddd-example 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.

About this page

  • The score is its most recent published measurement, taken on 21 September 2026 at a pinned commit. It is not a live figure and does not change until the project is measured again.
  • Measured at commit 8ecfcdf05b1462c4757bd2dcac9086c78e9f7791 — the exact code this score is about.
  • Scored under rubric-2026.09.15 — the same rubric and the same method as every other entry in this index.
  • Measured by watchdog.canine.dev using codehealth-analyzer preprod-28e75b8e3254.