mcprigor 1.0.0-rc.1

package/docs/SPECIFICATION.md

@@ -0,0 +1,178 @@
+# MCP Rigor runtime and product specification
+
+> Normative runtime behavior and product requirements. For `.mcpr` syntax, use the [language reference](LANGUAGE-SPEC.md). Everyday users should start with [Getting started](GETTING-STARTED.md).
+
+## 1. Product definition
+
+MCP Rigor is an open-source, deterministic, black-box application test framework for Model Context Protocol servers. Its core promise is:
+
+> Author a behavioral MCP scenario once, then run it repeatably against local subprocesses and deployed HTTP servers in CI.
+
+MCP Rigor complements interactive debuggers and protocol conformance tooling. It does not claim MCP certification.
+
+## 2. Users and jobs
+
+- **MCP server authors:** prevent regressions in tools, resources, prompts, errors, and side effects.
+- **Platform teams:** validate third-party servers before promotion or deployment.
+- **SDK maintainers:** run common behavioral scenarios across transports and versions.
+- **Security and QA teams:** build deterministic negative, authorization, and abuse cases.
+
+Primary job: turn manually verified MCP interactions into reviewable, version-controlled tests with reliable CI outcomes.
+
+## 3. Principles
+
+1. Deterministic checks are hard gates; probabilistic evaluation is optional and separate.
+2. Real transport boundaries matter.
+3. Test files contain data, not arbitrary executable code.
+4. Every wait has a deadline; notification tests use events rather than sleeps.
+5. Reports identify protocol version, transport, capability, skips, and evidence.
+6. Secrets are redacted before any result reaches a reporter.
+7. “Conformance” always names an exact versioned profile and never implies certification.
+
+## 4. MVP scope
+
+### Included
+
+- Node.js 20+, TypeScript, ESM
+- YAML and JSON suites
+- stdio subprocess and Streamable HTTP targets
+- one isolated MCP session per test
+- generic MCP requests
+- captures and variable substitution
+- exact, negative, existence, type, subset, length, and regex assertions
+- expected MCP errors
+- per-step deadlines
+- terminal, JSON, and JUnit output
+- CLI filtering and deterministic exit codes
+- TypeScript library API
+
+### Deferred
+
+- notification queues and progress assertions
+- JSON Schema output matcher
+- snapshots and record/replay
+- setup/teardown fixtures and shared sessions
+- official-conformance adapter and versioned packs
+- OAuth browser flows
+- plugin API, custom reporters, and custom transports
+- fuzzing and security packs
+- retries, parallel/distributed execution, GUI, and LLM judges
+
+## 5. Suite model
+
+A suite has `version`, optional `name`, one target, defaults, and tests. A test contains sequential steps. Each step sends one request, applies assertions, then captures response leaves.
+
+Variables:
+
+- `${captureName}` references a test-local captured value.
+- `${env.NAME}` references an environment value.
+- An exact placeholder preserves its JSON type; interpolation into a larger string converts to text.
+- Variables are resolved only in request parameters in the MVP. Target interpolation and centralized secret redaction are required next.
+
+Session isolation is the default because order-independent tests are easier to reproduce. Shared sessions may be added only as an explicit opt-in.
+
+## 6. Architecture
+
+```text
+CLI
+ ├─ suite loader and validator
+ ├─ protocol-neutral runner
+ │   ├─ variable resolver
+ │   ├─ matcher engine
+ │   └─ normalized result model
+ ├─ MCP SDK session
+ │   ├─ stdio adapter
+ │   └─ Streamable HTTP adapter
+ └─ reporters
+     ├─ terminal
+     ├─ JSON
+     └─ JUnit XML
+```
+
+The runner depends on a small `TestSession` interface so fixture sessions and future raw-wire transports can be substituted. The official TypeScript SDK currently performs initialization, protocol validation, framing, and transport lifecycle management.
+
+A future monorepo can split stable boundaries into `core`, `cli`, `transport-stdio`, `transport-http`, `conformance`, `reporters`, and `plugin-api` packages. Keeping one package until those boundaries stabilize reduces premature API commitments.
+
+## 7. Result and failure semantics
+
+Each run records suite status, UTC start time, duration, observed protocol versions, tests, steps, and summary counts. Failures stop the current test after the first failed step but do not stop later tests.
+
+Exit codes:
+
+- `0`: all selected tests passed
+- `1`: one or more behavioral assertions failed
+- `2`: usage, parsing, or configuration invalid
+- `3`: unexpected infrastructure failure
+
+A later version should explicitly distinguish test failure, transport failure, cleanup failure, skipped capability, not applicable, and inconclusive.
+
+## 8. Conformance roadmap
+
+Versioned profiles should be independently released, for example:
+
+```text
+profiles/2025-03-26/lifecycle
+profiles/2025-03-26/tools
+profiles/2025-03-26/resources
+profiles/2025-03-26/prompts
+profiles/2025-03-26/streamable-http
+```
+
+Checks should include initialization/version negotiation, declared capability behavior, required response/error shapes, ping, cancellation, pagination, progress, logging, subscriptions, unknown methods, invalid parameters, HTTP session IDs, media types, reconnect, and termination.
+
+Report statuses must include pass, fail, capability-skipped, not-applicable, and inconclusive. Integrate official MCP Conformance as a separately pinned run and merge evidence rather than duplicating or rebranding it.
+
+## 9. Security requirements
+
+Before a public beta:
+
+- interpolate target environment and headers without writing secrets into results
+- centralize recursive key/value redaction before reporters
+- cap response, stderr, and report sizes
+- guard regex complexity or document trust assumptions
+- avoid shell command strings; continue using command plus argument arrays
+- ensure bounded graceful subprocess shutdown with force-kill fallback
+- sanitize JUnit and terminal control characters
+- provide opt-in environment inheritance and document its threat model
+
+Security scanners should be integrations. MCP Rigor’s core identity remains functional and protocol-aware testing.
+
+## 10. Release roadmap
+
+### 0.1 — executable MVP
+
+Core runner, YAML/JSON suites, stdio/HTTP through official SDK, deterministic matchers, captures, CLI, JSON/JUnit, tests, and docs.
+
+### 0.2 — CI reliability
+
+Published JSON Schema, complete config validation with Ajv, secret redaction, richer diffs, target interpolation, robust transport classification, GitHub Action, Windows/macOS/Linux CI, and deterministic fixture servers.
+
+### 0.3 — MCP-native behavior
+
+Notification/event queues, progress and cancellation, pagination helpers, capability requirements, resource subscriptions, logging assertions, JSON Schema matcher, traces, snapshots, and record/sanitize/replay.
+
+### 0.4 — ecosystem
+
+Versioned conformance profiles, official conformance aggregation, plugin API, reusable fixture packs, security/fuzz hooks, and adapters for common MCP frameworks.
+
+### 1.0 criteria
+
+Stable suite schema and TypeScript API, two supported protocol revisions, robust process cleanup on three operating systems, transport/auth documentation, migration policy, plugin compatibility policy, reproducible fixture matrix, and no high-severity secret leakage paths.
+
+## 11. Open-source operating model
+
+- Apache-2.0 for broad individual and enterprise use.
+- Public RFCs for schema or plugin-breaking changes.
+- Conventional changesets and a compatibility table per release.
+- `good first issue` fixtures and matcher additions.
+- Governance should clearly document project ownership, maintainership, and vendor neutrality.
+- Reserve project, npm, GitHub organization, and domain names only after registry and trademark checks.
+
+## 12. Success metrics
+
+- time from install to first passing stdio test under ten minutes
+- less than 1% flaky failures in deterministic project fixtures
+- clean teardown across Linux, macOS, and Windows
+- projects running MCP Rigor in CI weekly
+- community-contributed reusable suites and transport fixtures
+- issue resolution time and repeat contributor rate

