Haraj-backend/hex-monscape

A new DynamoDB storage layer for battle data has been introduced, providing persistence for game states, partner and enemy monsters, and damage history. The implementation includes model definitions, storage logic for saving and retrieving battles, and corresponding tests using a local DynamoDB instance.

internal/driven/storage/dynamodb/battlestrg · high confidence

The codebase now includes a new DynamoDB storage adapter for game data, introducing \model.go\ and \storage.go\ to handle persistence of \entity.Game\ objects. The implementation provides \GetGame\ and \SaveGame\ methods that marshal and unmarshal game records to/from DynamoDB, along with a \Config\ struct for dependency injection. A corresponding test file (\storage\_test.go\) validates the save and retrieve operations using a local DynamoDB instance.

internal/driven/storage/dynamodb/gamestrg · high confidence

The MySQL adapter now supports saving and retrieving battle state. The \battlestrg\ package introduces a new \Storage\ implementation that persists battle data to a \battle\ table, mapping partner and enemy monster stats, health, and damage. This includes a \GetBattle\ method to retrieve the current state and a \SaveBattle\ method to persist updates, backed by corresponding integration tests.

internal/driven/storage/mysql/battlestrg · high confidence

Introduced a new MySQL storage implementation for game data, including the GameRow model, the Storage struct with GetGame and SaveGame methods, and corresponding integration tests. This enables persistent storage and retrieval of game state in the MySQL database.

internal/driven/storage/mysql/gamestrg · high confidence

A new MySQL storage implementation has been added to handle retrieving monster entities, specifically supporting queries for available partners and possible enemies. The implementation includes database interaction logic to fetch monster data based on their role (partner or enemy) and provides a test suite to verify the correct retrieval of these entities from the MySQL database.

internal/driven/storage/mysql/monstrg · high confidence

Introduces new core entities for the game logic: a Monster entity with battle stats and damage calculation, a Game entity that tracks player progress and scenarios, and a Battle entity that manages turn-based combat states and actions like attacking or surrendering. Includes comprehensive test coverage for these new components.

internal/core/entity · high confidence

A new in-memory storage implementation for monsters has been introduced in the \internal/driven/storage/memory/monstrg\ package. This adapter loads monster data from a JSON configuration, parsing it into a \monsterRow\ struct (which maps JSON fields like \battle\_stats\ and \avatar\_url\ to the core \entity.Monster\ model). The storage provides methods to retrieve available partners, specific partners by ID, and all possible enemies, supporting the application's battle and partner selection features with an in-memory data store.

internal/driven/storage/memory/monstrg · high confidence

A new local development stack has been introduced for the REST/DynamoDB integration, allowing developers to run the full application locally using Docker Compose. This includes a LocalStack container for DynamoDB, a server container configured to use DynamoDB storage, and a client container. The setup is pre-seeded with initial monster data (Yellowleg, Bluebub, Grumpy, Vegiewee, Snekworm) via a batch-write script, ensuring the local environment starts with a consistent state. The server and client services are configured to depend on the LocalStack health check, ensuring the database is ready before the application starts.

deploy/local/run/rest-dynamodb · high confidence

Introduced a new local deployment configuration for the REST MySQL service, including a Docker Compose setup that orchestrates MySQL, the server, and the client. The configuration ensures the server starts only after MySQL is healthy, and the client starts only after both MySQL and the server are healthy, preventing confusion during local development. Additionally, a SQL data file was added to populate the database with initial monster records.

deploy/local/run/rest-mysql · high confidence

New shell scripts and SQL schemas are added to the local deployment configuration. A script is introduced to create DynamoDB tables for monsters, games, and battles, while a wait utility is added to check LocalStack health. Additionally, a MySQL schema file is added defining the monster, game, and battle tables, establishing the local database structure for these entities.

deploy/local/shared · high confidence

Introduced a new Go entry point for the online game demo, which initializes AWS Lambda and API Gateway integrations along with DynamoDB storage for battles, games, and monsters. The change includes the main application logic that configures local and serverless execution modes, and adds a README explaining the deployment workflow and demo URL.

cmd/lambda · high confidence

New Dockerfiles have been introduced for the Lambda package, providing separate build configurations for local development and production deployment. The production image (Dockerfile) targets the AWS Lambda Go runtime, while the local development image (Dockerfile.local) uses Alpine Linux, enabling local testing and deployment workflows for the Lambda function.

build/package/lambda · high confidence

The Play service was introduced to handle core game logic, including initiating new games, retrieving game instances, and selecting available partners. The implementation defines a Service interface with methods for GetAvailablePartners, NewGame, and GetGame, supported by storage interfaces for game and partner data. This change adds the service implementation and its corresponding test suite to ensure correct business logic and error handling for game-related operations.

internal/core/service/play · high confidence

Added a new DynamoDB storage implementation for the 'monstrg' (monster) domain, introducing model and storage layers that handle persistence and retrieval of monster entities. The storage layer provides methods to retrieve available partners, all possible enemies (by scanning the entire table), and individual partners by ID, ensuring consistent behavior with other storage implementations.

internal/driven/storage/dynamodb/monstrg · medium confidence

The web client for the Hex Monscape game has been introduced, built with Vue 3 and Vite. This update adds the full client-side application, including the main entry point, routing configuration, and a Pinia store for managing game and battle state. The UI features a welcome screen, a new game flow for selecting a player name and partner, a lounge screen, and a battle scene with health bars and control buttons. The client communicates with the server via a dedicated HTTP client and uses Tailwind CSS for styling, including responsive adjustments for mobile devices.

