Docs

File integrity

Changes to sensitive or protected paths in a repo's working tree, measured against origin/main. This is Layer C of ledger integrity. It shows what a protected path had changed, the diff, and a one-click restore to main's version. It reads the developer's actual checkout, so it catches both committed-on-a-branch and uncommitted edits, using git's object store as the baseline a developer cannot rewrite without push and review.

Where to find it

  • Localhost: /file-integrity.html
  • API: GET /api/file-integrity (scan), GET /api/file-integrity/diff (one path), POST /api/file-integrity/revert
  • Sidebar: Guard, then File integrity

What it does for you

Shows what changed in a protected path, and reverts it.The scan runs a git diff of the working tree against origin/main, scoped to a sensitive-path watchlist, plus untracked files in those paths. You can open the diff for any changed path, and the guarded revert restores main's copy via git checkout origin/main -- <path>, a destructive working-tree action behind a confirm.
Honest about what a local monitor can do.A local file-integrity monitor is itself disable-able by a determined developer, so this is the visibility and a local revert affordance, not enforcement. The real enforcement of "can't change protected paths without sign-off" is server-side branch protection plus CODEOWNERS; the tab surfaces a recommended config for that.

Built vs. planned

The watchlist scan against origin/main, untracked-file detection, the per-path diff, and the guarded revert ship today, backed by lib/file-integrity.mjs (exported as scanIntegrity with a DEFAULT_WATCHLIST) and served through lib/routes/file-integrity.mjs. Results are cached per repo; ?fresh=1 re-scans. The same Layer-C summary also rolls up into the Governance tab.