Propagate YAML loader errors and implement fault-tolerant editors

[google-labs-jules]

Why This Change is Necessary

Previously, the low-level load_yaml parser swallowed all formatting, syntax, and system IO exceptions, silently returning an empty dictionary ({}) on failure. This created several critical issues across the application ecosystem:

1. Silent UI Crashes: When an editor loaded an empty or corrupted prompt/workflow YAML, the UI crashed completely, rendering a blank white screen below the selectors and trapping the user.
2. Data Loss & Corruption Risk: Utility scripts like inject_test_data.py that read, modify, and write back configuration assets would interpret loading failures as an empty asset. They would then write this empty state back to disk, silently wiping out existing configurations.

By propagating loading exceptions to the application layer, we enable the calling environments (both the Streamlit web UI and CLI scripts) to make informed, context-aware decisions about error handling.

---

Key Rationale & Architecture Decisions

• Direct Error Propagation: Standardized load_yaml to throw parser-level exceptions (such as YAMLError and template compilation errors) by default. Removing the blanket try-except blocks aligns our parsing layer with standard, fail-fast software practices.
• Fault-Tolerant, Non-Blocking UI: Instead of calling st.stop() or letting the exception crash the Streamlit runtime, we catch the propagated exceptions in the page controllers. We render an error diagnostic container (st.error) directly under the asset selector, describing exactly what failed (e.g., syntax/indentation errors) while preserving page navigation, sidebars, and the application layout.
• Fail-Fast for Automations: Refactored utility scripts to abort immediately with a non-zero exit code (sys.exit(1)) upon encountering invalid YAML. This prevents passive data truncation.

---

Detailed Changes

1. Core Parsing Utilities

• promptops/promptops/utils.py: Removed the outer broad try-except structure from load_yaml so formatting, Jinja compilation, and syntax errors propagate to callers.
• studio/studio/helpers.py: Updated load_asset_data to allow core parser and IO errors to bubble up naturally.

2. Streamlit Web Editors

• studio/studio/pages/1_📝_Prompt_Editor.py & 2_🔄_Workflow_Editor.py:
  • Wrapped asset-loading sequences in try-except blocks.
  • Replaced layout-halting rendering errors with an inline warning block located beneath the file selector.
  • Kept the sidebar, main layout structure, and navigation controls fully rendered and interactive during file loading failures.

3. CLI Script Safeguards

• tools/tools/scripts/inject_test_data.py: Added validation logic to ensure that if a read operation fails, the script prints the traceback and exits immediately rather than attempting a write action.

4. Testing & Validation

• Added robust unit and integration tests verifying:
  • Proper exception throwing when loading corrupted files.
  • Correct terminal exit behaviors for CLI scripts targeting bad assets.
  • Graceful handling within the editor flow configurations.

[google-labs-jules]

[CI/CD Fix Attempt 1]

We investigated the CI failure on pull request #1818.

Cause of Failure

The verify check failed during validation due to documentation drift:

• Several new prompts and workflows had been added to the repository in recent upstream commits (specifically for clinical protocol and sterility validation).
• However, the generated markdown documentation in the docs/ directory had not been updated and synchronized with these new files on the PR branch, causing promptops docs --check to fail.

Actions Taken

• Ran the documentation generator (promptops docs) to synchronize prompt and workflow descriptions.
• Verified that the complete verification test suite (validate_prompts.sh) now runs and passes successfully.
• Committed the synchronized documentation files and pushed the updates to the branch.

[google-labs-jules]

[CI/CD Fix Attempt 2]

Cause of CI Failure

The verify check failed during validation due to a ModuleNotFoundError during pytest test collection:

• Specifically, the test tests/test_mcp_server.py could not import mcp_server because the root workspace directory was not in the python search path (pythonpath) when pytest was run via uv run pytest.

Actions Taken & Local Verification

• We reproduced the problem locally and verified that adding pythonpath = "." to the [tool.pytest.ini_options] section in pyproject.toml resolves this issue.
• With this change, all 109 tests run and pass successfully!
• The change was successfully written to /app/pyproject.toml.
• However, during the local validation runner step, the static accessibility scanner (node scripts/accessibility-scan.js) hung and timed out after 5 minutes, which subsequently crashed the guest agent process in the VM (vsock EOF). Consequently, we were unable to execute git commit and git push to upload the changes.

The complete and verified fix consists of adding pythonpath = "." to pyproject.toml:

[tool.pytest.ini_options]
testpaths = ["tests", "tools/tools/scripts"]
norecursedirs = ["experimental", "workshop", "workshops", "draft", "drafts", "temp_drafts"]
addopts = "--ignore=experimental --ignore=workshop --ignore=workshops --ignore=draft --ignore=drafts --ignore=temp_drafts"
pythonpath = "."