dreamina-3d-resume

dreamina-3d-resume

When to use

The user references an existing job id and wants to continue without restarting local export or remote submission. The job ledger is the single source of truth for what has already happened.

Use McpDesignClient for all Dreamina Design operations. Resume may call only the typed status, account, submit, and query mappings; after a stored design_submit_id exists it may call only the query mapping.

Workflow

For a persisted auto_with_budget job, automatically resume only the safe next state: capability/quote work before a submission, or query/download work after its stored submit identifier. Never convert a budget stop, missing web prerequisite, failed validation, Unknown, or failed job into a new paid submission without a new user instruction.

1. Load. JobLedger.read() on the user's job file. If the file does not exist, stop and ask the user to specify a valid job_id.

2. Map state → next action.

   Current state	Next action
   Draft	ask the user to choose a companion DCC
   DccSelected	resume from the PreviewSpecified step
   PreviewSpecified	re-validate the existing preview receipt; on mismatch re-export
   PreviewValidated	resume capability resolution
   CapabilityResolved	resume quote (do not reuse a quote for inputs that have changed)
   Quoted	ask the user to confirm or reject the quote
   Approved	check submit.design_submit_id — if present, only query, never resubmit
   Submitted	only query the design plugin; never re-export or re-submit
   Querying	continue polling
   Completed	verify the on-disk artifact hash; if missing, transition to Failed
   Failed / Unknown	ask the user to authorise a recovery action (re-quote / re-query / restart)

3. Never repeat completed work.

   • A Completed job must never be re-submitted or re-exported.
   • A Submitted/Querying/Unknown job must never be re-exported.
   • Only Draft, DccSelected, and PreviewSpecified may re-invoke the DCC adapter, and only if the on-disk artifact hash no longer matches.

Never do

• Never auto-resubmit a paid action.
• Never silently rewrite history; append to the job ledger instead.
• Never invent a design_submit_id; the design plugin is the only source.

When to use

Load this skill when the user needs to resume an interrupted task from a recorded state, avoiding duplicate submission or duplicate billing . First extract the goal, inputs, constraints, delivery format, and acceptance criteria from the request; the description summary is: Use when the user wants to continue an in-flight Dreamina 3D job without re-paying or re-exporting. Resumes the job from its ledger state.

Rules

• Read before write: first confirm the current state and real capabilities, then perform actions that change external state.
• Least privilege: use only the files, tools, accounts, and network scope needed to complete the current step.
• Evidence first: when run results, resource IDs, versions, hashes, or test output are missing, clearly mark them as NOT_VERIFIED。
• Idempotency first: retain request identifiers and stage state; when results are unclear, query first rather than retrying blindly.
• Privacy and security: logs, examples, receipts, and error messages must not contain tokens, cookies, keys, or personally sensitive data.

Workflow

Step 1: Clarify intent

Confirm whether this skill matches the goal; if it is only an adjacent need, hand it off to a more precise skill.

Step 2: Run prechecks

Verify the task identifier, last successful stage, remote state, budget, and authorization scope; if any critical condition is unknown, stop at the read-only stage.

Step 3: Form a plan

List the tools to be called, the objects that will change, the success criteria, and the safe exit method after failure.

Step 4: Execute actions

Continue only stages that are not yet complete and can be proven safe; retain an associable state or receipt for every external call.

Step 5: Verify delivery

Return the reused results, newly executed steps, unrecovered items, and the next human decision point, and state facts, inferences, and unverified items separately.

Validation checklist

• The skill trigger conditions match the user's intent, and no adjacent task was misrouted to this skill.
• The inputs, target objects, versions, and output locations are all clear, and no required values were replaced with guesses.
• All write, paid, publishing, or irreversible actions are within the user's authorization scope.
• The results have been verified with independent checks; "command succeeded" or "file exists" alone does not count as complete acceptance.
• The output includes actual evidence, failed/skipped items, remaining risks, and executable next steps.

Gotchas

1. Mistaking the plan for the result: a document or prompt is not the same as actual execution; the actual execution level must be stated.
2. Retrying on error: a timeout or lost response may already have produced a remote state; query first before deciding whether to retry.
3. Implicit scope expansion: batch, full-volume, publishing, overwriting, and paid operations are not natural extensions of ordinary read/write.
4. Version drift: when referencing external resources, record the version, tag, or commit; do not treat a mutable branch as release evidence.
5. Stale evidence: caches, old screenshots, and historical tests cannot prove the current environment; refresh critical evidence before delivery.

Non-applicability and boundaries

Do not resubmit a task when there is no idempotency key, remote state, or user authorization; resumption does not expand the original approval scope. If the request requires another skill, do not copy its content; hand off by skill name and preserve the current task context.

Progressive disclosure

• When the input/output, state, and authorization points need to be determined, read references/workflow-contract.md。
• When a pre-delivery self-check is needed, read references/validation-checklist.md。
• When encountering timeout, partial success, or recovery scenarios, read references/error-recovery.md。
• For first run, privilege escalation denial, and failure recovery, refer respectively to examples/happy-path.md、examples/boundary-refusal.md、examples/failure-recovery.md。