package/docs/STATE-AND-DEPENDENCIES.md

@@ -0,0 +1,106 @@
+# Passing Outputs Between Tests and Runs
+
+MCP Rigor keeps tests isolated by default. Sharing must be explicit, so test ordering remains understandable.
+
+## Export an output
+
+```text
+Test: "Create customer"
+  Id: create-customer
+
+  Call tool "create_customer" with:
+    name: "Alice"
+
+  Export "structuredContent.id" as "customerId"
+```
+
+An export is captured only after the action and its expectations pass. A missing exported field fails the producer test.
+
+## Depend on the producer
+
+```text
+Test: "Retrieve customer"
+  Id: retrieve-customer
+  Depends on: create-customer
+
+  Call tool "get_customer" with:
+    id: "${deps.create-customer.customerId}"
+
+  Expect "structuredContent.name" equals "Alice"
+```
+
+MCP Rigor builds a dependency graph and runs producers first, regardless of file order.
+
+Rules:
+
+- IDs must be unique.
+- Unknown and circular dependencies fail before any server session opens.
+- All dependencies must pass.
+- If one fails, skips, or is blocked, the consumer is marked **blocked** and its MCP session is never opened.
+- Outputs remain namespaced under the producer ID.
+- Tests without dependencies remain isolated.
+
+## Data-driven producers
+
+Each row has an ID such as `create-customers.us`. Depending on `create-customers` waits for all rows. The consumer receives each exported output as a list in row order:
+
+```text
+Test: "Count all customers"
+  Depends on: create-customers
+
+  Call tool "verify_ids" with:
+    ids: "${deps.create-customers.customerId}"
+```
+
+A failed row blocks the consumer. Depending on one exact row ID is also supported.
+
+## Persist across separate CLI runs
+
+First run:
+
+```bash
+mcprigor test create.mcpr --state-out customer-state.json
+```
+
+A state file is written only when the entire run passes. It contains:
+
+- format version
+- creation time
+- target fingerprint
+- suite fingerprint
+- exported outputs
+- integrity fingerprint
+
+The file is written atomically with owner-only permissions where supported.
+
+Later run:
+
+```bash
+mcprigor test retrieve.mcpr --state-in customer-state.json
+```
+
+Use values through the read-only `state` namespace:
+
+```text
+Call tool "get_customer" with:
+  id: "${state.create-customer.customerId}"
+```
+
+MCP Rigor rejects state created for a different target. After careful review, it can be overridden:
+
+```bash
+mcprigor test retrieve.mcpr \
+  --state-in customer-state.json \
+  --allow-state-target-mismatch
+```
+
+## Security guidance
+
+State files can contain real business data. They are not encrypted.
+
+- Never export passwords, access tokens, private keys, or regulated data.
+- Do not commit state files to source control.
+- Keep state short-lived.
+- Prefer a secret manager for credentials.
+- Treat target-mismatch override as an exceptional migration tool.
+- Redaction protects reports, but internal dependency values remain unredacted so tests can use them correctly.

