chore: update AI-related files

Signed-off-by: Ilya Lesikov <ilya@lesikov.com>

Author: ilya-lesikov

AGENTS.md

@@ -0,0 +1,77 @@
+# Repository Guidelines
+
+All rules in this document are requirements — not suggestions. ALWAYS follow them.
+
+Wormatter is a DST-based Go source code formatter. Highly opinionated, but very comprehensive. Gofumpt and gci built-in.
+
+## Highest-priority rule (MANDATORY)
+
+- NEVER add comments unless they document a non-obvious public API or explain genuinely non-obvious logic. NEVER add comments that restate what the code does, repeat the field/function name, describe obvious error handling, or act as section separators. When in doubt, don't comment.
+- ALWAYS use `task` commands for build/test/lint/format — NEVER raw `go build`, `go test`, `go vet`, `go fmt`, or `golangci-lint` directly.
+- ALWAYS verify, don't assume — check the actual state before making changes.
+- ALWAYS start with the simplest possible solution. If it works, stop. Add complexity only when justified by a concrete, current requirement — NEVER for hypothetical future needs.
+- NEVER leave TODOs, stubs, or partial implementations.
+- ALWAYS stay within the scope of what was asked. When asked to update a plan — only update the plan, don't change code. When asked to brainstorm/discuss — only discuss, don't write code. When asked to do X — do X and nothing else. NEVER make unsolicited changes.
+
+## Code style
+
+### Design (MANDATORY)
+
+> NEVER edit rules below directly. Instead ALWAYS update [CODESTYLE.md](CODESTYLE.md) and ask AI to sync the section below with it.
+
+- ALWAYS prefer stupid and simple over abstract and extendable.
+- ALWAYS prefer a bit of duplication over complex abstractions.
+- ALWAYS prefer clarity over brevity in names.
+- ALWAYS minimize interfaces, generics, embedding.
+- ALWAYS prefer fewer types. Prefer no types over few. Prefer data types over types with behavior.
+- ALWAYS prefer functions over methods. ALWAYS prefer public fields over getters/setters.
+- ALWAYS keep everything private/internal as much as possible.
+- ALWAYS validate early, validate a lot. ALWAYS keep APIs stupid and minimal.
+- NEVER prefer global state. ALWAYS prefer simplicity over micro-optimizations.
+- ALWAYS use libraries for complex things instead of reinventing the wheel.
+- NEVER add comments unless they document a non-obvious public API or explain genuinely non-obvious logic. NEVER add obvious/redundant comments, NEVER add comments restating what code does. When in doubt, don't comment.
+
+### Conventions (MANDATORY)
+
+> NEVER edit rules below directly. Instead ALWAYS update [CODESTYLE.md](CODESTYLE.md) and ask AI to sync the section below with it.
+
+- All arguments of a public function are required — passing nil not allowed.
+- Optional arguments via `<FunctionName>Options` as the last argument. NEVER use functional options.
+- Use guard clauses and early returns to keep the happy path unindented.
+- Use `samber/lo` helpers: `lo.Filter`, `lo.Find`, `lo.Map`, `lo.Contains`, `lo.Ternary`, `lo.ToPtr`, `lo.Must`, etc.
+- Constructors: `New<TypeName>[...]()`. No network/filesystem calls in constructors.
+- Interfaces: ALWAYS add `var _ Animal = (*Dog)(nil)` compile-time check.
+- Constants: avoid `iota`. Prefix enum constants with type name: `LogLevelDebug LogLevel = "debug"`.
+- Errors: ALWAYS wrap with context: `fmt.Errorf("read config: %w", err)`. Describe what is being done, not what failed. Panic on programmer errors. Prefer one-line `if err := ...; err != nil`.
+
+### Go standard guidelines (MANDATORY)
+
+Follow [Effective Go](https://go.dev/doc/effective_go) and [Go Code Review Comments](https://go.dev/wiki/CodeReviewComments). Commonly violated rules:
+
+- NEVER use `this`/`self` as receiver names. Use 1-2 letter names, consistent across methods.
+- NEVER discard errors with `_`. Indent error flow, not happy path.
+- NEVER use dot imports.
+- NEVER use named returns or naked returns.
+
+## Commands (MANDATORY)
+
+ALWAYS use these `task` commands. NEVER use raw `go build`, `go test`, `go fmt`, `go vet`, or `golangci-lint` directly. Pass extra args after `--` to forward them to the underlying command (e.g., `task test -- -run TestMyFunc`).
+
+- NEVER `go build` → ALWAYS `task build`. Builds binary to `./bin/`.
+- NEVER `go test` → ALWAYS `task test`. Runs all tests.
+- `task clean` — clean build artifacts.
+- `task install` — install binary to `$GOPATH/bin`.
+
+## Testing (MANDATORY)
+
+- ALWAYS use `testify` (`assert`, `require`) when writing new tests.
+- When writing tests as an AI agent → ALWAYS name the file `*_ai_test.go`, add `//go:build ai_tests` build tag, prefix test functions with `TestAI_`.
+- ALWAYS place tests alongside source files, not in a separate directory.
+- Test helpers go in `helpers_test.go` (or `helpers_ai_test.go` for AI-written helpers).
+- Test fixtures go in `testdata/` subdirectory next to the tests.
+
+## PR review guidelines (MANDATORY)
+
+- NEVER add new external dependencies without flagging to the user first.
+- NEVER introduce breaking user-facing changes (not API changes) unless they are hidden behind a feature flag. Flag to the user first.
+- NEVER introduce changes that may compromise security. Flag to the user first.

CODESTYLE.md

@@ -0,0 +1,57 @@
+## Design
+
+* Prefer stupid and simple over abstract and extendable.
+* Prefer a bit of duplication over complex abstractions.
+* Prefer clarity over brevity in variable, function and type names.
+* Minimize usage of interfaces, generics, embedding.
+* Prefer few classes over many.
+* Prefer no classes over few.
+* Prefer data classes over regular classes.
+* Prefer functions over methods.
+* Prefer public fields over getters/setters.
+* Keep everything private/internal as much as possible.
+* Validate early, validate a lot.
+* Keep APIs stupid and minimal.
+* Avoid global state.
+* Prefer simplicity over micro-optimizations.
+* For complex things use libraries instead of reinventing the wheel.
+* Document only non-obvious public APIs or complex/weird code.
+
+## Conventions
+
+### Functions/methods
+
+* All arguments of a **public** function are required: passing nil not allowed.
+* Optional arguments of a **public** function are provided via `<MyFunctionName>Options` as the last argument.
+* Avoid functional options pattern.
+* Use guard clauses and early returns/continues to keep the happy path unindented.
+* Use `samber/lo` helpers (if nothing similar in the standard lib): `lo.Filter`, `lo.Find`, `lo.Map`, `lo.Contains`, `lo.Ternary`, `lo.ToPtr`, `lo.Must`, etc.
+
+### Constructors
+
+* Constructors are optional.
+* Should be named `New<TypeName>[...]`, e.g. `NewResource()` and `NewResourceFromManifest()`.
+* No network/filesystem calls or resource-intensive operations. Do it somewhere higher, like in `BuildResources()`.
+
+### Interfaces
+
+* Always add a compile-time check for each implementation, e.g. `var _ Animal = (*Dog)(nil)`.
+
+### Constants
+
+* Avoid `iota`.
+* Prefix the enum-like constant name with the type name, e.g. `LogLevelDebug LogLevel = "debug"`.
+
+### Errors
+
+* Always wrap errors with additional context using `fmt.Errorf("...: %w", err)`.
+* On programmer errors prefer panics, e.g. on an unexpected case in a switch.
+* Do one-line `if err := myfunc(); err != nil` wherever possible, generally prefer one-line handling.
+* When wrapping errors with fmt.Errorf, describe what is being done, not what failed, e.g. `fmt.Errorf("read config file: %w", err)` instead of `fmt.Errorf("cannot read config file: %w", err)`.
+
+## Go standard guidelines
+
+Follow these two guides:
+
+* [Effective Go](https://go.dev/doc/effective_go)
+* [Go Code Review Comments](https://go.dev/wiki/CodeReviewComments)

OPENCODE.md

@@ -0,0 +1,31 @@
+## Exploring the codebase (MANDATORY)
+
+These are NOT suggestions — they are requirements.
+
+- ALWAYS use **LSP** (`goToDefinition`, `findReferences`, `goToImplementation`, `hover`, `incomingCalls`/`outgoingCalls`, `documentSymbol`, `workspaceSymbol`) for navigating code. NEVER use `grep` for finding definitions, references, implementations, or callers — LSP is precise, `grep` is a guess.
+  - To find a symbol's definition when you have a call site: use `goToDefinition`.
+  - To find a symbol's definition without a call site: use `workspaceSymbol`. If it returns no results, fall back to `grep`.
+  - To understand a file's structure: use `documentSymbol`.
+  - To find interface implementations: use `goToImplementation`.
+  - To check types or godoc: use `hover`.
+- ALWAYS use **CodeAlive MCP** (`codealive_codebase_search`, `codealive_codebase_consultant`) for semantic/intent-based code search. Call `codealive_get_data_sources` first. NEVER substitute with `grep` when the query is about intent or behavior.
+- Only fall back to `grep`/`glob` for simple literal pattern matching (specific strings, config keys, error messages).
+- Only use `task` subagent (`explore`/`general`) for broad codebase exploration or multi-step investigation when the above tools are insufficient.
+
+## External documentation (MANDATORY)
+
+These are NOT suggestions — they are requirements.
+
+- ALWAYS use **LSP** `hover` to look up type signatures and godoc for any symbol (including external dependencies).
+- Use **Context7 MCP** (`context7_resolve-library-id` + `context7_query-docs`) for library documentation, guides, or examples.
+- Use **codesearch** (Exa) for finding code examples, API references, or documentation for libraries and tools.
+- Use **websearch** for current information, recent changes, or topics beyond training data.
+- Use **webfetch** to retrieve content from a specific URL (docs page, issue, PR).
+- NEVER guess at APIs — look them up.
+
+## Verifying changes (MANDATORY)
+
+ALWAYS verify after making changes:
+
+- ALWAYS run `task build` — verify it compiles.
+- ALWAYS run `task test` — verify tests pass.

opencode.json

@@ -0,0 +1,7 @@
+{
+  "$schema": "https://opencode.ai/config.json",
+  "instructions": [
+    "OPENCODE.md",
+    "AGENTS.md"
+  ]
+}