This project uses CursorRules to define coding standards, anti-patterns, and workflows. The full rules are located in the .cursor/rules/ directory.
The following are the Top 15 Universal Anti-Patterns from .cursor/rules/critical-rules-quick-reference.mdc. Avoid these at all costs.
❌ Bad: class Service { func get() { return repo.get() } } (>80% delegation)
✅ Good: Service coordinates multiple repos OR adds logic OR delete layer
general-llm-anti-patterns.mdc section 1.1
❌ Bad: actor Repo { func process() async { await MainActor.run { } } } (defeats isolation)
✅ Good: actor Repo { func process() async { /* actual async work */ } }
general-llm-anti-patterns.mdc section 1.2
❌ Bad: func method() { throw NotImplementedError() } or _ = expensiveOperation()
✅ Good: Implement, remove, or mark unavailable with explanation
general-llm-anti-patterns.mdc section 1.3
❌ Bad: Repository contains switch statements, state transitions, business calculations
✅ Good: Repository is pure CRUD, business logic in Domain layer
general-llm-anti-patterns.mdc section 1.4
❌ Bad: for item in items { await processItem(item) } (I/O in loop = O(N²))
✅ Good: Batch operations - fetch once, modify in-memory, save once
general-llm-anti-patterns.mdc section 2.1
❌ Bad: Multi-step search workaround when direct lookup API exists
✅ Good: Verify framework documentation, use official APIs
general-llm-anti-patterns.mdc section 4.1
❌ Bad: apiKey = "sk-live-1234567890abcdef" in source code
✅ Good: apiKey = process.env.API_KEY (environment variables)
general-llm-anti-patterns.mdc section 5.1
❌ Bad: database.query("SELECT * FROM users WHERE id = " + userInput)
✅ Good: Validate input, use parameterized queries
general-llm-anti-patterns.mdc section 5.2
❌ Bad: try { op() } catch { pass } (swallows errors)
✅ Good: Handle specific errors or explicitly propagate with context
general-llm-anti-patterns.mdc section 5.3
❌ Bad: Mock returns different types/behavior than real implementation
✅ Good: Mocks match real API signatures and behavior exactly
general-llm-anti-patterns.mdc section 6.1
❌ Bad: Comments dismissing warnings as "false positives" or "won't affect runtime"
✅ Good: Fix all warnings; if truly unfixable, document technical reason and escalate
general-llm-anti-patterns.mdc section 3.7
❌ Bad: "All code compiles with zero warnings" (without running build)
✅ Good: "Code changes complete. Build verification pending." OR show actual build output
general-llm-anti-patterns.mdc section 3.8
❌ Bad: "All tests pass" (without running tests)
✅ Good: "Code changes complete. Test verification pending." OR show actual test output
general-llm-anti-patterns.mdc section 3.9
❌ Bad: import suspicious_package (unverified package), importing plausible-sounding packages without checking
✅ Good: Verify package exists in registry, check maintainer, check download stats, verify owner
general-llm-anti-patterns.mdc section 4.2d
❌ Bad: Example code used verbatim without adaptation
✅ Good: Adapt examples to project patterns, verify examples match requirements
general-llm-anti-patterns.mdc section 4.4
This project utilizes Go and JavaScript/TypeScript. Refer to the following rules for detailed standards:
- Standards:
.cursor/rules/go-1-21-development-standards.mdc - Audit:
.cursor/rules/go-1-21-brutal-audit.mdc
- Standards:
.cursor/rules/javascript-3-development-standards.mdc - Audit:
.cursor/rules/javascript-3-brutal-audit.mdc
- Standards:
.cursor/rules/rust-development-standards.mdc - Audit:
.cursor/rules/rust-brutal-audit.mdc
- Dev Container: The project includes a
.devcontainerconfiguration. Used for a consistent environment. - Languages:
- Go: 1.22 or later.
- Node.js/TypeScript: Required for the extension.
- Directory Structure:
cli/: Go source code (main module).extension/: TypeScript source for the Cursor/VSCode extension.docs/: Project documentation.
- LLM backends: Default is Ollama (
provider/STET_PROVIDER). Optional OpenAI-compatible HTTP API (openai_base_url/STET_OPENAI_BASE_URL,max_completion_tokens/STET_MAX_COMPLETION_TOKENS). See README.md for a short user overview and docs/cli-extension-contract.md for the full configuration contract and precedence.
- CLI (Go):
cd cli go build ./... - Extension (TypeScript):
cd extension npm install npm run compile
Strict Coverage Requirements:
- 77% line coverage for the entire project.
- 72% minimum line coverage for every file.
- Run Tests:
- Go:
go test ./... -cover - Extension:
npm test(Vitest)
- Go:
- Coverage artifact guard: After extension
npm test(and before spine batches), runbash scripts/check-untracked-coverage.shfrom the repo root. The script fails if any path underextension/coverage/is tracked in git; untracked coverage output is expected and only warned.
- Source of Truth: All implementation MUST follow
docs/PRD.mdanddocs/implementation-plan.md. - Phased Delivery: Complete work in phases as defined in the Implementation Plan.
- Verification: A phase is not complete until new/changed code has tests, coverage thresholds are met, and existing tests pass.
- Extension
npm install: Deprecatedglobwarning from transitive deps (Vitest coverage). Resolving would require Vitest 4 or glob overrides that need Node 20+. - Extension
npm test: "The CJS build of Vite's Node API is deprecated" comes from Vitest; tests pass. Upgrading to Vitest 4 would address it. - Extension
npm test: One test intentionally triggers an error path; stderr "Failed to clear findings panel" infinishReview.test.tsis expected and not a failure.
Before marking a phase or task as complete, you MUST run the appropriate "Brutal Audit" to verify quality.
- For Go code: Run the steps in
.cursor/rules/go-1-21-brutal-audit.mdc. - For JS/TS code: Run the steps in
.cursor/rules/javascript-3-brutal-audit.mdc. - For Rust code: Run the steps in
.cursor/rules/rust-brutal-audit.mdc.
To invoke: Ask the agent to "Run the brutal audit" or "Verify this phase".