D2: vendor config schema, all 12 entries, validator-as-test, consistency tests

[open-coder-ai]

What this changes

Implements wave D2 of docs/design/dialect-families.md: src/agentseam/data/vendors/schema.json plus one data/vendors/<agent>.json per adapted agent, a recount script, a stdlib-only validator run as a test, and the §3.3 consistency tests. The runtime does not read this data yet (D3+ wires an engine onto it) — this PR's correctness bar is "entries recount against the adapters" and "schema tests green," per the design's own D2 exit criteria.

Verified W35's ACS vocabulary (ESCALATE/TRANSFORM/WARN in contract.py) is on main before writing a single schema word, per the brief's binding constraint.

Recounted, not transcribed. tools/recount_vendor_config.py (a thin orchestrator over the tools/recount/ package) derives every field by executing or AST-reading the current adapter and its D1 golden fixture:

• module constants (EVENT_MAP, DECISION_VOCABULARY, WRITE_TOOLS, ...) read directly
• parse()'s ordered field-fallback chains AST-walked (three vendors whose parse() doesn't fit the generic ti.get(...) or ... shape get a small, cited override)
• each gate's grammar / honours_ask / honours_rewrite replayed straight out of the frozen (payload → stdout) wire truth D1 captured — including cursor's five wire-name variants of pre_tool, whose own golden fixture only exercises one (preToolUse); the other four are recounted by re-running the real dispatcher against the same frozen payload with hook_event_name swapped
• hook_config()'s wrapper shape and whether matcher does anything, the same way

Family assignment and the marker-based claims table are the design's own stated judgment calls (§2.2, §3.1), recorded as small tables and pinned by tests/test_vendor_config_claims.py, which mutates a real claimed payload per declared marker/client_type and replays claims() — a wrong marker fails the test.

Per-claim evidence (owner decision 2026-09-01, plan/agentseam-project.md in org-plan) gives every claim group basis/date/test; schema validation fails a claim with none. tools/validate_vendor_config.py is a small stdlib-only JSON Schema subset validator (no new dependency), with a mutation pass — including one benign edit that must still pass — per worker-protocol.md's mutation-testing discipline.

tests/test_vendor_config.py adds the §3.3 consistency tests (config gates are a subset of the matrix's block-capable events; config_path agrees with the matrix — which caught and fixed a stale kimi_code config path in matrix.json) and answers both [h] hypotheses D2 carries (§7): reject_probes stays at one named predicate (looks_like_claude_code) against the ~3-probe budget, and PR #89's tuple-restoring loader is order-safe for fields' order-sensitive chains.

Claim check

• No capability claim is widened without a mechanism behind it — the runtime doesn't read this data yet; every value is recounted against, never wider than, the adapter/matrix it describes
• Any new/changed MATRIX row carries a verified record — only kimi_code's config display field changed (a stale path string), its verified record is untouched
• N/A — no new payload shapes; every entry is derived from existing adapters and the D1 golden fixtures

Checks

• pytest -q passes (1319 passed, 4 skipped, unchanged skip count)
• ruff check . and ruff format --check . pass
• Runtime path is still stdlib-only (data/vendors/*.json added to pyproject.toml package-data)
• Commits are signed off (git commit -s)

Notes for the reviewer

• matrix.json's kimi_code.config was "config.toml", disagreeing with the adapter's real CONFIG_PATH ("~/.kimi-code/config.toml") since before this PR. Fixed as a minimal, targeted correction needed to make the new config_path agrees with the matrix test meaningful; regenerated the two affected example pages (examples/generated/README.md, kimi_code.md) to match.
• The [h] about vscode_copilot's dual-casing (§7) is explicitly D3-scoped in the design ("decide in D3 with the fixtures open") and is untouched here.
• data/vendors/schema.json's evidence map is a deliberate, called-out exception to §3.1's "config may carry strings/booleans/ordered lists/flat maps" line — the schema's own description field says so, and it's the owner's 2026-09-01 addition, not part of the original §3 design.

---

Generated by Claude Code