package/docs/TRANSPORT-PARITY.md

@@ -0,0 +1,98 @@
+# Transport Parity Testing
+
+MCP Rigor can execute the same acceptance suite against named stdio and Streamable HTTP targets, then compare normalized behavior test by test.
+
+## Plain-language parity for QA teams
+
+Create `calculator-parity.mcpr`:
+
+```text
+MCP Test 1
+
+Suite: "Calculator behaves the same everywhere"
+
+Compare target "Local": node server.js
+Compare target "QA environment": https://qa.example.com/mcp
+
+Test: "Adding 20 and 22 gives 42"
+  Id: adding-numbers
+
+  Call tool "add" with:
+    a: 20
+    b: 22
+
+  Expect "structuredContent.sum" equals 42
+
+Test: "The service status is ready"
+  Id: service-status
+
+  Read resource "service://status"
+  Expect "contents[0].text" contains "ready"
+```
+
+Run it exactly like a YAML parity suite:
+
+```bash
+mcprigor parity calculator-parity.mcpr
+```
+
+The `Compare target` lines are usually configured once by an engineer. QA authors only add ordinary `Test`, `Call tool`, `Read resource`, and `Expect` statements. Each test automatically runs against every named target.
+
+A target value beginning with `http://` or `https://` is Streamable HTTP. Any other value is parsed as a stdio command.
+
+## YAML alternative
+
+Automation engineers may also use the structured YAML representation:
+
+```yaml
+version: 1
+name: Calculator parity
+
+target: &default
+  transport: stdio
+  command: node
+  args: [server.js]
+
+targets:
+  stdio:
+    transport: stdio
+    command: node
+    args: [server.js]
+  deployed:
+    transport: streamable-http
+    url: https://staging.example.com/mcp
+
+tests:
+  - id: add
+    name: Addition is consistent
+    steps:
+      - tool:
+          name: add
+          arguments: { a: 20, b: 22 }
+        assert:
+          json:
+            path: $.structuredContent.sum
+            equals: 42
+```
+
+Run the matrix:
+
+```bash
+mcprigor parity parity.yaml
+mcprigor parity parity.yaml --markdown --out parity.md
+```
+
+The first named target is the baseline. Every target runs independently with a fresh MCP session. MCP Rigor compares:
+
+- test status;
+- step status and MCP method;
+- normalized response structures;
+- captured/exported outputs.
+
+It excludes durations, elapsed times, timestamps, session IDs, and `_meta` transport details. Application response fields are not ignored.
+
+A divergent test includes a deterministic path-level semantic diff. The command exits `1` when any target differs.
+
+## Scope
+
+Parity means equivalent observable behavior under the selected tests. It does not prove byte-level transport equivalence, identical concurrency behavior, network reliability, authentication parity, or production infrastructure correctness.

