render-export-evidence

name	render-export-evidence
description	Verify preview/render/GLB artifact truth by recording commands, inputs, output paths, file existence, validation notes, limitations, and conservative status labels.

render-export-evidence

Purpose

Create a conservative evidence ledger for preview, render, export, and GLB claims. Use this skill to decide whether an artifact is Not Run, Attempted, Produced, Verified, or Failed.

This skill verifies evidence; it does not run Blender or create artifacts by itself.

Quick start

1. Identify the claimed artifact or runtime action.
2. Collect command/tool, input/script/scene, output path, file existence, validation notes, and limitations.
3. Assign the most conservative valid status.
4. Hand off to glb-web-handoff or response writer only after evidence is clear.

When to use

Use this skill when:

• a user asks whether preview/render/GLB/export succeeded
• an agent needs to summarize artifact evidence
• a runtime eval produced or attempted files
• a report needs artifact truth labels
• a handoff needs proof before user-facing claims

When not to use

Do not use this skill when:

• the user only needs a scene plan with no runtime/artifact evidence
• runtime readiness has not been checked and the user wants execution
• the task is GLB web integration language after evidence is already summarized; use glb-web-handoff
• the request asks to run Blender, render, or export; use runtime/eval flow first

Trigger phrases

• “Did the render produce?”
• “Can I claim the GLB exists?”
• “Verify export evidence.”
• “What artifact status should this have?”
• “Summarize preview/render/GLB evidence.”

Prerequisites / readiness

• The claimed artifact type is known: preview, render, Blender file, GLB/export, or handoff record.
• Any runtime action is already completed or explicitly Not Run / Attempted.
• Evidence sources are available or can be marked missing.
• No artifact claim is accepted from intent, prompt text, or transcript alone.

Input schema

Required inputs

Input	Why it is required
Artifact type	Status is scoped per artifact.
Runtime path or mode	Separates Path 1 (with host a or b), Path 2, CLI fallback, or text-only mode (see ../../docs/runtime-stack-strategy.md).
Command/tool/action used	Proves how the artifact was attempted.
Input/script/scene	Connects output to a specific run.
Output path	Required for file-based claims.
File existence or visible evidence	Required before Produced or Verified.
Validation notes	Required before Verified.
Limitations/failures	Prevents overclaiming.

Optional inputs

Input	Use
File size/hash	Strengthens generated-file evidence.
Screenshot/render thumbnail path	Supports visible-output claims.
Logs/exit status	Supports CLI or failed-attempt analysis.
User-facing target	Shapes handoff language.

Assumptions to confirm

• Runtime eval remains Not Run unless an actual runtime action was recorded.
• Preview/render/GLB remains Not Produced unless concrete output evidence exists.
• Produced is not Verified until validation notes exist.

Output schema

Primary output

An artifact evidence ledger.

Secondary output

• status per artifact type
• missing evidence list
• next safe action
• handoff recommendation

Evidence / caveat output

Artifact type: <preview | render | blend | GLB/export | handoff>
Status: Not Run | Attempted | Produced | Verified | Failed
Runtime path: <Path 1 host a (Anthropic Connector) | Path 1 host b (manual MCP) | Path 2 (ahujasid) | CLI fallback | text-only | unknown>
Blender version: <output of `blender --version` or unknown>
Blender-side add-on identity: <Lab MCP add-on version | ahujasid addon.py commit | N/A for CLI>
MCP server source: <Lab .mcpb bundle filename or commit | uvx blender-mcp version | N/A for CLI>
MCP host product: <Claude Desktop (Connector or manual MCP) | Cursor | Codex | OpenCode | Cline | other | N/A for CLI>
Command/tool/action: <recorded or missing>
Input/script/scene: <recorded or missing>
Output path: <path or Not Produced>
File existence: <yes/no/unknown>
Validation notes: <notes or missing>
Limitations: <caveats>
Next safe action: <action>

Required laws

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

Official runtime boundary

This skill can evaluate evidence from the 2-path + CLI appendix runtime model (see ../../docs/runtime-stack-strategy.md):

1. Path 1 — Official Blender Lab MCP (Lab add-on + Lab server in Blender 5.1+, hosted from either (a) Anthropic Blender Connector in Claude Desktop, or (b) any other MCP client configured manually). Both hosts share the same Blender-side stack and tool surface.
2. Path 2 — Community ahujasid/blender-mcp (different addon.py + server via uvx blender-mcp, mature 21K+ stars third-party, Blender 3.0+).
3. CLI fallback (appendix) — direct blender --background --python, no MCP. Documented upstream as a first-class Blender CLI surface (stable across LTS releases); no in-repo evidence file yet.

Evidence records must name the path explicitly (and Path 1 host option a/b when relevant) and must include Blender version + Blender-side add-on identity + MCP server source/commit + MCP host product so the record is unambiguously attributable.

This skill must not run Blender, render, export GLB, mutate scenes, install runtimes, or promote optional local bridge evidence as official release-eval evidence.

Operating procedure

1. Name every artifact type in scope.
2. For each artifact, collect:
   • command/tool/action used
   • input/script/scene
   • output path
   • file existence or visible-output evidence
   • validation notes
   • limitations/failures
