agentleFS
autonomous-aiautonomous-ai/lampOS/.cursor/rules/architecture.mdc

lampOS / rules

Cursor rule535 starsChanged 7 months agoApache-2.0View on GitHub

Architecture and coding conventions for AI Lamp OpenClaw

We split this architecture.mdc into the rules it gives an agent

10 rules. About 0 are common, 4 are distinctive, and 6 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 6

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Distinctive:

    Use Google Wire for compile-time DI — no runtime reflection

    line 18
  2. Very specific:

    After changing any provider signature: run make generate

    line 19
  3. Very specific:

    Never manually edit wire_gen.go files

    line 20
  4. Very specific:

    All responses use serializers.ResponseSuccess(data) or serializers.ResponseError(err)

    line 24
  5. Very specific:

    Always wrap errors with context: fmt.Errorf("operation: %w", err)

    line 31
  6. Distinctive:

    Never swallow errors silently

    line 33
  7. Very specific:

    Always pass context.Context for cancellation

    line 37
  8. Very specific:

    Use sync.Mutex for shared state, not channels (unless fan-out pattern)

    line 39
  9. Distinctive:

    Use notification channel for propagating config changes to services

    line 44
  10. Distinctive:

    Never hardcode secrets — load from config file

    line 45

≈ “Common” is an estimate: at least 1 in 5 of the 6,350 Cursor rule files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
architecture.mdc
---
description: Architecture and coding conventions for AI Lamp OpenClaw
alwaysApply: true
---

# Architecture Rules

## Package Structure

- **Handlers** go in `server/<domain>/delivery/http/handler.go`
- **Services** go in `internal/<domain>/service.go`
- **Domain types** go in `domain/<type>.go`
- **Wire providers** go in `server/wire.go` and `bootstrap/wire.go`
- **Shared libraries** go in `lib/`

## Dependency Injection

- Use **Google Wire** for compile-time DI — no runtime reflection
- After changing any provider signature: run `make generate`
- Never manually edit `wire_gen.go` files

## API Conventions

- All responses use `serializers.ResponseSuccess(data)` or `serializers.ResponseError(err)`
- Response format: `{"status": 1|0, "data": <payload>|null, "message": null|"error"}`
- Validate requests with `go-playground/validator` at handler level
- Return early on validation failure with `http.StatusBadRequest`

## Error Handling

- Always wrap errors with context: `fmt.Errorf("operation: %w", err)`
- Log with component prefix: `log.Println("[led] starting engine")`
- Never swallow errors silently

## Goroutines & Concurrency

- Always pass `context.Context` for cancellation
- Background goroutines must select on `ctx.Done()`
- Use `sync.Mutex` for shared state, not channels (unless fan-out pattern)

## Configuration

- Config in `config/config.json` managed by `server/config/config.go`
- Use notification channel for propagating config changes to services
- Never hardcode secrets — load from config file

## Build

- Cross-compile target: `GOOS=linux GOARCH=arm64`
- Version injected via ldflags — never commit binaries
- Lint with `golangci-lint run` before committing

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.