Additional information

Any signed-in user can send a support request from inside the web application. It goes to the people who hold the reviewer roles in your own Kumoss deployment — colleagues on your platform team, not the Kumoss project — through the channel your platform team connected (Slack in the reference setup), with a copy addressed to you.

From the browser, the chat-bubble Support icon in the header opens a form for up to 500 characters, plain text only — HTML and code formatting are rejected. The message carries your e-mail, the session id, the repository, branch, request, status, and a link to the session automatically, so you do not need to copy those in yourself. Contact Team (on a locked session) and Request Review (on the apply confirmation) send the same kind of message, pre-filled for that session, and flagged as a warning when the plan deletes or recreates resources. "Your question has been sent successfully" confirms delivery; "Your question could not be sent. Notifications are disabled." means your deployment has not connected a notification channel — use your organization’s usual support route and quote the session id.

The form calls POST /api/v1/notifications. The core forwards the request to the notifications sidecar with an audience made of the caller’s e-mail plus every user holding a panel role of editor or higher, and the bundled sidecar posts it to Slack. When services.notifications.enabled is false the route answers 503 Notifications are disabled.; when delivery fails it answers 502 Notification was not delivered.

Report a security vulnerability through the disclosure submission program, in English — never through a public GitHub issue. The security team acknowledges a report within 48 hours, investigates its severity, and develops, tests, and publishes a fix and an advisory. See the security policy for the full process and the safe-harbor terms covering researchers who report in good faith.