Vireo is developed in public. Use the route that matches the type of feedback so maintainers and future contributors can find the result.
Ask and discuss#
Use GitHub Discussions for architecture questions, adoption experiences, ideas and design exploration.
Report a reproducible problem#
Use GitHub Issues for confirmed bugs. Include:
- Exact Vireo documentation and package versions
- Project profile
- Operating system and tool versions
- Doctor JSON output where relevant
- Minimal reproduction or failing schema
- Expected and actual behavior
Remove secrets and private company data.
Contribute#
Read the contributing guide before opening a pull request. Public API changes require tests, documentation, compatibility consideration and a changeset where applicable.
The vireo-template repository demonstrates public consumer composition; the vireo repository owns framework libraries, CLI, contracts, release automation and this website.
Security reports#
Do not open a public issue for an unpatched vulnerability. Follow the private route in the security policy.
Evaluate honestly#
Vireo's current maturity is public 0.x. Reports about confusing onboarding, missing workflows and unsuitable architecture are as valuable as code contributions.
- Record a sanitized public-beta evaluation after a bounded technical review.
- Open an independent adopter check-in only when you control a non-fixture application and meet the qualification statements in the form.
The form definitions and submitted issues are public; opening or submitting the rendered forms requires GitHub sign-in. Do not include credentials, private source, application data, employer or client identity, or vulnerability details.