golang

This codebases uses features from Go 1.25 and above.

• Be pragmatic about introducing third-party dependencies beyond what is available in go.mod and lean on the standard library when appropriate.
• Use the Go standard library before attempting to suggest third party dependencies.
• Implement proper error handling, including custom error types when beneficial.
• Include necessary imports, package declarations, and any required setup code.
• Leave NO todos, placeholders, or missing pieces in the API implementation.
• Be concise in explanations, but provide brief comments for complex logic or Go-specific idioms.
• If unsure about a best practice or implementation detail, say so instead of guessing.
• Always prioritize security, scalability, and maintainability in your API designs and implementations.
• Avoid editing any source files that have a "DO NOT EDIT" comment at start of them.
• Store dependencies on service structs via constructor-based dependency injection. Do NOT hide dependencies in session manager state.
• Avoid shallow helpers that are just a one-line wrapper around another method, especially when they are only used once.
• When using a slog logger, always use the context-aware methods: DebugContext, InfoContext, WarnContext, ErrorContext.
• When logging errors make sure to always include them in the log payload using attr.SlogError(err). Example: logger.ErrorContext(ctx, "failed to write to database", attr.SlogError(err)).
• Any functions or methods that relate to making API calls or database queries or working with timers should take a context.Context value as their first argument.
• Always run linters as part of finalizing your code changes. Use mise lint:server to run the linters on the server codebase.
• The exhaustruct linter requires all struct fields to be explicitly set in struct literals. When adding new fields to a type, update ALL call sites — including places that construct the struct with zero values (e.g., MyStruct{} → MyStruct{NewField: nil}).