cmd/client · high confidence

A new Battle service has been added to the core domain, providing operations to start a battle, retrieve the current state, decide turns, execute attacks, and handle surrender. The service manages the lifecycle of a battle, including validating game and battle states, handling enemy attacks, and persisting battle data. This introduces the core logic for the battle system, supported by storage interfaces for games, battles, and monsters.

internal/core/service/battle · high confidence

Added model definitions for the MySQL storage layer, including the MonsterRow struct and conversion helpers that map database rows to the core entity.Monster type. Also added test utilities in tests.go, providing a helper to create a test SQL client and a function to insert monster rows into the database for testing purposes.

internal/driven/storage/mysql/shared · high confidence

A new REST API layer has been added to serve the web client and expose game and battle endpoints. The API provides endpoints for health checks, partner selection, game creation, game details, scenario retrieval, and battle operations (start, info, turn, attack, surrender). It includes structured error handling for common states like not found or invalid battle states, and supports serving static web assets.

internal/driver · high confidence

The DynamoDB storage implementation now uses a dedicated data structure (MonsterRow) for storing and retrieving monster records, separating the database representation from the core entity model. This change ensures the DynamoDB adapter has its own data structure for storing records, aligning its behavior with other storage implementations.

internal/driven/storage/dynamodb/shared · high confidence

The in-memory storage implementations for battles and games now return nil when a requested record is not found, rather than returning an error or a zero-value object. This change ensures that the storage layer correctly signals the absence of data, which should prevent downstream components from encountering unexpected nil-pointer panics or invalid state when querying for non-existent battles or games.

internal/driven/storage/memory/battlestrg · high confidence

The server's initialization logic has been restructured to support multiple storage backends—memory, DynamoDB, and MySQL—selected via configuration. This change introduces a new configuration structure that allows users to specify the storage type and provide the necessary connection details (e.g., table names, endpoints, or file paths) for each backend, enabling flexible deployment options for game state and battle data.

cmd/server · high confidence

A new helper function, NewTestMonster, has been added to the testutil package. This utility generates a random Monster entity with randomized battle stats (Health, MaxHealth, Attack, Defense, Speed) and a unique ID, streamlining the creation of test data for MySQL storage implementations.

internal/core/testutil · high confidence

The project now includes a \package.json\ for the client-side application, establishing a Vue 3, Pinia, and Vite-based frontend environment with specific versions for dependencies like \@headlessui/vue\ and \vue-router\. Simultaneously, a \go.mod\ file is introduced to manage the Go backend dependencies, including \go-chi\, \sqlx\, and AWS SDK, effectively setting up the build and dependency resolution for both the client and server sides of the application.

(dependencies) · high confidence

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

• CAI 46 → 41 (-5.0)
• Rubric changed (rubric-2026.08.18 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 85 → 70 (-15.0)
• Architecture 90 → 88 (-2.1)
• Maturity 70 → 70 (+0.0)
• Readiness 30 → 30 (+0.1)
• Security 51 → 46 (-4.6)
• Domain Modelling 100 → 44 (-56.1)
• Accessibility 51 → 51 (+0.0)

• Coverage not included — suite not readable by the collector
• Dependency hygiene not measured — dependency manifest found but not parsed for hygiene
• Duplicated block (13 lines × 2) (internal/driven/storage/dynamodb/battlestrg/storage.go)
• High CVE: [GHSA redacted] (cmd/client/yarn.lock)
• High CVE: [GHSA redacted] (cmd/client/yarn.lock)
• High CVE: [GHSA redacted] (cmd/client/yarn.lock)
• High CVE: [GHSA redacted] (cmd/client/yarn.lock)
• High CVE: [GHSA redacted] (cmd/client/yarn.lock)
• High CVE: [GHSA redacted] (cmd/client/yarn.lock)
• High CVE: [GHSA redacted] (cmd/client/yarn.lock)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• LLM evaluation failed
• …and 11 more

• Dependency pinned to a stale untagged commit: gopkg.in/validator.v2
• Deprecated module: github.com/aws/aws-sdk-go
• Documentation: no installation or build instructions (README.md)
• Documentation: no usage examples (README.md)
• Duplicated block (11 lines × 2) (internal/driven/storage/dynamodb/battlestrg/storage.go)
• Duplicated block (13 lines × 2) (internal/driven/storage/dynamodb/battlestrg/storage.go)
• Duplicated block (8 lines × 2) (internal/driven/storage/mysql/battlestrg/storage.go)
• High CVE: [GHSA redacted] (cmd/client/yarn.lock)
• High CVE: [GHSA redacted] (cmd/client/yarn.lock)
• High CVE: [GHSA redacted] (cmd/client/yarn.lock)
• High CVE: [GHSA redacted] (cmd/client/yarn.lock)
• High CVE: [GHSA redacted] (cmd/client/yarn.lock)
• High CVE: [GHSA redacted] (cmd/client/yarn.lock)
• High CVE: [GHSA redacted] (cmd/client/yarn.lock)
• High CVE: [GHSA redacted] (cmd/client/yarn.lock)
• High CVE: [GHSA redacted] (cmd/client/yarn.lock)
• High IaC: WD-DOCKER-0013 (build/package/lambda/Dockerfile.local)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• …and 56 more

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

Haraj-backend/hex-monscape 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.