Vetrix Docs

Vetrix User Documentation

End-user guides for using Vetrix: authentication, repositories, CI/CD, package registries, and integrations. Operator and admin guides live in the separate runbook, admin, and system documentation sets.

Start here: Getting Started with Vetrix.

Authentication

  • Authentication — signing in, adding a second factor, minting credentials for scripts, and exchanging identity with external providers.

Repositories

  • Repositories — Git access over SSH and HTTPS, the built-in issue tracker, mirroring, and the rules that gate what lands on a branch.

CI/CD

  • CI/CD — writing the pipeline file, controlling which jobs fire on which branch, provisioning the runner that executes them, the scanners and gates that inspect the result, and the security-review record for the execution surface.

Registry

  • Registry — the client-facing container, npm, PyPI, Go module, and generic artifact endpoints: where to point tooling, how to present a credential, and what each protocol serves.

Integrations

  • Integrations — signed outbound webhook deliveries, the per-repository Model Context Protocol server, and the code-search index.

Reference

screenshots/ holds the image assets referenced by the pages above.

Contributing — operator-manual guardrail

These pages are an operator manual. Before opening a pull request, run the manual doc-lint. The command below works from any directory inside a clone:

bash "$(git rev-parse --show-toplevel)/llm-documentation/user-docs/doc-lint.sh"

The script switches to the repository root itself and scans every tracked Markdown and YAML file, so a single run covers all five documentation sets. Each set holds an identical copy of the script; running any one of them lints the whole tree, so this is not a per-set lint.

The script fails — listing file:line — when an operator-manual rule is violated. The Docs Reviewer enforces the same rules:

  • Use gitvetrix.com as the only product host (the .test dev host is fine).
  • Refer to the platform as Vetrix; do not use the legacy product name.
  • Keep tracker IDs out of the prose.
  • Link to other pages with relative .md paths. A markdown link whose target is an absolute git-host URL (https://www.gitvetrix.com/... or https://gitvetrix.com/...) fails the lint, because it sends the reader out of the manual and into the repository file browser; this is checked case-insensitively across inline links, reference-style link definitions, bare autolinks (a URL wrapped only in < >, no square brackets), and angle-bracket-wrapped destinations, including a userinfo-prefixed form (e.g. https://user:token@ in front of the host). Bare-text host mentions, curl examples and code blocks are unaffected.
  • Write in present-tense operator-manual tone, without decision or history narration.

doc-lint.sh must pass before review.

This tree is also in scope for the two link checkers at the repo root — python3 user-docs/check-links.py (relative link/image targets resolve, no crossing into user-docs/) and python3 user-docs/check-fragments.py (#fragment links resolve to a real heading or anchor) — documented in the Contributing section of the root-level user-docs/README.md.