Product workflow

Work Graph is a local task tracker in git — board, backlog and statuses included. The difference is the unit of work: a BVC contract with evidence gates, not a chat ticket. Decisions become AN records, tasks become .bvc atoms, motion on the board, readiness via verification, outcomes in project memory.

The platform lives in your repository

  1. Fully local and in Git All data (.bvc, .md, .jsonl) stays inside your repository. No WG cloud database, no SaaS subscriptions — you own the data.

  2. MCP integration AI agents talk to WG over MCP, calling tools such as get_work_contract, submit_evidence or assert_task_ready_for_done.

  3. Local UI A web interface for backlog, kanban board, analytics, verification and architecture.

  4. 1C / OneBase support Domain verticals including 1C via specialized MCP servers and evidence contracts.

Five steps in one repository

Each step has a screen in the UI and a file contract in intent/.

  1. Decision (AN) Capture why before backlog intake
  2. Work contract (.bvc) Basis, Vector, Goal and checks
  3. Agent claim work.id, targetFiles and allowlist
  4. Evidence Commands, traces and structured records
  5. Verified memory Closed work linked to files in git

Surfaces you work in every day

Open npm run workgraph:ui on port 4177 after init — the same backlog your MCP agent sees.

Analytics

AN records hold options, boundaries and lineage before tasks exist. You see which epic or decision a work item came from — not a lost chat thread.

BVC work items

Each task is a .bvc atom with Basis, Vector, Goal, checks and labels. The drawer is the human view of what get_work_contract returns to the agent.

Kanban board

Columns reflect contract state: backlog, ready, claimed, doing, verify. Moving a card follows evidence and gates — not a manual status edit.

Verification

Tier A/B/C matrix lists deterministic commands and optional gates. assert_task_ready_for_done returns violations[] when proof is missing.

Project memory

Done tasks with valid evidence become memory records. The next agent session reads git, not a recap of the previous conversation.

Three graphs behind the UI

Screens map to Intent, Execution and Memory graphs. Together they form a loop humans can audit and agents can execute via MCP.

Intent graph

What and why

BVC atoms, AN → Epic → Work Item, depends_on and trace.* links.

Execution graph

How and by whom

work.id tasks, evidence, todo → ready → doing → done/blocked and gates.

Memory graph

What was decided

Closed tasks with valid evidence, audit trail and RAG context from git.

What lands in your repo after init

npx @work-graph/cli init . wires the filesystem contract — no WG cloud account.

intent/ graph
work.bvc backlog
MCP for Cursor
UI on :4177
workgraph:doctor
llms.txt