Honest answers, in plain language
Short, self-contained answers to the questions people actually ask — written so a human and an answer engine get the same truth. Sourced from the repo's docs and shipped code; limitations stated, never green-washed.
Platform
What is Veylqorix?
Veylqorix is a universal code-security and quality platform that verifies AI-generated and human-written code before it is committed, pushed, merged, or deployed. It orchestrates real scanners — dependency auditing, secret detection, license checks, static analysis, and test suites — normalizes their output into one finding schema, and turns it into a deterministic gate decision with auditable evidence.
What is the Rust security engine, and is it live?
Veylqorix now has a pure-Rust security engine (crates/veylqorix-engine): a byte-compatible re-implementation of the secret scanner, policy resolution, and gate, spoken to over a bounded JSON-over-stdio protocol. When its release binary is available, runAudit makes the engine authoritative for the secret scanner and the gate; when it is missing, the audit degrades to the byte-compatible TypeScript scanner and policy with an honest compatibility note — never a silent fallback. The Rust engine and its TypeScript adapter are on main; building the release binary (cargo build --release -p veylqorix-engine) points at it via VEYLQORIX_ENGINE for authoritative results.
Does Veylqorix do a transitive license audit?
No. License scanning is manifest-level: it checks declared licenses and copyleft risk in the manifests. It is not a transitive dependency license audit, and a clean quality check is not a security certification — Veylqorix reports what its scanners found, not an absence of vulnerabilities.
Can I add my own scanners or quality checks to a Veylqorix audit?
Yes — the plugin SDK (@veylqorix/plugin) lets a team author custom scanners and quality checks with definePlugin, wrapping an in-house SAST tool, an SBOM policy check, a coverage gate, or a house rule. The evidence is handed to runAudit through runPluginAudit, or through toAuditOptions/withPlugin if you drive the audit yourself; its findings pass through the same normalizeFindings pipeline as the built-ins and are judged by the same single-sourced gate. The package is not published to npm yet — it is consumed from the monorepo via workspace:* (same status as the CLI), and is covered by 20 SDK tests plus 7 core regression tests.
Gate
What do the Veylqorix exit codes mean?
The quality gate is deterministic: exit 0 is PASS (no blocking findings), exit 1 is FAIL (blocking findings present), and exit 2 is INCOMPLETE (coverage was degraded). Exit 2 is the most important: it means a scanner errored, was skipped, or a mandatory check could not run, so the gate refuses to report a clean pass. Stable codes make CI branching predictable and auditable run to run.
Why does the gate report INCOMPLETE instead of just failing?
Most gates have two answers — pass or fail. Veylqorix has a third, INCOMPLETE (exit 2), for degraded coverage: no network, --offline, a missing binary such as pip-audit, or no lockfile for npm audit. A scanner that cannot run is reported SKIPPED or ERROR with a reason, never mistaken for a clean pass. This is deliberate: incomplete audits are surfaced, not green-washed.
Can an AI agent suppress findings or raise thresholds to force a pass?
No. The gate is driven by a committed policy file. Exceptions must carry a documented reason, are capped by maxExceptions, can expire, and are recorded in every gate decision. An exception is honored only if it is present in the committed policy file and visible in the report. The gate and its checks cannot be weakened to make a test pass.
Operations
What does veylqorix check do, and can it verify secrets?
veylqorix check runs the quality checks only — type, lint, and tests — and runs no scanners, so its gate is always INCOMPLETE (exit 2): coverage is degraded by construction, not just when something errors. Secrets are never verified by check; use veylqorix scan for full coverage including secret detection. A clean check output must never be read as a clean security result.
Does the GitHub Actions gate block merges on its own?
No. The reusable veylqorix-gate workflow runs a real scan, uploads SARIF to code scanning, and exits non-zero on blocking findings or incomplete coverage. But it blocks a merge only when the calling repository requires that workflow's status check via branch protection or a ruleset. Until that is configured, the gate is advisory: it produces findings and fails the check, but a merge can still be forced. That is stated in the workflow file itself, never hidden.
Why does the dashboard sometimes show demo data?
When the API is unreachable, the dashboard renders clearly-labeled sample data under a DEMO MODE banner. It never presents a demo as a live result. Starting the API flips it to LIVE with real scan data.
How do I run and secure the Veylqorix REST API?
The API binds to loopback (127.0.0.1) by default, so it is reachable only on the local machine. To serve it remotely or protect it, set VEYLQORIX_API_TOKEN and VEYLQORIX_API_HOST: a non-loopback host with no token refuses to start, and with a token set, every /api route except GET /api/health requires the header Authorization: Bearer <token> (401 when missing, 403 when wrong). Cross-origin dashboard use is controlled by VEYLQORIX_CORS_ORIGINS, a comma-separated exact-origin allowlist — no wildcard. Operational limits: VEYLQORIX_MAX_CONCURRENT_SCANS (default 2; excess requests get 429 with retryAfterSec), VEYLQORIX_BODY_LIMIT_BYTES (default 1 MiB; larger bodies get 413), and VEYLQORIX_MAX_FIELD_LENGTH (default 4096; longer fields get 400). State (repositories and scans) persists to the durable store at VEYLQORIX_STORE_PATH, so a restart never loses data: scans that were in flight recover as INTERRUPTED, never DONE, and can be re-triggered.
Do I need to install anything to run a scan?
No. The secret, license, and quality scanners run from the Node runtime. The dependency scanner needs npm audit (Node) or pip-audit (Python); without the binary or network, that scanner is skipped and coverage is degraded — never hidden. The CLI is not published to npm yet, so it is run from the monorepo build.
Security
Are my secrets safe in the reports?
Yes. Matched secret values are redacted in every output surface — JSON, Markdown, SARIF, the API, and the dashboard — using a consistent format (for example "AKIA…CDEF (20 chars, redacted)"). Test fixtures contain only fake, well-known placeholder values, never real credentials.
Are the Git hooks a security boundary?
No — local hooks are a convenience, not a security boundary. They never touch git config and back up any non-Veylqorix hook before replacing it, but they are bypassable with git commit --no-verify or the VEYLQORIX_OVERRIDE=1 escape hatch. The authoritative enforcement point is the GitHub Actions gate plus branch protection.
Can a custom plugin scanner make a bad scan look clean?
No. A plugin scanner or check that throws or times out is wrapped by the core and recorded as an ERROR result — under the default policy that blocks the gate and degrades coverage to INCOMPLETE (exit 2), never a clean pass. Plugin findings are normalized like built-ins, the only process API is the core’s shell-free execFileAsync (no shell, hard timeout, bounded output), and there is no surface for plugins to raise thresholds or suppress findings — the gate is shaped only by the committed, auditable policy file. One duty stays with the author: reports trust that findings arrive redacted, so a plugin that detects secrets must mask values before emitting them.
Ecosystems
Which ecosystems are supported?
Project detection covers Node, Python, Go, Rust, Java, Ruby, PHP, and .NET manifests. The dependency scanner is backed by npm audit (Node) and pip-audit (Python); the Rust engine adds cargo audit for Rust. Scanners run where their toolchain is present; where it is not, the scanner is skipped and coverage degrades rather than failing silently.