package/docs/TROUBLESHOOTING.md

@@ -0,0 +1,199 @@
+# Troubleshooting
+
+Start with:
+
+```bash
+mcprigor check your-tests.mcpr
+```
+
+This catches wording and configuration problems without starting the MCP server.
+
+## The server does not start
+
+Typical category:
+
+```text
+MCP-SPAWN-* [server-spawn]
+```
+
+Check:
+
+1. Run the `Server:` command directly in the same terminal.
+2. Confirm the executable is installed and on `PATH`.
+3. Check `Server options` → `cwd`.
+4. Build the server before running tests.
+5. Confirm required environment variables exist.
+
+## Initialization times out
+
+Typical categories:
+
+```text
+MCP-INIT-* [initialization]
+MCP-TIMEOUT-* [timeout]
+```
+
+Check that the stdio server:
+
+- writes MCP messages only to stdout;
+- writes diagnostics to stderr;
+- does not wait for interactive input;
+- completes MCP initialization;
+- stays running after startup.
+
+For HTTP, verify the URL, authentication, and server logs.
+
+## A field was not found
+
+Example:
+
+```text
+MCP-ASSERT-001 [assertion] $.structuredContent.id expected to exist
+```
+
+Actions:
+
+- inspect the actual response in JSON or evidence;
+- check capitalization and array indexes;
+- use `content[0].text` for text results;
+- use `structuredContent.field` for structured tool output;
+- avoid adding `result.` because paths begin at the returned result.
+
+## Expected number, received text
+
+Equality is type-sensitive:
+
+```text
+Expect "structuredContent.total" equals 2
+```
+
+is different from:
+
+```text
+Expect "structuredContent.total" equals "2"
+```
+
+Match the server's actual JSON type.
+
+## The test was skipped
+
+`Require` gates a test on server capability or protocol revision:
+
+```text
+Require: tools
+Require protocol: "2025-06-18"
+```
+
+A skip means the server did not advertise the requirement. It is not a test failure.
+
+## The test was blocked
+
+A dependent test is blocked when its producer did not pass:
+
+```text
+Depends on: create-customer
+```
+
+Fix the producer first. MCP Rigor does not open a server session for a blocked consumer.
+
+## Data loading failed
+
+Typical category:
+
+```text
+MCP-DATA-* [data-loading]
+```
+
+Check:
+
+- file path relative to the `.mcpr` file;
+- required column names;
+- number, boolean, date, or JSON values;
+- selected Excel sheet;
+- configured row limit;
+- remote-data permission;
+- remote endpoint returns a JSON array of row objects.
+
+Remote data requires:
+
+```bash
+mcprigor test FILE --allow-remote-data
+```
+
+Private and local network destinations are rejected.
+
+## An extension failed
+
+Typical category:
+
+```text
+MCP-EXT-* [extension]
+```
+
+Check:
+
+- `--allow-custom-code` was supplied;
+- module path is in `extensions.allowlist` when configured;
+- manifest declares the function/provider;
+- requested permissions are granted;
+- input and output are JSON-compatible;
+- extension finishes before its timeout.
+
+## Snapshot changed
+
+Review the path-level diff. If the change is expected:
+
+```bash
+mcprigor test FILE --snapshot snapshots.json --update-snapshots
+```
+
+Never update snapshots automatically in CI. Commit and review changed expectations.
+
+## Transport parity differs
+
+A parity failure can mean:
+
+- different server versions;
+- different fixture data;
+- missing capabilities;
+- a real stdio/HTTP implementation difference;
+- volatile application fields that need an explicit snapshot policy.
+
+Compare the path-level difference and verify both environments use equivalent test data.
+
+## Cleanup failed
+
+Typical category:
+
+```text
+MCP-CLEANUP-* [cleanup]
+```
+
+Make cleanup operations idempotent. A delete should safely handle an item that is already absent. Check that server child processes stop when stdin closes and do not leave descendants running.
+
+## Ctrl+C does not return immediately
+
+MCP Rigor first closes active MCP clients and transports. The pinned SDK gives stdio servers a graceful shutdown window before escalation. If a server creates child processes, the server must also shut them down.
+
+## Collect useful evidence
+
+```bash
+mcprigor test FILE --evidence .mcprigor/debug-run --json result.json
+mcprigor evidence-show .mcprigor/debug-run
+```
+
+Before sharing evidence, review it for sensitive business data. Secret redaction does not remove all possible customer content.
+
+## Reporting a framework bug
+
+Include:
+
+- MCP Rigor version;
+- Node and operating-system version;
+- transport type;
+- protocol revision if known;
+- stable error code/category;
+- smallest sanitized `.mcpr` test;
+- sanitized evidence or result JSON.
+
+Do not include credentials or regulated data.

