Before you start
Problem / motivation
A delegated task may produce a non-empty report.json whose contents cannot be parsed as JSON. The current file existence, non-empty and read-back conditions do not express JSON syntax validity. An agent can run a Python or shell check itself, but every delegation must recreate the command, path rules, read limits and interpretation of incomplete evidence.
This proposal adds a deterministic, advisory syntax result to the existing acceptance checklist. It does not claim a production incident or measured improvement in agent success rates.
Proposed solution
Allow an explicit criterion such as file:../outputs/report.json json-valid on task and durable batch_task items. Do not automatically inspect .json files or change existing criterion semantics.
Acceptance criteria:
- A complete UTF-8 JSON document of at most 50,000 bytes produces checked=true, holds=true.
- A complete invalid document, including an empty file or the non-standard NaN/Infinity/-Infinity constants, produces checked=true, holds=false.
- Over-limit files, incomplete reads, unavailable probes/transport and parser resource limits remain UNVERIFIED. A truncated prefix must never produce a syntax verdict.
- A proven missing file produces a negative result; inaccessible or out-of-scope paths remain uncertain under the existing shared-workspace contract.
- Reads are bounded at the source, including growth after a size probe. Local and remote sandbox paths retain containment rules. Remote transport completion is checked.
- Scalars and duplicate keys are accepted as syntax; Schema validation, required business fields, semantic correctness, repairs, LLM judging and automatic retries are excluded.
- Existing conditions, result metadata and execution status remain compatible; the new family shares sandbox admission with existing file conditions.
- Tests cover valid/invalid/empty files, exact and over-limit sizes, incomplete reads, containment, local and real-shell remote paths, and old-rule compatibility.
Affected area(s)
Agents / LangGraph; Sandbox; Docs.
Alternatives considered
Agent-authored bash/Python validation remains useful for arbitrary or larger checks. The built-in condition provides one deterministic result shape, common path/read boundaries and an explicit uncertainty state. A JSON Schema validator or LLM judge would introduce a different contract and is out of scope.
Additional context
Related background: RFC #4651. Its author dropped the optional LLM judge PR5 to retain a simpler architecture; this proposal extends only Layer 2. PR #5559 has merged and fixes remote empty-file detection; its behavior is part of the implementation baseline.
The 50,000-byte cap limits this check's resource use; it is not a deliverable-size requirement. Larger files remain UNVERIFIED rather than being declared invalid. Feedback on the criterion and cap is welcome; maintainer scope alignment remains pending.
Before you start
Problem / motivation
A delegated task may produce a non-empty report.json whose contents cannot be parsed as JSON. The current file existence, non-empty and read-back conditions do not express JSON syntax validity. An agent can run a Python or shell check itself, but every delegation must recreate the command, path rules, read limits and interpretation of incomplete evidence.
This proposal adds a deterministic, advisory syntax result to the existing acceptance checklist. It does not claim a production incident or measured improvement in agent success rates.
Proposed solution
Allow an explicit criterion such as
file:../outputs/report.json json-validon task and durable batch_task items. Do not automatically inspect .json files or change existing criterion semantics.Acceptance criteria:
Affected area(s)
Agents / LangGraph; Sandbox; Docs.
Alternatives considered
Agent-authored bash/Python validation remains useful for arbitrary or larger checks. The built-in condition provides one deterministic result shape, common path/read boundaries and an explicit uncertainty state. A JSON Schema validator or LLM judge would introduce a different contract and is out of scope.
Additional context
Related background: RFC #4651. Its author dropped the optional LLM judge PR5 to retain a simpler architecture; this proposal extends only Layer 2. PR #5559 has merged and fixes remote empty-file detection; its behavior is part of the implementation baseline.
The 50,000-byte cap limits this check's resource use; it is not a deliverable-size requirement. Larger files remain UNVERIFIED rather than being declared invalid. Feedback on the criterion and cap is welcome; maintainer scope alignment remains pending.