Official Runtime Readiness Checker

official-runtime-readiness-checker

Purpose

Assess runtime readiness before any attempt to claim runtime execution outcomes.

Canonical role: runtime-readiness in the BlendOps skill system. Keep this as the active readiness implementation rather than creating duplicate readiness skills.

Quick start

• confirm this skill fits your goal
• provide required inputs first
• keep runtime claims evidence-bound
• follow suggested next-skill handoff

When to use

• before runtime manual eval
• before any preview/render/GLB readiness claim

When not to use

• as proof that runtime execution succeeded
• as substitute for actual runtime artifacts

Trigger phrases

• “check runtime readiness”
• “is runtime available”
• “can we run this now”
• “verify connector and MCP availability”

Prerequisites / readiness

• non-destructive local environment access
• ability to read config/path signals
• clear distinction between readiness and execution

Input schema

Required inputs

• expected runtime path(s)
• target harness context

Optional inputs

• known executable paths
• known config file locations
• prior blocker records

Assumptions to confirm

• no Blender run required for readiness-only pass
• no non-official runtime path should be used

Output schema

Primary output

• readiness matrix + final status

Secondary output

• blocker list + retry steps

Evidence / caveat output

• per-check evidence lines
• confidence label per check: verified / linked-only / unknown / blocked

Required laws

• ../../laws/official-runtime-only.md
• ../../laws/evidence-before-done.md
• ../../laws/no-arbitrary-python-interface.md
• ../../laws/non-blender-user-language.md

Official runtime boundary

• This skill can check local readiness signals.
• This skill must not claim runtime artifact production.
• This skill must not claim execution success without execution evidence.

Operating procedure

1. Confirm chosen runtime path (Path 1 or Path 2 from ../../docs/runtime-stack-strategy.md); for Path 1 also confirm host option (a Anthropic Connector, b manual MCP). CLI fallback is appendix only — documented upstream as first-class Blender CLI surface but no in-repo evidence file yet; flag this if user picks it.
2. Check Blender executable availability (command/path evidence) AND record exact blender --version output for per-path minimum check:
   • Path 1 (either host) → 5.1+ required (Lab add-on blender_version_min = 5.1.0).
   • Path 2 → 3.0+ required (per upstream).
   • CLI fallback → 4.2+ recommended; documented upstream as first-class Blender CLI; no in-repo evidence file yet.
3. Per chosen path + host, check the path-specific configuration:
   • Path 1 Blender-side (always required): Lab MCP add-on installed in Blender + MCP server (.mcpb bundle or source) reachable.
   • Path 1 host (a): Anthropic Connector enabled in Claude Desktop → Customize → Connectors.
   • Path 1 host (b): Lab MCP server registered in MCP client config (mcpServers JSON or equivalent).
   • Path 2: ahujasid/blender-mcp server registered (uvx blender-mcp or equivalent) + upstream addon.py installed + enabled in Blender.
   • CLI fallback: Blender executable resolvable from agent shell.
4. Check single-bridge constraint: at most one MCP bridge session active per Blender instance (Path 1 + Path 2 must not both target the same Blender; Path 1 host (a) + host (b) must not both target the same Blender).
5. Check artifact/output location readiness for future run.
6. Assign confidence label to each check (verified-read / linked-only / unknown / blocked).
7. Populate readiness matrix table per path + host.
8. Derive final status (Ready / Partially Ready / Blocked / Unknown).
9. Produce blocker summary and next actions.
10. Route to planner or setup skill based on status.

Decision tree

• Blender missing + no connector/MCP evidence → Blocked.
• Blender found but connector/MCP uncertain → Partially Ready or Unknown.
• Blender found + connector/MCP signals sufficient → Ready candidate (still no artifact claim).

Playbooks

• Playbook A: text-only planning path
• Playbook B: runtime-ready path with evidence gating
• Playbook C: blocked runtime path with caveat-first reporting

Mode handling

Text-only mode

• readiness checks only
• no runtime execution claims

Runtime-ready mode

• status Ready/Partially Ready with explicit caveats
• handoff to planning/execution workflows

Blocked runtime mode

• status Blocked
• explicit blockers + setup next steps

Validation checklist

• Blender check recorded
• connector check recorded
• MCP check recorded
• artifact path readiness recorded
• confidence labels assigned
• final status assigned
• blocker list included
• no execution success claim
• no non-official path reference
• next actions clear

Pass / Warn / Fail rubric

Failure handling

• Unknown state: mark Unknown, not Ready.
• Missing config path: mark Blocked and provide exact next check.
• Conflicting signals: choose safer status with caveat.

Troubleshooting

• Blender not on PATH: check absolute path.
• Config file exists but missing runtime entries: mark unknown/blocked.
• Existing artifacts found: treat as pre-existing unless run-specific evidence ties them to current eval.

Best practices

• keep checks reproducible and non-destructive
• include exact evidence lines in report
• separate readiness from artifact claims

Good examples

“Status: Blocked. Blender binary exists, but official connector/MCP runtime path is not confirmed in this environment.”

Bad examples

“Looks good; runtime should work.” (no matrix, no evidence)

User-facing response template

• Current runtime status
• Evidence observed
• Missing readiness signals
• Next setup action

Anti-patterns

• skipping required laws or runtime boundary statements
• claiming runtime/artifact success without evidence
• using non-official runtime setup paths
• producing jargon-heavy final output without explanation

Cross-skill handoff

• If Ready/Partially Ready: product-hero-scene-planner
• If Blocked/Unknown: official-runtime-setup-guide

Non-goals

• runtime execution
• artifact generation claims
• unofficial runtime fallback

References

• 2-path + CLI appendix runtime model: ../../docs/runtime-stack-strategy.md
• Per-path setup details: ../../docs/external-runtime-setup.md
• Path 1 host (a) source — Anthropic Connector: https://claude.com/resources/tutorials/using-the-blender-connector-in-claude
• Path 1 Blender-side source — Lab MCP (required for both hosts): https://www.blender.org/lab/mcp-server/
• Path 2 source: https://github.com/ahujasid/blender-mcp
• CLI fallback source (documented upstream as first-class Blender CLI; no in-repo evidence file yet): https://docs.blender.org/manual/en/latest/advanced/command_line/index.html