🦏 RHINO

Repository Hygiene & INtegration Orchestrator checks that a repository matches the policy it explicitly declares. It ships no repository, organization, harness, tree, or threshold defaults.

RHINO validates declared Markdown, governance, lifecycle, harness, environment, and toolchain policy. Tree validators read local files only: they do not write, spawn, or connect to a network. env validate asks Git for the staged paths when a staging guard is declared, and toolchain validate runs each declared probe. Declared gates and explicit operations use separate, narrow boundaries.

Highlights

• No policy of its own. Every repository-specific value it enforces comes from repo-config.yml.
• Closed grouped configuration. rhino/repo-config/v2 rejects unknown core groups and keys instead of treating a typo as silent policy.
• Explicit operations. Adapter generation, environment setup, toolchain provision, and gate execution need their own declared authority.
• Stable exit meanings. 1 means a declared policy found a violation; 2 means the invocation, configuration, or boundary was unusable; 126 and 127 mean a gate child could not be executed or was not found, the same two things a shell reports with those numbers. A signal ends the process as 128+N, never as a value in the result range.
• Machine-readable results. --output json keeps programmatic callers out of human prose.

Install

The download and extraction sequence below was not exercised during this documentation pass.

Source validation evidence does not verify a downloaded release artifact.

Download a published, immutable release tag and verify its checksum before extracting it. Each release carries one checksum manifest for all four supported archives.

VERSION=REPLACE_WITH_RELEASE_TAG
TARGET=aarch64-apple-darwin
BASE="https://github.com/wahidyankf/rhino/releases/download/$VERSION"

curl -fsSLO "$BASE/rhino-$TARGET.tar.gz"
curl -fsSLO "$BASE/checksums.txt"
shasum -a 256 --ignore-missing -c checksums.txt
tar -xzf "rhino-$TARGET.tar.gz"

Replace the placeholder with a tag from the releases page that is not marked Pre-release; the one marked Latest is the newest. The grouped configuration below needs v0.4.0 or later; a key added later needs the release that added it, such as v0.9.0 for policies.governance.quality-gates. The full procedure, including the Linux checksum alternative and PATH installation, is in How to install a pinned release.

Quick start

Create repo-config.yml at the repository root and declare only the policy your repository owns. This minimal example adopts internal-link validation:

schema: rhino/repo-config/v2
policies:
  markdown:
    internal-link:
      exclude-sources: []

Validate the configuration, then run its declared validator:

$ rhino repo-config validate
$ rhino md internal-link validate

An omitted policy group makes the leaf that needs it exit 2; it is not a clean result. Add Markdown, governance, gate, harness, environment, and toolchain groups only when the repository can name their scope and owner.

Lifecycle and operations

gate list shows declared membership across the seven closed lifecycle surfaces. gate validate checks membership and pull-request composition before gate run --surface <name> dispatches a declared typed argv projection. A gate cannot replace its command with arguments after --.

Formatter gates can opt into regular-files to select changed regular-file destinations from the staged index or an immutable range; see how to wire RHINO into your gates.

Environment initialization and toolchain provision plan first and require --apply for a declared mutation. Environment backup and restore require a repository-relative --dir; restore additionally requires --force before it replaces an existing target. Harness adapter generation validates the complete declared profile projection before it replaces declared adapter families and exact adapter files.

v0.3 to v0.4 migration

Stable v0.4 accepts only the grouped schema. It rejects predecessor schemas and does not provide aliases, compatibility wrappers, or a migration command. Create an explicit grouped configuration and validate it locally before using the stable binary.

How to migrate from v0.3 to v0.4 gives the owner-by-owner mapping and verification sequence.

Documentation

The documentation follows Diátaxis.

Section	Use it when
Tutorials	You are learning the product surface.
How-to guides	You have a concrete maintenance goal.
Reference	You need an exact command, flag, code, or configuration key.
Explanation	You need the design reasoning.

The specifications tree is canonical. If documentation and the executable Gherkin corpus disagree, the corpus wins.

Project status

RHINO is a pre-1.0 product released in the 0.x line, where a breaking change moves the minor version; the changelog records each release. Since v0.4.0, stable accepts the grouped contract only, rather than carrying an unbounded compatibility layer. Published tags and assets are immutable.

Contributor rules for maintainers and automated agents start at AGENTS.md. External contributions are currently closed while the engineering patterns stabilize.

Project context

RHINO is one of seven ose-projects repositories, with hippo, ose-public, beaver-nest, ose-rules, py-typekit, and ose-private (Private), and remains usable on its own. The label is navigation only, not product coupling: repositories choose their own policy, version, release cadence, and configuration. See project context for each one's link and relationship.