Reported issues for srdcheck

Pod holds 11 of 11 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to srdcheck.

Most discussed

[P1] Prevent MCP tool proliferation from degrading agent discovery

Problem

The MCP surface already contains 22 tools and grows one tool per mechanic. Similar names and overlapping responsibilities increase tool-selection errors, token cost, and repair loops for agents.

Acceptance criteria

• Measure tool-selection and first-call success across frontier, mid-tier, and local models.
• Compare the current specialized tools with a small capabilities/evaluate/enumerate/explain protocol.
• Preserve specialized schemas where they materially improve accuracy.

Read the thread · 2026-08-01 · closed · 4 comments

[P1] Represent asserted facts, derived rules, and table decisions separately

Problem

Current requests and verdicts do not distinguish caller assertions from facts derived by srdcheck or from DM/table rulings. This makes receipts ambiguous and can turn an incorrect perception/ASR assertion into an authoritative-looking rules result.

Acceptance criteria

• Accept asserted_facts with source and confidence metadata.
• Return facts consumed, facts derived, assumptions, and missing facts separately.
• Keep rule_result distinct from table_decision and state mutation.

Read the thread · 2026-08-01 · closed · 1 comment

SKILL.md states the wrong meaning and handling for exit 2, omitting refusal contract 1.1

SKILL.md:28-30 tells consuming agents:

Exit 2 [...] means the question is outside the loaded rulesets or genuinely up to the DM. Route it to a human ruling; do not retry, rephrase, or guess.

The numeric table is correct — 0 legal / 1 illegal / 2 cannot-adjudicate / 3 usage error all verified against the CLI, --schema, and tool.json. The breach is semantic.

srdcheck's real exit-2 surface is refusal contract 1.1 (srdcheck/verdict.py:73-104), published via `srdcheck capabilitie

Read the thread · 2026-08-18 · open · 0 comments

[P1] Require condition-sensitive facts before confident roll verdicts

Problem

Several condition-sensitive checks return confident roll composition when facts required by the cited rule were omitted.

Examples found in the refusal audit:

• attack.modifiers can assume outcomes without facts about whether a Frightened source is visible, whether a Charmed target is the charmer, grappler relationships, Invisible visibility, or the nearby-enemy census for a ranged attack.
• check.make can assume outcomes without check_requires for Blinded/Deafened or sight of

Read the thread · 2026-08-01 · closed · 0 comments

[P0] Validate event.apply state and conditional event facts

Problem

event.apply accepts state with only { "type": "object" } instead of enforcing the shipped state schema. A schema-valid MCP call containing state.turn = {} and a move event reaches movement_ft_spent and raises KeyError, which becomes an internal tool-execution failure rather than an honest verdict.

Conditional event facts are also defaulted optimistically. A damage event without amount returns exit 0 and records “Takes 0 damage”; a move event without its distance can

Read the thread · 2026-08-01 · closed · 0 comments

[P1] Define and test concurrency and multi-engine behavior

Problem

Lazy module globals, dynamic module names, and adapter loading have no documented behavior under threads, multiple Engine instances, adapters with colliding names, or long-running MCP processes.

Acceptance criteria

• Specify thread-safety and process-lifetime guarantees.
• Remove or safely synchronize mutable module-global caches.
• Prevent dynamic module-name collisions across adapter versions/paths.
• Test concurrent queries, multiple engines, reloads, and long-running server

Read the thread · 2026-08-01 · open · 0 comments

[P1] Define a trust and sandbox model for executable adapters

Problem

Adapters load handlers.py through importlib, which is arbitrary code execution. That is acceptable for explicitly trusted local packages but unsafe for a casual adapter catalog or hosted service.

Acceptance criteria

• Clearly distinguish trusted code adapters from declarative content adapters.
• Add package digest/signature and maintainer identity metadata.
• Show provenance and requested trust before local installation.
• Run untrusted adapters out of process in hosted deployme

Read the thread · 2026-08-01 · open · 0 comments

[P0] Add clean wheel and sdist release CI with registry smoke tests

Problem

No release pipeline proves that a tag builds reproducible artifacts which work after cold installation. The checked-in wheel already demonstrates a repository-versus-package behavior gap.

Acceptance criteria

• Build wheel and sdist from a clean tagged commit in CI.
• Install each outside the repository and run headline CLI, library, and MCP journeys.
• Verify versions, licenses, attribution, file manifest, checksums, SBOM, and build provenance.
• After publishing, install from t

Read the thread · 2026-08-01 · closed · 0 comments

Most recent

[P0] Enforce complete JSON Schema validation at the query boundary

Problem

The engine rejects unknown keys but does not generically enforce required fields, types, enums, numeric bounds, array items, or all nested constraints. Validation remains handler-dependent and inconsistent.

Acceptance criteria

• Validate every request against its declared schema before dispatch.
• Cover required fields, types, enums, bounds, arrays, nested objects, and additionalProperties.
• Return structured invalid-input results without executing handlers.
• Add property/fuzz

Read the thread · 2026-08-01 · closed · 0 comments

[P0] Harden MCP JSON-RPC and protocol compliance

Problem

The MCP server echoes the client protocol version instead of negotiating support, silently drops malformed JSON, lacks complete parse/invalid-request handling, and advertises no output schemas. Strict clients may fail or hang in ambiguous ways.

Acceptance criteria

• Negotiate only supported MCP protocol versions.
• Return correct JSON-RPC parse, invalid-request, invalid-params, and method-not-found errors.
• Advertise and validate output schemas for every tool.
• Sanitize intern

Read the thread · 2026-08-01 · closed · 0 comments

[P0] Establish one canonical engine, adapter, MCP, and metadata version contract

Problem

The release reports conflicting versions: package/server metadata says 0.5.0, MCP SERVER_INFO says 0.2.0, the SRD adapter says 0.2.0, examples mention 1.0.0, and tool.json is stale. Agents and registries cannot determine the active capability contract.

Acceptance criteria

• Make package version the canonical engine build input and report adapter versions separately.
• Add machine-readable capabilities with engine, schema, protocol, adapter version/digest, and tools.
• Generate o

Read the thread · 2026-08-01 · closed · 0 comments

The remaining reports are on the project's issue tracker.