async-jobs-and-events
Background jobs, domain events, and side effects
When to use: Queues and workers, domain event publishers, async notifications or projections, or not doing that work inside HTTP handlers.
Side effects and eventing
- Domain code emits domain events through domain-level publisher abstractions (ports), not ad-hoc calls from use-cases to email/HTTP/Slack.
- Workers handle notifications, integrations, projections, and other I/O asynchronously.
- Do not orchestrate side effects (fan-out integrations, “fire and forget” HTTP, etc.) inside HTTP handlers — enqueue / publish and return.
Domain event naming and publisher–consumer decoupling
Domain events represent facts that happened — state transitions on an aggregate — not instructions for what should happen next. The publisher must never know or care which handlers are subscribed.
Rules
More from latitude-dev/latitude-llm
gh-issue
Create clear, actionable GitHub issues for bugs, features, and improvements. Issues are primarily consumed by LLMs, so optimize for agent readability and actionability.
4testing
Writing or debugging tests, choosing unit vs integration style, Postgres/ClickHouse tests, regenerating ClickHouse test schema, or exporting test helpers from packages without pulling test code into production bundles.
4docs
Review the current conversation context and git changes, then persist durable repository knowledge into `dev-docs/*.md` by domain and into `AGENTS.md` for cross-cutting repo rules. Use after features, fixes, refactors, architecture changes, schema changes, or when the user mentions docs, documentation, design, architecture, business logic, conventions, or `AGENTS.md`.
4create-pr
Patterns and conventions for creating a good PR
4authentication
Sessions, sign-in/sign-up flows, OAuth, magic links, or organization context on the session.
4analyze-problem
>-
4