✨ Initial project setup with basic scaffolding, build tools, and agent guidelines.

AGENTS.md

@@ -0,0 +1,43 @@
+# Agent Guidelines for waiterr
+
+This document outlines the conventions and commands for agents operating within the `waiterr` Go project.
+
+## Build/Lint/Test Commands
+
+- **Lint:** `task lint`
+- **Test All:** `task test`
+- **Test Single File:** `go test -run <TestName> <path/to/file_test.go>` (e.g., `go test -run TestNewHappy ./ezcache_test.go`)
+- **Format:** `task fmt`
+
+## Code Style Guidelines
+
+- **Module**: `codeberg.org/danjones000/waiterr`
+- **Go version**: 1.24.9
+- **Imports:** Group standard library imports separately from third-party imports.
+- **Formatting:** Adhere to `go fmt` standards.
+- **Naming Conventions:**
+    - Variables: `camelCase`
+    - Functions/Methods: `CamelCase` (exported), `camelCase` (unexported)
+    - Packages: `lowercase`
+- **Error Handling:** Return errors explicitly. Check errors immediately after a function call that returns an error.
+- **Linter Rules:** Refer to `.golangci.yaml` for detailed linting rules.
+- **Testing**: Use `github.com/nalgeon/be`
+
+## Git Commit Guidelines
+- **Format**: Prepend commit messages with a gitmoji emoji (see https://gitmoji.dev)
+- **Style**: Write detailed commit messages that explain what changed and why
+- **Examples**: `✨ Add JSON export functionality for log entries`, `🐛 Fix date parsing for RFC3339 timestamps`, `📝 Update README with configuration examples`
+
+## Git Flow Workflow
+- **Main branches**: `stable` (production-ready), `develop` (integration branch)
+- **Development**: Always commit new features/fixes to `develop` branch or appropriate feature branches
+- **Branch prefixes**:
+  - `feat/feature-name` - New features, merge to `develop` when complete
+  - `bug/bug-name` - Bug fixes (non-urgent), merge to `develop` when complete
+  - `rel/version` - Release preparation branches, merge to `stable` and then **also** merge `stable` back to `develop`
+  - `hot/version` - Hotfixes for production issues follow same merge rules as releases
+- **Version tags**: Prefix all version tags with `v` (e.g., `v1.0.2`, `v0.0.6`)
+- **Releases**: Update CHANGELOG.md with a summary of changes for each new version
+- **Never commit directly to** `stable` branch (only merge from `rel/` or `hot/` branches)
+- After merging to `stable`, always merge it back to `develop`
+- **Before starting work**: Ensure you're on `develop` branch or create an appropriate feature branch from it