Reporting an Issue

This page describes where each kind of report goes and how a fix travels from report to production. Use it whenever you find a bug, want to request a feature, have an idea to discuss, or need to disclose a security vulnerability.

Overview

Lumio uses a small number of dedicated surfaces so every report lands in exactly one place and can be tracked to resolution:

• GitHub Issues — code-level bug reports and concrete feature requests that benefit from sitting next to the code and pull requests.
• GitHub Discussions — open-ended ideas, questions, and RFC-style proposals that are not yet actionable work.
• GitHub Security Advisories — the only correct channel for security vulnerabilities. A vulnerability is never filed as a regular issue.

Accepted reports are triaged, labelled, and tracked internally through to a fix.

Where to report

Pick the surface that matches what you found:

What you have	Where it goes	Notes
Bug or error	GitHub Issue — bug report template	Include steps to reproduce, expected vs. actual behaviour, and the affected app.
Concrete feature request	GitHub Issue — feature request template	For a well-scoped, buildable change.
Open-ended idea	GitHub Discussion — Ideas	Promising ideas are promoted to tracked work.
Question or how-to	GitHub Discussion — Q&A	For usage and support questions.
Design proposal / RFC	GitHub Discussion — RFC category	Accepted RFCs become tracked work items.
Security vulnerability	Private GitHub Security Advisory	See Security vulnerabilities below — never a public issue.

Issue templates prompt for the details maintainers need, and labels (type, priority, status, scope) are applied during triage so you can follow progress on the report.

Security vulnerabilities

warning

Do not report a security vulnerability as a public issue or discussion.

Report vulnerabilities privately through a GitHub Security Advisory, following the repository's security policy (SECURITY.md). Private advisories keep the details restricted while a fix is prepared and let maintainers coordinate a release before any disclosure.

How a fix reaches production

Fixes and features move through branches and a versioned release tag. The environment each stage maps to matches the Deployment and Installation guides:

Stage	Branch / tag	Environment
Development & integration	next	Staging
Release preview	main	Production preview
Release	version tag, e.g. api@2026.5.3	Production

The flow, end to end:

1. Branch and open a pull request into next. next is the staging integration branch and the default target for normal fixes and features. CI must be green and the change reviewed before it merges.
2. Promote to main. Once validated on staging, next is merged into main, the production-preview branch.
3. Cut a release. A production deploy is triggered by publishing a versioned release tag in the {app}@{version} format (for example api@2026.5.3), which builds and pushes the image. See Deployment for the full tag reference.

Security fixes are the exception: an urgent fix may target main directly rather than waiting in next.

Following updates

Track progress from the surface where you reported:

• Issues and Discussions — the thread's labels reflect its status, and GitHub notifications alert you to comments and status changes when you participate in or watch the thread.
• Security advisories — updates are shared privately with the reporter until a coordinated release.

See Contributing for local setup and pull-request conventions.