Skip to main content

Development Setup

This guide covers setting up a local development environment for contributing to Station.

Prerequisites

Optional

Clone and Build

Project Structure

Running Locally

Start the Server

Create a Test Environment

Run an Agent

Configuration

Default Paths

Configuration File

Create config.yaml:

Environment Variables

Starting Infrastructure

Jaeger (Distributed Tracing)

libsql (Optional Cloud Database)

For cloud database development:

IDE Setup

VS Code

Recommended extensions:
Settings for Go:

GoLand / IntelliJ

  1. Open the station/ directory as a Go project
  2. Enable “Go Modules integration”
  3. Configure GOROOT to Go 1.21+

Makefile Targets

Common Development Tasks

Adding a New CLI Command

  1. Create handler in cmd/main/handlers/<domain>/
  2. Register command in cmd/main/main.go
  3. Add tests in cmd/main/handlers/<domain>/*_test.go

Adding a New Service

  1. Create service in internal/services/<name>.go
  2. Define interface if needed
  3. Add to service registry if applicable
  4. Write tests in internal/services/<name>_test.go

Adding a New API Endpoint

  1. Add handler in internal/api/v1/<resource>.go
  2. Register route in internal/api/v1/routes.go
  3. Add tests in internal/api/v1/<resource>_test.go

Adding a New MCP Tool

  1. Add handler in internal/mcp/handlers/
  2. Register in internal/mcp/server.go
  3. Update tool discovery if needed

Debugging

Enable Debug Logging

Database Inspection

Tracing with Jaeger

  1. Start Jaeger (see above)
  2. Configure telemetry in config.yaml
  3. Run agents and view traces at http://localhost:16686

Station Lattice Development

Station Lattice enables multi-station mesh networking. This section covers development-specific workflows.

Running Lattice Locally

Key Lattice Directories

NATS Subject Conventions

Adding New Message Types

  1. Define the message struct in internal/lattice/messages.go:
  1. Add publisher function in appropriate file:

Testing Lattice Code

Common Gotchas

  1. Always close NATS connections - Use defer client.Close() to prevent resource leaks
  2. JetStream KV eventual consistency - Allow small delays when testing KV operations
  3. Port conflicts - Use unique ports in tests to avoid conflicts with running stations
  4. Heartbeat timing - Default heartbeat is 5s; tests may need shorter intervals

Next Steps

Architecture

Deep dive into system architecture

Testing

Running and writing tests