package/editors/mcpr-language.json

@@ -0,0 +1,16 @@
+{
+  "$schema": "https://raw.githubusercontent.com/martinring/tmlanguage/master/tmlanguage.json",
+  "name": "MCP Rigor Language",
+  "scopeName": "source.mcpr",
+  "patterns": [
+    { "match": "^\\s*#.*$", "name": "comment.line.number-sign.mcpr" },
+    { "match": "^MCP Test 1$", "name": "keyword.control.version.mcpr" },
+    { "match": "^\\s*(Suite|Server|Server options|MCP URL|Compare target|Target options for|Default timeout|Redact|Snapshots|Ignore snapshot paths|Client behavior|Import flows from|Flow|Inputs|Outputs|Test|Scenario|Id|Depends on|Require|Require protocol|Variables|Skip|Setup|Steps|Cleanup|Data source):?", "name": "keyword.control.mcpr" },
+    { "match": "^\\s*(Call tool|Read resource|Get prompt|Send|Expect|Save|Export|Set|Use flow|For each row|Wait up to|Wait for notification|Subscribe to resource|Unsubscribe from resource|Set log level|List all|Get task|List tasks|Cancel task|From CSV|From JSON|From YAML|From Excel|From REST|Column|Derive|Keep rows where|Sample|Cache this source)\\b", "name": "keyword.other.mcpr" },
+    { "begin": "\"", "end": "\"", "name": "string.quoted.double.mcpr" },
+    { "begin": "'", "end": "'", "name": "string.quoted.single.mcpr" },
+    { "match": "\\$\\{[^}]+\\}", "name": "variable.other.mcpr" },
+    { "match": "\\b(true|false|null)\\b", "name": "constant.language.mcpr" },
+    { "match": "\\b-?[0-9]+(?:\\.[0-9]+)?\\b", "name": "constant.numeric.mcpr" }
+  ]
+}

package/package.json

