Schema validation mode is stringly-typed: unknown modes (including 'error') silently degrade to warn

[phernandez]

Problem

Setting settings.validation: error on a schema does not enforce anything: a note missing a required field still validates with passed: true, warning_count: 1, error_count: 0. Observed during the development MCP acceptance run mcp-acceptance-20260810T031527Z (schemas phase FAIL) against cloud revision 28213b84 / core 940acff6, and reproducible from the code alone.

Root cause

The validation mode is a stringly-typed open value with no boundary validation, and unknown modes silently behave as warn:

• src/basic_memory/picoschema/parser.py:309 (and resolver.py:89): validation_mode = settings.get("validation", "warn") — accepts any string verbatim into a field documented only by comment as "warn" | "strict" | "off" (parser.py:55).
• src/basic_memory/picoschema/validator.py:105/113/130: escalation to errors happens only on the literal validation_mode == "strict"; every other value — including error — falls into the warnings branch.

So validation: error (a natural spelling a user or runbook reaches for) is silently accepted and silently unenforced. For a validation setting, silent lenience on an unrecognized mode is the worst failure direction.

Fix direction (Constructive Domain Modeling)

Model the mode as a closed vocabulary constructed at the boundary:

1. validation_mode becomes a closed type (Literal["warn", "strict", "off"] / parsed enum), not str.
2. The parser rejects unknown values explicitly — a schema declaring validation: banana (or error, if not adopted) surfaces a parse/validation error on the schema itself instead of silently degrading.
3. Product decision inside the fix: either accept error as a documented alias of strict (it is the spelling the acceptance runbook and at least one user-facing flow used), or reject it with a message naming the accepted values. Pick one canonical vocabulary and align docs/runbook.

Acceptance criteria

• A note missing a required field under strict/error mode returns passed: false with error_count >= 1.
• An unknown settings.validation value is rejected at schema parse/definition time with the accepted vocabulary named — never silently treated as warn.
• The warn and off behaviors are unchanged and pinned by tests.
• Docs and the cloud acceptance runbook use the canonical vocabulary.
• The cloud development MCP acceptance schemas phase passes against a build carrying this fix.

[claude]

Claude finished @phernandez's task in 44s —— View job

---

Triage

Type: Bug — confirmed against source. parser.py:309 (validation_mode = settings.get("validation", "warn")) and resolver.py:89 accept any string with no boundary validation, and validator.py:105/113/130 only escalate to errors on the literal == "strict". Any other value, including error, silently falls into the warnings branch — settings.validation: error is accepted and unenforced exactly as described.

Priority: High — a validation mode that silently fails open defeats the purpose of settings.validation: error/strict for any schema relying on it, and the issue reports it's currently blocking the cloud MCP acceptance run.

Component: Core (src/basic_memory/picoschema/ — parser.py, resolver.py, validator.py). Not cloud-specific: the bug is fully reproducible from the core code alone, even though it was surfaced via a cloud acceptance run.

Complexity: Medium — the fix itself (closing validation_mode to a Literal/enum, rejecting unknown values at parse time, deciding whether error is a documented alias of strict) is contained to a few files, but it touches a schema-definition-time behavior change (previously-silent bad values now raise) and needs test coverage for warn/off/strict plus the new rejection path, and doc/runbook alignment per the acceptance criteria.

No duplicate issues found in this repo.

Labels applied: bug (unchanged), component recorded as core/none per the triage taxonomy (not cloud-labeled).