Support and feedback

Orneos is small and pre-release. Support is a person, not a queue.

Email support@orneos.com.

Before writing

Two pages answer most questions:

• Troubleshooting — the problems people actually hit.
• Known limits — things that are missing on purpose, so you do not spend time reporting them as bugs.

If it is in Known limits, you can still write. Telling us a gap is blocking you is genuinely more useful than us guessing which gaps matter.

Reporting a bug

What makes a report actionable:

• What you did, and what happened instead. Specific beats general.
• Roughly when, and which team. Both help us find it server-side.
• Browser and version.
• Did a reload fix it?
• Did anyone else see it? This one matters more than it sounds — a problem only you see is usually local state, a problem everyone sees is usually the server. It halves the search.

A screenshot helps. A screen recording helps more.

Reporting a security issue

Email the same address with enough detail to reproduce. We will acknowledge and keep you posted. Please do not disclose publicly before we have had a chance to fix it. See Security and isolation.

Accessibility

Something unusable with a keyboard or a screen reader is a bug, not a limitation, and we treat it that way. Please report it rather than working around it.

Corrections to these docs

If a page here is wrong, out of date, or claims more than the product does, tell us. That last one especially — overstating availability is the specific failure this documentation is built to avoid, and an outside reader is better placed to catch it than we are.

Every page has a correction link at the foot.

Feature requests

Welcome. Tell us the problem you want to solve and how it affects your work. We use that evidence to shape priorities and scope. See Roadmap for active work, planned capabilities and options we are exploring.

The requests that move us are the ones attached to something concrete — a review that went badly, a decision that got lost, a gap that cost your team real time. Not “it would be nice if”. That is not a rhetorical preference; a specific failure tells us what to build and a general wish does not.

Pilots

If you want to bring a real change through a founder-assisted review, request a pilot. Scope, what material is shared, retention and any model-provider use are agreed with you in writing beforehand.