Governance policies

Policies that keep Flock’s codebase and guardrails from drifting apart.

Verification pipeline

.github/workflows/ci.yml
        │
        ├── scripts/drift-guard.sh  →  flock drift-check (manifest)
        └── scripts/verify.sh       →  fmt, clippy, hack, test, build, smoke

CI must call ./scripts/drift-guard.sh then ./scripts/verify.sh only. Do not add duplicate lint or test steps to the workflow — that creates anti-drift debt.

Single source of truth

When adding a new required check:

1. Add a ManifestCheck entry to manifest.rs.
2. Implement validation in run_drift_check.
3. If the check belongs in the full suite, add it to verify.sh.
4. Note the change in your PR description (required).

PR requirements

PRs that touch any of the following must include a ## Guardrails section in the description explaining what changed and why:

• scripts/verify.sh
• scripts/drift-guard.sh
• .github/workflows/**
• crates/flock-governance/src/manifest.rs
• rust-toolchain.toml, clippy.toml, rustfmt.toml, deny.toml

PRs that change Rust style conventions must update the engineering guide in the same PR.

Drift-check command

cargo run -p flock-cli -- drift-check
# or, after install:
flock drift-check

Exits non-zero when any VERIFICATION_MANIFEST expectation fails. Use locally before pushing when editing guardrail files.

Python deprecation

The python/ tree is deprecated and packages were removed. python/README.md must retain a deprecation notice — drift-check enforces this when the directory exists.

Review expectations

• Guardrail changes: one maintainer approval minimum.
• Manifest changes: confirm flock drift-check and ./scripts/verify.sh both pass in CI.
• No allow(dead_code) in crate sources without removing the check from manifest (not permitted).

Related

• Agent hooks — multiplexer lifecycle reporting
• CLI reference — flock drift-check