Solver-LNK Build Order Generator

This skill helps you work with the solver-lnk project, a Go-based simulation solver for the Lords & Knights game that generates optimized build orders for castle development and unit training.

What This Skill Does

Project Architecture

The solver uses a simulation-based approach with event-driven resource accumulation:

Key Implementation Details

Resource System

Build Queue System

Technology Prerequisites

Development Workflow

Initial Setup

```bash

Clone with submodules (proto-lnk)

git clone --recursive [email protected]:Napolitain/solver-lnk.git

Install protoc plugins

go install google.golang.org/protobuf/cmd/protoc-gen-go@latest

go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@latest

```

Daily Commands

```bash

Regenerate protobuf code (after proto-lnk changes)

go generate ./...

Build binaries

go build ./cmd/server

go build ./cmd/castle

go build ./cmd/units

Lint (required before commit)

golangci-lint run

Run tests

go test ./... # All tests (includes fuzz corpus)

go test -race ./... # With race detection

go test -cover ./... # With coverage

Run server

./server # Starts gRPC on port 50051

```

Testing Strategy

**Standard Tests:**

```bash

go test ./... # Run all tests

./scripts/test-all.sh # Full test suite

```

**Fuzz Testing:**

Note: `go test ./...` only runs fuzz seed corpus (regression). To actively fuzz:

```bash

Castle solver fuzzing

go test -fuzz=FuzzSolverDeterminism -fuzztime=30s ./internal/solver/castle

go test -fuzz=FuzzSolverResources -fuzztime=30s ./internal/solver/castle

go test -fuzz=FuzzSolverBuildingLevels -fuzztime=30s ./internal/solver/castle

Units solver fuzzing

go test -fuzz=FuzzSolverConstraints -fuzztime=30s ./internal/solver/units

go test -fuzz=FuzzUnitThroughput -fuzztime=30s ./internal/solver/units

go test -fuzz=FuzzUnitResourceCosts -fuzztime=30s ./internal/solver/units

```

**Pre-Commit Check:**

```bash

golangci-lint run && go test -race ./...

```

Coding Conventions

Timing Representation

Since this is a build order solver, use step-based notation internally:

✅ **Correct:**

❌ **Avoid:**

**Exception:** Hours are acceptable for user-facing display, test logging, and documentation.

Go Best Practices

Project Structure

```

solver-lnk/

├── cmd/

│ ├── castle/ # Castle CLI

│ ├── server/ # gRPC server

│ └── units/ # Units CLI

├── internal/

│ ├── converter/ # Proto ↔ internal models

│ ├── loader/ # JSON data loaders

│ ├── models/ # Domain models

│ └── solver/

│ ├── castle/ # Castle solver + tests

│ └── units/ # Units solver + tests

├── proto/ # Submodule (proto-lnk)

├── data/ # Game data JSON

└── go.mod

```

gRPC API

The server exposes `CastleSolverService`:

**Input:** Current castle state (buildings, resources, levels)

**Output:** Recommended next action + full build plan

```protobuf

service CastleSolverService {

rpc Solve(SolveRequest) returns (SolveResponse);

}

```

CI/CD Pipeline

GitHub Actions workflow on push/PR:

1. Checkout with submodules

2. Install protoc + plugins

3. Generate protobuf code

4. Lint with golangci-lint

5. Run race-detected tests

6. Generate coverage report

7. Run all fuzz tests (20s each)

8. Upload to Codecov

Philosophy

This project favors **state-of-the-art, edge tooling** for 2025+:

Important Notes

1. **Submodule**: The `proto/` directory is a Git submodule (`proto-lnk`). Always clone with `--recursive`.

2. **Food Mechanic**: Farm provides absolute capacity, not production rate.

3. **Dual Queues**: Building and research can progress simultaneously.

4. **Determinism**: All solver outputs are deterministic and fuzz-tested.

5. **Modern Go**: Uses Go 1.23+ features, targeting 1.25 idioms.

Constraints