3. Assign status using the decision tree.
4. List missing evidence before any handoff.
5. Recommend next safe action.

Decision tree

No runtime action recorded?
  → Not Run
Runtime action recorded but output missing/incomplete?
  → Attempted or Failed
Output path/visible evidence exists but validation missing?
  → Produced
Output exists and validation notes pass?
  → Verified
Runtime/action failed or artifact absent when required?
  → Failed or Not Produced with reason

Playbooks

Playbook A: Text-only planning output

• Runtime status: Not Run.
• Artifact status: Not Produced.
• Next action: runtime readiness or eval packet.

Playbook B: CLI fallback output

Require:

• exact Blender command
• script/input path
• output folder
• generated file paths
• exit status/logs
• validation notes

Without generated files, do not claim artifacts.

Playbook C: Connector output

Require:

• connector action/tool name or UI action
• Blender-side action notes
• generated file paths or screenshot/render evidence
• validation notes
• permission/session caveats

Read-only smoke evidence is not render/export evidence.

Playbook D: Path 2 (community ahujasid/blender-mcp) output

• Label as Path 2 with upstream commit/version of addon.py and uvx blender-mcp.
• Keep separate from Path 1 evidence — Path 2 is third-party from both Anthropic and the Blender Foundation.
• Record host/port and arbitrary code execution caveats (execute_blender_code runs LLM-generated Python with no sandbox).
• See ../../docs/unofficial-runtime-bridges.md for the full Path 2 caveat write-up.

Mode handling

Text-only mode

Use to mark artifacts Not Run / Not Produced and prepare evidence checklist.

Runtime-ready mode

Use after the runtime/eval action has happened or when reviewing a captured eval record.

Blocked runtime mode

Use when runtime was unavailable; record blockers and keep artifacts Not Produced.

Validation checklist

• Artifact type is named.
• Runtime stack/mode is named.
• Command/tool/action is recorded or explicitly missing.
• Input/script/scene is recorded or explicitly missing.
• Output path is recorded or explicitly Not Produced.
• File existence or visible evidence is recorded.
• Validation notes exist before Verified.
• Limitations/failures are listed.
• No unsupported route is treated as official.
• No artifact success is claimed from transcript alone.

Pass / Warn / Fail rubric

Verdict	Criteria
Pass	Status labels match evidence, output paths/validation are clear, and limitations are explicit.
Warn	Some evidence exists but validation, provenance, or scope is incomplete.
Fail	Artifact success is claimed without evidence, or labels contradict the recorded facts.

Failure handling

• Missing output path → status cannot exceed Attempted.
• Missing file existence/visible evidence → status cannot exceed Attempted.
• Missing validation notes → status cannot exceed Produced.
• Failed command/export → record Failed or Not Produced with reason.
• Pre-existing file only → do not claim current run produced it unless provenance links it to the run.

Troubleshooting

Problem	Conservative handling
Screenshot exists but no render file	Mark preview evidence separately from render file.
GLB file exists but no validation	Produced, not Verified.
CLI log says success but file missing	Attempted or Failed, not Produced.
Output path unknown	Attempted; request path evidence.
Read-only connector smoke passed	Runtime access scoped to read-only; artifacts Not Produced.

Best practices

• Track each artifact type separately.
• Prefer paths and validation notes over prose claims.
• Use exact status words.
• Keep user-facing summary understandable for non-Blender users.
• Hand off to glb-web-handoff only after GLB/export status is known.

Good examples

• “Render status: Produced. Output path: out/hero.png. Validation: camera framing checked; material fidelity not yet verified.”
• “GLB status: Not Produced. Runtime action was Not Run; no export path exists.”

Bad examples

• “GLB produced” with no file path.
• “Render verified” with no validation notes.
• “Runtime eval passed” from read-only smoke evidence only.

User-facing response template

Artifact evidence summary
- Runtime stack/mode: <state>
- Preview: <status + path/evidence>
- Render: <status + path/evidence>
- GLB/export: <status + path/evidence>
- Validation: <notes or missing>
- Limitations: <caveats>
- Next safe action: <action>

Anti-patterns

• Treating a planned output as a produced artifact.
• Treating a prompt transcript as file evidence.
• Merging preview, render, and GLB into one vague status.
• Calling optional local bridge evidence official release evidence.

Cross-skill handoff

• Runtime readiness → ../official-runtime-readiness-checker/SKILL.md
• Scene validation → ../blender-scene-quality-checker/SKILL.md
• GLB/web handoff → ../glb-web-handoff/SKILL.md
• User-facing explanation → ../non-blender-user-response-writer/SKILL.md

Non-goals

• Run Blender.
• Render images.
• Export GLB.
• Modify scene data.
• Install runtime bridges.
• Publish artifacts.

References

• ../../docs/skill-system.md
• ../../docs/runtime-stack-strategy.md
• ../../docs/evals/official-runtime-verification-criteria.md
• ../../docs/evals/official-runtime-manual-eval-packet.md
• ../../laws/evidence-before-done.md