# Repository Guidelines

## Project Structure & Module Organization

Skylinks is a compact Go 1.23 service built on Skykit. `main.go` embeds everything under `views/` and registers controllers. HTTP behavior lives in `controllers/`: `links.go` owns the landing page and link-creation workflow, while `redirect.go` resolves short codes. Persistence code resides in `models/`, where `database.go` wires a shared manager and `link.go` enforces validation, sanitization, and time zone helpers. Keep any new assets or templates in `views/` so they are bundled by the `//go:embed` directive.

## Build, Test, and Development Commands

- `go run .` starts the local server on http://localhost:5000 with embedded templates.

- `go build -o bin/skylinks` produces a binary suitable for Docker or systemd units.

- `go test ./...` runs all Go tests (table-driven unit tests belong next to the code under test).

- `docker build -t skylinks .` mirrors the production image defined in `Dockerfile`.

## Coding Style & Naming Conventions

Use `go fmt ./...` before committing; gofmt’s tab indentation and standard import ordering are the baseline. Keep functions small and focused, prefer descriptive names (`LinksController`, `CreateLink`) and lowerCamelCase for locals. Follow GoDoc conventions for exported types, and guard user input exactly as `models/link.go` does (trim, lowercase, explicit allowlists). Favor explicit HTTP routes (`http.HandleFunc("POST /links", ...)`) when adding endpoints.

## Testing Guidelines

Write tests with the standard `testing` package; colocate `*_test.go` files with their subjects (e.g., `models/link_test.go`). Use fixtures that cover success and validation error paths, and target helper methods like `sanitizeShortCode`, `generateAvailableShortCode`, and controller handlers. Aim for meaningful branch coverage on input sanitization and redirect logic. Run `go test ./... -race` before opening a PR if concurrency is touched.

## Commit & Pull Request Guidelines

History mixes concise imperative commits (`fix: store original target url`, `CLEANUP`), so keep subject lines under 72 characters and describe the user-facing change or module touched. Reference issue IDs when available. Each PR should explain the problem, summarize the fix, note any schema or config changes, and include test evidence or manual verification steps (curl transcript, browser screenshot). Include reviewers who own the affected controller or model.