@@ -0,0 +1,70 @@
+{
+  "name": "mcprigor",
+  "version": "1.0.0-rc.1",
+  "description": "Plain-language MCP testing with isolated extensions and a local QA workspace",
+  "type": "module",
+  "bin": {
+    "mcprigor": "dist/cli.js"
+  },
+  "main": "./dist/index.js",
+  "types": "./dist/index.d.ts",
+  "exports": {
+    ".": {
+      "types": "./dist/index.d.ts",
+      "import": "./dist/index.js"
+    }
+  },
+  "files": [
+    "dist",
+    "schema",
+    "editors",
+    "docs",
+    "workspace-assets",
+    "README.md",
+    "LICENSE"
+  ],
+  "scripts": {
+    "build": "tsc -p tsconfig.json",
+    "dev": "tsx src/cli.ts",
+    "test": "vitest run",
+    "test:watch": "vitest",
+    "check": "npm run build && npm test"
+  },
+  "keywords": [
+    "mcp",
+    "model-context-protocol",
+    "testing",
+    "qa",
+    "test-automation",
+    "plain-language",
+    "contract-testing",
+    "cli"
+  ],
+  "license": "Apache-2.0",
+  "engines": {
+    "node": ">=20"
+  },
+  "dependencies": {
+    "@modelcontextprotocol/sdk": "1.27.1",
+    "ajv": "^8.18.0",
+    "exceljs": "^4.4.0",
+    "yaml": "^2.8.2"
+  },
+  "overrides": {
+    "uuid": "^11.1.1"
+  },
+  "devDependencies": {
+    "@types/node": "^22.19.15",
+    "tsx": "^4.21.0",
+    "typescript": "^5.9.3",
+    "vitest": "^4.0.18"
+  },
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/FusionOnePlatform/mcprigor.git"
+  },
+  "homepage": "https://mcprigor.com",
+  "bugs": {
+    "url": "https://github.com/FusionOnePlatform/mcprigor/issues"
+  }
+}

package/workspace-assets/app.js

@@ -0,0 +1 @@
+const state={csrf:'',path:'',etag:'',dirty:false};const $=id=>document.getElementById(id);async function api(path,options={}){const headers={...(options.body?{'content-type':'application/json'}:{}),...(options.method&&options.method!=='GET'?{'x-mcp-csrf':state.csrf}:{})};const response=await fetch(path,{...options,headers:{...headers,...options.headers}});const value=await response.json();if(!response.ok)throw new Error(value.error?.message||`HTTP ${response.status}`);return value}async function start(){const boot=await api('/api/v1/bootstrap');state.csrf=boot.csrf;$('workspace').textContent=`Workspace: ${boot.root} · MCP Rigor ${boot.version}`;$('connection').textContent='● Local and ready';await suites()}async function suites(){const value=await api('/api/v1/suites');const nav=$('suites');nav.replaceChildren();for(const suite of value.suites){const button=document.createElement('button');button.textContent=suite.path;button.onclick=()=>open(suite.path,button);nav.append(button)}}async function open(path,button){if(state.dirty&&!confirm('Discard unsaved changes?'))return;const value=await api(`/api/v1/file?path=${encodeURIComponent(path)}`);state.path=path;state.etag=value.etag;state.dirty=false;$('editor').value=value.text;$('dirty').textContent='';document.querySelectorAll('nav button').forEach(x=>x.classList.remove('active'));button.classList.add('active');$('diagnostics').textContent=`Opened ${path}`}async function save(){if(!state.path)return;const value=await api('/api/v1/file',{method:'PUT',body:JSON.stringify({path:state.path,text:$('editor').value,etag:state.etag})});state.etag=value.etag;state.dirty=false;$('dirty').textContent='';$('diagnostics').textContent='Saved'}async function validate(){if(state.dirty)await save();const value=await api('/api/v1/validate',{method:'POST',body:JSON.stringify({path:state.path})});$('diagnostics').textContent=value.valid?`✓ Valid · ${value.suite.tests} tests${value.suite.parityTargets.length?` · ${value.suite.parityTargets.length} parity targets`:''}`:value.diagnostics.map(x=>x.message).join('\n')}async function run(mode){if(state.dirty)await save();$('output').textContent='Starting…';const value=await api('/api/v1/runs',{method:'POST',body:JSON.stringify({path:state.path,mode})});const poll=setInterval(async()=>{try{const result=await api(`/api/v1/runs/${value.runId}`);$('output').textContent=result.output;if(result.status!=='running'){clearInterval(poll);$('diagnostics').textContent=result.status==='passed'?'✓ Run passed':'✗ Run failed'}}catch(error){clearInterval(poll);$('output').textContent=error.message}},500)}$('editor').addEventListener('input',()=>{state.dirty=true;$('dirty').textContent='● Unsaved'});$('save').onclick=()=>save().catch(show);$('validate').onclick=()=>validate().catch(show);$('run').onclick=()=>run('test').catch(show);$('parity').onclick=()=>run('parity').catch(show);$('refresh').onclick=()=>suites().catch(show);function show(error){$('diagnostics').textContent=error.message}start().catch(show);

