[google-labs-jules]

Context

In our current orchestration flow, the orchestrator layer fails to monitor sub-process exit codes from spawned asset tools. This lack of error propagation often causes the system to report false successes, misleading upstream agents into generating "slop" placeholders or dummy layouts when asset discovery fails.

Furthermore, decorative ASCII headers outputted during failures and standard operations contaminate stdout, corrupting the stream when structured output (--json) is requested by automated tools.

This Pull Request implements the Robust Signal Patch to address these issues by ensuring reliable error propagation and guaranteeing strictly machine-readable JSON outputs.

Key Changes

1. Orchestrator Integrity & Failure Propagation (skills/vg-os/cli.js)

• Synchronous Subprocess Monitoring: Replaced asynchronous spawns for critical asset tools (search) and cognitive commands (task) with spawnSync to ensure the orchestrator waits for execution to finish.
• Exit Status Routing: The orchestrator now actively monitors subprocess exit codes. If a subprocess returns a non-zero exit code, the orchestrator immediately halts execution, logs a clean error, and exits with the same error status.
• Stream Protection: Guarded stdout logs in cli.js to prevent human-readable interactive logs from executing before search spawning when the --json flag is provided.

2. Header Suppression & JSON Safeguards (skills/utils/search.js)

• Suppressed ASCII Banners: Wrapped search header banners in if (!isJson) blocks to prevent stream contamination when automated tools request JSON payloads.
• Machine-Readable Failure States: Refactored error handling blocks (e.g., missing arguments, invalid queries, search exceptions, and visualization decode errors) to dynamically detect the presence of the --json flag.
• Structured Error Output: When --json is active, errors are written directly to stdout as a single JSON object containing the error message ({"error": "<specific error description>"}), bypassing standard ASCII help screens and exiting with status 1.

Rationale: The "Why"

Exposing clear, unpolluted failure signals prevents agents from assuming an execution succeeded when it actually crashed.

• By halting early on non-zero exit codes, we ensure the agent is forced to address the underlying failure rather than generating invalid layouts based on incomplete data.
• Disabling decorative headers during JSON operations preserves machine-readability. Without decorative text interfering with JSON parsing, automated pipelines can reliably catch and parse 100% of tool failures without runtime parser crashes.

Verification & Acceptance Criteria

• Orchestrator halts execution and exits with a non-zero status if a sub-process crashes.
• Asset discovery tools suppress decorative ASCII banners during errors and fallback modes when --json is enabled.
• Outputs remain valid JSON (e.g., {"error": "..."}) even during tool failures.
• Agents receive clear, structured error messages instead of misleading "Success" indicators.