You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Workspai publishes a generated runtime command inventory, but inventory parity
alone does not prove that every JSON command keeps stdout clean or that JSON,
events, persisted artifacts, and exit codes report the same outcome.
Proposed solution
Current foundation
runtime-command-surface.v1.json and generated inventory snapshots;
workspai commands --json and command-surface verification;
versioned operational JSON schemas and event contracts;
targeted machine-output, cancellation, and observability tests;
versioned PCC operation/capsule and Live Board projections exercised by
isolated real-world qualification.
Remaining work
Drive one conformance harness from the runtime surface. For each JSON-capable
command, capture stdout, stderr, exit code, events, and persisted result, then
compare their semantic verdict and diagnostics.
Acceptance criteria
Every public JSON-capable command is discovered from the runtime surface.
JSON mode emits one documented JSON value or JSONL stream on stdout.
Progress/debug/human text cannot contaminate machine stdout.
Success, attention, blocked, unsupported, cancelled, and internal failure have stable exit families.
JSON, event, persisted artifact, and human rendering preserve one verdict/scope.
Diagnostics are bounded, stable, structured, and secret-safe.
New commands must join the inventory and conformance matrix.
Completion evidence
Publish a per-command conformance report and pass it on Linux, macOS, and Windows.
The report must name the exact command/projection mismatch rather than only a raw log.
Alternatives considered
The following alternatives or adjacent concerns are intentionally outside this issue:
parsing human help/output as a consumer contract;
forcing all commands into one payload schema;
breaking existing exit behavior without migration fixtures.
Expected impact
CI, IDEs, MCP, and agents can consume every declared machine command without
parsing human output or guessing whether a partial failure was successful.
Problem statement
Workspai publishes a generated runtime command inventory, but inventory parity
alone does not prove that every JSON command keeps stdout clean or that JSON,
events, persisted artifacts, and exit codes report the same outcome.
Proposed solution
Current foundation
runtime-command-surface.v1.jsonand generated inventory snapshots;workspai commands --jsonand command-surface verification;isolated real-world qualification.
Remaining work
Drive one conformance harness from the runtime surface. For each JSON-capable
command, capture stdout, stderr, exit code, events, and persisted result, then
compare their semantic verdict and diagnostics.
Acceptance criteria
Completion evidence
Publish a per-command conformance report and pass it on Linux, macOS, and Windows.
The report must name the exact command/projection mismatch rather than only a raw log.
Alternatives considered
The following alternatives or adjacent concerns are intentionally outside this issue:
Expected impact
CI, IDEs, MCP, and agents can consume every declared machine command without
parsing human output or guessing whether a partial failure was successful.