package/workspace-assets/index.html

@@ -0,0 +1 @@
+<!doctype html><html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width"><title>MCP Rigor QA Workspace</title><link rel="stylesheet" href="/style.css"></head><body><header><div><strong>MCP Rigor</strong><span>QA Workspace</span></div><div id="connection">Connecting…</div></header><main><aside><button id="refresh">↻ Refresh suites</button><nav id="suites" aria-label="Test suites"></nav></aside><section class="workbench"><div class="toolbar"><button id="save">Save</button><button id="validate">Validate</button><button id="run">Run tests</button><button id="parity">Run parity</button><span id="dirty"></span></div><textarea id="editor" spellcheck="false" aria-label="Plain-language MCP test editor" placeholder="Select a suite or create a .mcp file in your workspace"></textarea><div id="diagnostics" role="status" aria-live="polite"></div></section><aside class="results"><h2>Run results</h2><pre id="output">No run yet.</pre></aside></main><footer><span id="workspace"></span><span>Plain language and YAML share one runtime model</span></footer><script type="module" src="/app.js"></script></body></html>

package/workspace-assets/style.css

@@ -0,0 +1 @@
+:root{font:15px/1.5 Inter,ui-sans-serif,system-ui;color:#15231d;background:#edf3ef}*{box-sizing:border-box}body{margin:0;height:100vh;display:grid;grid-template-rows:58px 1fr 34px}header,footer{display:flex;align-items:center;justify-content:space-between;padding:0 22px;background:#10291f;color:#e7fff4}header strong{font-size:20px;margin-right:12px}header span,footer{color:#a9cbbb}main{display:grid;grid-template-columns:230px minmax(400px,1fr) minmax(300px,38%);min-height:0}aside{padding:14px;border-right:1px solid #c7d5cd;background:#f7faf8;overflow:auto}.results{border:0;border-left:1px solid #c7d5cd;background:#102019;color:#dff4e8}.results h2{font-size:14px;text-transform:uppercase;letter-spacing:.08em}.workbench{display:grid;grid-template-rows:52px 1fr auto;min-width:0}.toolbar{display:flex;align-items:center;gap:8px;padding:9px 14px;background:white;border-bottom:1px solid #c7d5cd}button{border:1px solid #7d9b8b;border-radius:7px;padding:7px 11px;background:white;color:#173c2c;cursor:pointer}button:hover,button:focus{background:#dff3e7;outline:2px solid transparent}nav button{display:block;width:100%;text-align:left;margin:5px 0;overflow:hidden;text-overflow:ellipsis}nav button.active{background:#bde6cc;border-color:#238653}textarea{resize:none;border:0;padding:20px;font:14px/1.65 ui-monospace,SFMono-Regular,Menlo,monospace;outline:none;color:#17221d;tab-size:2}#diagnostics{padding:8px 14px;min-height:38px;background:#fff8df;color:#6a4c00;white-space:pre-wrap}pre{white-space:pre-wrap;word-break:break-word;font:13px/1.55 ui-monospace;padding:8px 0}footer{font-size:12px}#dirty{color:#aa5b00}@media(max-width:900px){main{grid-template-columns:180px 1fr}.results{display:none}}@media(max-width:620px){main{grid-template-columns:1fr}main>aside:first-child{max-height:150px;border-bottom:1px solid #ccc}.workbench{min-height:500px}}