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

Category	Pass	Warn	Fail
Blender availability	Verified with local evidence	Partial path evidence	Missing/not found
Connector/MCP checks	Clear signal per path	Unknown signal with caveat	Claimed available without evidence
Confidence labeling	Every check labeled	Partial labels	No labels
Status logic	Matches matrix evidence	Minor ambiguity	Contradicts evidence

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