Parity (the ProveSpec workbench)

The application that measures whether one implementation has what another declares — specified against itself.

34 capabilities 2 sections extracted from Parity source: D:\Dev\Lab\Parity

Build against it

# give your agent the catalog — no account, no install
claude mcp add provespec -- npx -y provespec-mcp

# then, from any agent session
spec_get(slug: "parity")                → the capability tree
spec_checklist(slug: "parity")          → the questions to answer
spec_grade(slug: "parity", grades: [...])  → parity % + the gap list

# or just fetch it
curl https://provespec.com/catalog/parity/spec.json

Grade every capability below as yes · partial · no · na, with a file reference as evidence. Whatever you leave ungraded counts as missing — the gap list is the work queue.

Or just paste this to your agent

Use the ProveSpec MCP server. Fetch the "parity" spec with
spec_get, then walk spec_checklist and grade this repository against it —
one verdict per capability, each with a file reference as the note.
Call spec_grade with the results and give me the gap list as the plan.

If the server is not registered, add it first:
  claude mcp add provespec -- npx -y provespec-mcp

The specification

AI 20

Model

✓ Comparison as products x capability tree x cells The whole product rests on this one shape: a tree of capabilities, a set of products, and a verdict at each intersection. Everything else is a projection of it.
✓ Capability tree of arbitrary depth Groups nest without limit; only leaves carry verdicts. Depth is the unresolved granularity question — two honest extractions at different depths score the same code differently.
✓ Four verdicts per cell yes | partial | no | na "partial" is what a has-it checkbox cannot express, and it is where a port quietly diverges from its reference.

Relation

✓ Parity as fully-has over declares parity = fullyHas(target) / has(baseline) Directional by construction. The same tree answers "is the port done?" and "what does the port add?" without a second model.
✓ Not-applicable leaves the denominator on both sides Subtle and load-bearing: an "na" that stayed in the denominator would penalise a target for something nobody asked of it.
✓ Ungraded counts as missing Silence is not credit. Without this rule a spec gets a good score by leaving hard capabilities unanswered.
✓ Target-only capabilities reported, never scored What the target has beyond the baseline is information, not a defect. Getting this backwards once turned a 100% reading into 95%.
✓ Parity of a subtree, not only the whole The differentiated question. Scoping to one branch is what lets a UI be graded against its own engine.

Output

✓ Markdown report of the gap The artifact a porting agent actually works from — not the percentage, the list.
✓ Spec card: coverage rolled up per section
✓ SVG badge coloured by percentage
✓ CI gate against a threshold Turns the number into something that can fail a build, which is the only way a parity figure changes behaviour.
✓ Difference detection across products

History

✓ Append-only assessment record A parity number is only true of a commit. Overwriting the last reading is how a stale number gets presented confidently.

Import

✓ Apply a JSON spec into a comparison The way agents write to the app. Values are normalised so "REST" and "rest " do not read as a difference.

Storage

✓ Local store with no native dependency node:sqlite Chosen over better-sqlite3 specifically to avoid Electron native rebuilds on Windows.
✓ Carries a pre-rename database forward on first run Copies rather than moves, and never overwrites an existing file. The catalog is the asset; a rename must not cost it.

Headless

✓ MCP server over the local store comparisons_list, comparison_get, parity_report, spec_import, parity_history How an agent works with Parity without a screen.
✓ CLI for CI check, badge, history, record
✓ Engine is browser-safe, storage is not @parity/ai is pure and bundles for a browser; @parity/ai/data reaches node:sqlite and does not. This split is what makes a web shell an adapter rather than a rewrite.

UI 14

Shell

✓ VS Code-style workbench Activity bar, primary and secondary sidebars, status bar, bottom panel — from the shared Shell library, not reimplemented.

Views

✓ Matrix: capability rows against product columns
✓ Spec card view The second reading of the same data. It does not yet render the dense square grid used as the product's signature image on the site — the two surfaces draw the same artifact differently.
✓ Differences-only filter The most-used reading in practice: rows where the products actually disagree.
✓ Scope the view to one branch

Editing

✓ Cycle a cell's verdict by clicking it Grading is the highest-frequency action in the app, so it costs one click and no dialog.
✓ Create and delete comparisons
✓ Add, rename, delete and source a product A product's source folder is what lets a grade cite where it came from.
✓ Add, rename and delete capabilities
✓ Import a JSON spec from the interface

Reading

✓ Report dialog with markdown export
✓ Assessment history panel Reads the append-only record. Without it the app shows only the present, which is the state a stale number hides in.
✓ Running version shown in the status bar package.json is the single authority; the running app exposes exactly which build you are looking at.

Freshness

✓ Re-reads the store when the window regains focus Agents write to the database from outside the app. Without this the interface shows a stale picture and never says so.

Download spec.json All 102 specs