tadori
Updated November 9, 2026

Roadmap

Each stage has a condition that must be met before moving on. Whether tadori is useful is decided by whether people on real projects can say “yes, that really was a gap”. If they can't, development stops and the project is wound down.

Done

1. Runs locally (MVP)

  • The checking core: four kinds of rule (has something downstream, is based on something upstream, a column is filled, human approval) plus IDs that don't exist
  • Phase gates per phase (gaps and pending approvals), and tracing up and down from a single item
  • Commands: check (with a log), why, serve, init
  • Screens: remaining work to release (timeline / cards), product (WBS), rulesets, check log, trace, settings, glossary
  • A fictional sample project

Condition to move on: after starting it locally, people could read the situation from the remaining work and trace screens → achieved

Now

2. Working together with agents

  • MCP read tools: usage guide, glossary, remaining work, gaps (with owner and fix), trace, and searching ledger rows
  • An agent cursor inside the app: the agent points, clicks and types without using the person's mouse
  • Desktop app (custom title bar, light / dark, switching projects, starting a new project)
  • URL templates for opening md-business and git-qa (the md / qa icons next to each gap)
  • Installers for macOS (Apple silicon, Intel) and Windows (x64, ARM)
  • MCP write tools: ledger rows, WBS tasks, rules, people, phases, a logged check, switching projects (with no way to record a human approval)
  • Type-check the screens with TypeScript and add screen tests (Playwright) that run on every push
  • Add, edit and remove rules from the screen
  • Daily progress per person, drafted from WBS changes, ledger changes and the check log, with links to the sources of truth
  • Version check and update notice; server errors recorded locally and readable by agents
  • English and Japanese throughout (website, README, screens, messages, CLI, MCP and the guide)
  • Rules that check values: allowed values for a column (e.g. a result is OK or NG), and narrowing by column=a|b or column!=value (e.g. a failed test result must link to a defect ticket)
  • Read md-business verification sheets directly as ledger rows (without copying), and open the sheet with that row selected
Next

3. Run it on two real projects

  • Inside real projects, put the existing findings of two projects into a ledger (real project data never goes into this repository)
  • People read the gaps that check reports. If the column layout breaks on the second project, fix the columns and the sample

Stopping point: could people say “yes, that really was a gap”? If not, development stops and the project is wound down.

Later

4. Broaden

  • Pre-release checks (tadori before), spotting the same gap recurring (tadori repeat), importing from other ledgers (tadori import)
  • When a document changes after approval, move it back to pending approval (record which version was checked)
  • Listing and switching between multiple products and projects
  • Code-signed installers, and a version that bundles Node.js

What tadori won't build

Even if they sound useful, tadori will not build the following.

  • Deciding a gap is fixedPeople confirm that it's fixed.
  • Approving on someone's behalfNot even MCP gets a way to record a human approval.
  • Percentages and scoresThey breed rows that exist only for show.
  • Syncing with outside toolstadori records what it read at the time; the source of truth stays in the original tool.