all work

Evidoc — documentation drift control for agentic repositories

  • TypeScript
  • Node.js
  • MCP
  • GitHub Actions
  • CLI
  • Local Web UI
  • Documentation Drift
  • Agent Workflows

A public, local-first developer tool that checks whether README files, docs, AGENTS.md, CLAUDE.md, examples, API notes, and source-bound documentation still match the repository that exists now. It gives humans, CI, and coding agents the same repo-local evidence before they trust or repair stale context.

View code

At a glance

Role Sole builder — product framing, CLI, MCP server, local Command Center, GitHub Action, Local Git Gate, release workflow

Problem

Agentic repositories accumulate stale instructions quickly: README commands drift from package scripts, AGENTS.md and CLAUDE.md keep obsolete paths, examples stop matching APIs, and coding agents may trust those claims before checking the source. Evidoc turns that trust problem into a local evidence workflow.

Solution

I packaged the trust check as a local workflow available from the CLI, MCP server, local web UI, and GitHub Action. Each surface compares documentation claims against repository evidence before suggesting repairs or blocking a gate.

Impact

Public v0.3.2 · published on npm as @evidoc/evidoc · CLI, MCP server, Local Web UI, GitHub Action, Local Git Gate · package artifacts for CLI, core, dashboard, local app, MCP server, reports, and review log

My contribution

  • CLI workflow for checking drift, running doctor diagnostics, generating repo-local reports, and enforcing local gates from the command line
  • MCP server for coding agents, exposing drift status, scans, diagnosis, doc-fix suggestions, and explicit review logging as bounded tools
  • Bilingual Evidoc Command Center / Local Web UI for repository health, triage, repair prompts, and local-gate visibility
  • GitHub Action for CI-side drift checks, PR feedback, changed-file focus, and compatibility detection for old DriftGuard action references
  • v0.1.0 release that completed the DriftGuard -> Evidoc rename across CLI, npm packages, .evidoc state, MCP, GitHub Action, local app, and docs
  • npm scoped publication as @evidoc/evidoc in v0.3.x, after the Evidoc namespace migration, topological npm publication, and hardened 0.3.2 release flow

Technical evidence

  • Repo-local evidence model: compare commands, paths, symbols, package scripts, frontmatter source bindings, API surfaces, and changed files before trusting documentation claims
  • Agent-safe defaults: read-only checks by default, explicit write boundaries for review logs and repair proposals, and no reliance on remote project knowledge
  • Repair workflow separates evidence, diagnosis, and patch suggestions so generated fixes remain reviewable instead of silently rewriting repository truth
  • Release hardening covered doctor readiness, scoped package artifacts, GitHub Action behavior, and docs aligned with the current scoped npx and local GUI paths

Why docs drift matters

Coding agents increasingly start from repository instructions before they read source files. If those instructions are stale, the agent can confidently follow commands, paths, policies, or examples that no longer exist.

Evidoc makes documentation trust explicit: scan the repo, collect evidence, mark stale claims, and only then decide whether to fix the docs, block a gate, or ask for human review.

CLI, MCP, Command Center, CI

The same evidence workflow is available from multiple surfaces: the CLI for local checks, the MCP server for agent workflows, the Local Web UI for triage, and the GitHub Action for pull-request feedback.

The v0.1.0 release made that surface area coherent under the Evidoc name while keeping compatibility detection for older DriftGuard action references.

Current distribution is through the npm scoped package @evidoc/evidoc at v0.3.2, after the namespace migration and release hardening.

Bounded repair, not blind automation

The tool is designed around reviewable evidence rather than silent rewriting. It can suggest fixes and prompts, but the boundary between diagnosis, proposal, and accepted repository change stays visible.