Trust through explicit boundaries
Security and control in the Xroga build workflow
Security is not a badge added after generation. It is the set of controls that determines what Xroga can read, change, execute, and publish—and what evidence the product returns.
01
Authorised accounts
Repository and provider operations use the permissions the connected user grants. Xroga does not claim access beyond those scopes and should report provider or policy blocks directly.
02
Protected credentials
Secret values belong in protected server or provider environments. Interfaces may show configuration names and readiness, but must not return secret values to the browser or include them in generated code.
03
Repository write safety
The active project context—repository, branch, and project scope—must match the target at the write boundary. Branch protections, organisation policy, concurrency controls, and review requirements remain authoritative.
04
Validation is evidence, not certainty
Xroga can run applicable checks and report their output. Passing tests reduce known risk; they do not prove the absence of vulnerabilities or operational failures. High-risk changes still require appropriate review.
05
Deployment truth
A production status requires evidence from the authorised deployment provider and verification of the running result. Missing environment values, DNS, quotas, or permissions remain explicit blockers.
06
Responsible reporting
Security concerns can be sent through the contact channel. Do not include passwords, tokens, private keys, sensitive customer data, or exploitable production details in public community posts.