Cover the non-empty-string floor in the structural corpus

[kikashy]

Goal

Add structural cases for members the schema requires to be non-empty strings. Today no fixture in the repository contains an empty string anywhere.

Why

The schema has one shared definition for this, and refers to it twenty-two times:

"nonEmptyString": {
  "type": "string",
  "minLength": 1
}

It governs title, description, decision.intent, decision.question, every outcome label, sources[].locator.value, escalation.target.name, metadata.license, and more. Core says the same in prose — the §4 root table calls title a "Non-empty human-readable title", and §6.1 says of decision.intent and decision.question that "Both are required human-readable strings."

Nothing tests it. grep -rn '""' conformance/carrier conformance/structural conformance/semantic conformance/valid conformance/evaluation/packs examples returns no matches: the corpus contains no empty string at all, and grep -c JPS-STRUCTURE-MINLENGTH conformance/manifest.json returns 0.

That gap has a specific shape. The corpus already has structural/missing-decision.json for an absent required member, so an implementation that checks presence — "title" in document — passes every case in the corpus while accepting "title": "". An empty title is a member that is there and says nothing, which is exactly the failure a presence check cannot see.

The repository's validator reports a single diagnostic for these, JPS-STRUCTURE-MINLENGTH at the offending pointer.

Scope

• Add fixtures under conformance/structural/ for at least: an empty root title, an empty decision.question, an empty outcome label, an empty sources[].locator.value, and an empty escalation.target.name.
• Add one conformance/manifest.json entry per fixture: layer: "structural", expectedResult: "invalid", the code and pointer the repository's validator reports, and the section that states the requirement (§4 for the root members, §6.3 and §6.7 for the nested ones).
• Leave the root id out of this issue. An empty id fails the uri format assertion as well as minLength, so it produces two diagnostics and muddies the single primary expectation each case is supposed to carry.
• Update the document-corpus count statements; a harness test derives the number and its failure message names each stale one.
• Do not change the schema, spec/judgment-pack-core.md, or any existing fixture or case.

Acceptance criteria

• Each listed member has a fixture whose only defect is the empty string, plus a manifest entry.
• Diagnostics match what the validator reports; run the suite rather than guessing.
• The corpus count statements match the manifest again.
• python -m pip install -r requirements-dev.txt then python -m unittest discover -s tests -v passes.
• Every commit includes a DCO sign-off created with git commit -s.

Contributor learning

The difference between a member being present and a member carrying meaning, and why a conformance corpus tests the second one explicitly.

[Jeevika1917]

Hello! I would be very interested in working on this problem for my next open-source contribution. I would like to find out more about the conformance tests. Thank you!

[kikashy]

Welcome — it's yours, and this is a good first one; assigned.

How conformance works in this repository, since you asked: the corpus under conformance/ is pure data — JSON fixtures grouped by what they exercise (structural/, carrier/, semantic/, evaluation/, valid/) plus manifest.json, which registers every case and is what implementations actually run. Nothing here executes packs; implementations elsewhere (the Go runtime, the Python evaluator) pull this corpus and replay the manifest, which is why a well-formed new case makes every implementation stricter at once. conformance/README.md describes the case layout, and this issue's Why section shows the exact schema floor (nonEmptyString) your cases will pin.

To work on it locally:

python3 -m pip install -r requirements-dev.txt
python3 -m unittest discover -s tests -v

That second command is what CI runs — it validates the corpus artifacts, including that your new cases are well-formed and registered in manifest.json.

The issue's acceptance checklist is the definition of done, including one habit this organization asks of every commit: a DCO sign-off, created with git commit -s. Ask anything here on the issue as you go — questions are welcome.