[GH-ISSUE #100] Complete actionable output schemas, structured results, and typed error details #66

Closed
opened 2026-10-15 18:20:44 +00:00 by bsakaguchi · 0 comments
Owner

Originally created by @morluto on GitHub (Jul 13, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/100

Summary

Finish the structured CLI/MCP contract work begun in REA 1.3.0 by preserving actionable, machine-readable error details consistently across tools and command surfaces.

The successful-result portion is largely shipped. The remaining work is error detail fidelity, permission remediation, cross-surface consistency, and validation that every contract remains precise.

Shipped in REA 1.3.0

  • Tool registrations publish outputSchema.
  • Successful values are validated before return.
  • Successful MCP calls return structuredContent.
  • Expected errors expose provider-neutral category and message fields.
  • Tool contract helpers centralize schema and annotations.
  • Package verification exercises the MCP catalog.

Implementation evidence includes PR #107 and the 1.3.0 release.

Remaining problem

The current safe error projection can discard evidence required to diagnose local artifacts. Example: direct ASAR inventory reduces an integrity mismatch to category plus generic remediation, removing:

  • logical entry path;
  • declared SHA-256;
  • calculated SHA-256;
  • embedded versus unpacked state.

The same underlying failure remains verbose through investigate-versions, so CLI surfaces are inconsistent. See #111.

Permission failures also need structured requested/allowed scope and remediation rather than generic disabled/outside-root messages.

Proposed error contract

Define a stable discriminated envelope containing code, category, safe message, retryability, per-code details, and structured remediation. Integrity details should include logical_path, declared_sha256, calculated_sha256, and unpacked.

Not every error needs every field. Each error code should have its own schema.

Suggested families:

  • invalid_request;
  • permission_required;
  • capability_unavailable;
  • provider_unavailable;
  • provider_timeout;
  • cancelled;
  • artifact_integrity_mismatch;
  • evidence_integrity_mismatch;
  • truncated;
  • process_capture_failed;
  • cleanup_incomplete;
  • revision_conflict;
  • outside_approved_root.

Redaction policy

Preserve evidence needed for local reproducibility:

  • hashes;
  • addresses;
  • artifact-relative paths;
  • entry types;
  • provider IDs;
  • classifications;
  • limits and truncation state.

Continue redacting:

  • tokens and credentials;
  • authorization headers;
  • environment values;
  • captured secret content;
  • raw subprocess output not explicitly approved.

If absolute paths require protection, use stable aliases or an explicit path-redaction policy rather than deleting identity-bearing details.

Permission error details

A permission_required result should identify:

  • capability requested;
  • requested executable/working/evidence/input roots as aliases or safe paths;
  • requested environment names, never values;
  • requested network mode;
  • active policy ceiling;
  • whether elicitation is supported;
  • exact configuration or retry action;
  • whether restart is required.

Acceptance criteria

  • Every registered MCP tool has an output schema.
  • Successful structuredContent validates against its schema.
  • Expected operational errors have stable discriminated codes and per-code detail schemas.
  • ASAR integrity mismatch includes logical path, declared/calculated digest, and unpacked state in CLI and MCP.
  • Permission errors identify missing scope and actionable remediation.
  • Cleanup, cancellation, truncation, and revision conflicts retain their distinct typed details.
  • CLI, MCP, direct inventory, and investigate-versions project the same underlying error consistently.
  • --full-output never contains less diagnostic information than normal structured output.
  • Text content remains concise and compatible while structuredContent retains details.
  • Sensitive values remain redacted without removing reproducibility metadata.
  • Contract tests validate every success and error variant across CLI and MCP.
  • Generated schemas/documentation identify error variants clients may handle.

Non-goals

  • Returning raw provider stack traces.
  • Exposing subprocess stderr indiscriminately.
  • Treating every programmer defect as a recoverable operational error.
  • Silently accepting integrity mismatches.

Relationships

  • #111 is the concrete diagnostic-loss regression and redaction-policy case.
  • #96 defines interactive permission grants.
  • #99 may expose large diagnostic evidence through resources.
Originally created by @morluto on GitHub (Jul 13, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/100 ## Summary Finish the structured CLI/MCP contract work begun in REA 1.3.0 by preserving actionable, machine-readable error details consistently across tools and command surfaces. The successful-result portion is largely shipped. The remaining work is error detail fidelity, permission remediation, cross-surface consistency, and validation that every contract remains precise. ## Shipped in REA 1.3.0 - [x] Tool registrations publish outputSchema. - [x] Successful values are validated before return. - [x] Successful MCP calls return structuredContent. - [x] Expected errors expose provider-neutral category and message fields. - [x] Tool contract helpers centralize schema and annotations. - [x] Package verification exercises the MCP catalog. Implementation evidence includes PR #107 and the 1.3.0 release. ## Remaining problem The current safe error projection can discard evidence required to diagnose local artifacts. Example: direct ASAR inventory reduces an integrity mismatch to category plus generic remediation, removing: - logical entry path; - declared SHA-256; - calculated SHA-256; - embedded versus unpacked state. The same underlying failure remains verbose through investigate-versions, so CLI surfaces are inconsistent. See #111. Permission failures also need structured requested/allowed scope and remediation rather than generic disabled/outside-root messages. ## Proposed error contract Define a stable discriminated envelope containing code, category, safe message, retryability, per-code details, and structured remediation. Integrity details should include logical_path, declared_sha256, calculated_sha256, and unpacked. Not every error needs every field. Each error code should have its own schema. Suggested families: - invalid_request; - permission_required; - capability_unavailable; - provider_unavailable; - provider_timeout; - cancelled; - artifact_integrity_mismatch; - evidence_integrity_mismatch; - truncated; - process_capture_failed; - cleanup_incomplete; - revision_conflict; - outside_approved_root. ## Redaction policy Preserve evidence needed for local reproducibility: - hashes; - addresses; - artifact-relative paths; - entry types; - provider IDs; - classifications; - limits and truncation state. Continue redacting: - tokens and credentials; - authorization headers; - environment values; - captured secret content; - raw subprocess output not explicitly approved. If absolute paths require protection, use stable aliases or an explicit path-redaction policy rather than deleting identity-bearing details. ## Permission error details A permission_required result should identify: - capability requested; - requested executable/working/evidence/input roots as aliases or safe paths; - requested environment names, never values; - requested network mode; - active policy ceiling; - whether elicitation is supported; - exact configuration or retry action; - whether restart is required. ## Acceptance criteria - [x] Every registered MCP tool has an output schema. - [x] Successful structuredContent validates against its schema. - [ ] Expected operational errors have stable discriminated codes and per-code detail schemas. - [ ] ASAR integrity mismatch includes logical path, declared/calculated digest, and unpacked state in CLI and MCP. - [ ] Permission errors identify missing scope and actionable remediation. - [ ] Cleanup, cancellation, truncation, and revision conflicts retain their distinct typed details. - [ ] CLI, MCP, direct inventory, and investigate-versions project the same underlying error consistently. - [ ] --full-output never contains less diagnostic information than normal structured output. - [ ] Text content remains concise and compatible while structuredContent retains details. - [ ] Sensitive values remain redacted without removing reproducibility metadata. - [ ] Contract tests validate every success and error variant across CLI and MCP. - [ ] Generated schemas/documentation identify error variants clients may handle. ## Non-goals - Returning raw provider stack traces. - Exposing subprocess stderr indiscriminately. - Treating every programmer defect as a recoverable operational error. - Silently accepting integrity mismatches. ## Relationships - #111 is the concrete diagnostic-loss regression and redaction-policy case. - #96 defines interactive permission grants. - #99 may expose large diagnostic evidence through resources.
bsakaguchi 2026-10-15 18:20:44 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
morluto/rea#66
No description provided.