Content Workflow Asset Task Processing

content-workflow-asset-task-processing

Workflow-owned processing: Immutable inventory, plan revisions, per-item failure isolation, decision memory, commit gates, and the Workflow 2 handoff remain in content-workflow-cli scene process. Use the scene tool frozen in the large-scene request only for per-asset inspection, rendering, and accepted authoring. Existing usd-cli material-task adapters remain supported where selected; changing a low-level backend must not remove batch orchestration or resume.

Run Workflow 2 over qualified (manifest_id, asset_id, task_id) work items. Let the driving agent choose its plan; do not bake domain archetypes, task ordering, or automatic result propagation into the runtime.

Prepare

1. Load manifest_catalog.json and every selected finalized manifest.

2. Load every requested domain skill and write task_catalog.json using TaskCatalog from content_agent_workflows.asset_task_processing.contracts. Write one task request per catalog entry. Put user guidance in the request's additional_instructions field, copying scene-level instructions exactly from large_scene_run.json when present. Keep this guidance task-wide; do not duplicate it per asset or prim.

3. Mechanically expand each task over processable assets in its selected view:

   content-workflow-cli scene process prepare \
     --manifest-catalog MANIFEST_CATALOG.json \
     --task-catalog TASK_CATALOG.json \
     --output-dir RUN/02-asset-tasks \
     --input-digest PHASE_INPUT_DIGEST
   

   This writes immutable asset_task_inventory.json and separate mutable asset_task_run_state.json. Do not edit either manually.

4. Survey the complete work matrix and available evidence before committing the first result. Read every task request, summarize the applicable user guidance in the plan, and cite its frozen SHA-256. Write a plan draft, then preserve it as an immutable revision:

   content-workflow-cli scene process record-plan \
     --output-dir RUN/02-asset-tasks \
     --plan-file PLAN_DRAFT.md
   

Process

1. Choose asset-major, task-major, mixed, or concurrent progression from the evidence and resource limits. Revise the plan when new evidence warrants it.
2. Process only eligible representatives. Do per-item scene inspection, OVRTX rendering, and accepted material/physics authoring through the workflow-owned usd-cli session. Serialize scene loads and GPU renders where resources are constrained. Copy the parent scene task's frozen scene_backend and scene_session_scope into each domain task request's processing_policy. With scene_session_scope: per_asset, create an independent usd-cli named session and checkpoint lineage for every work item. Close that state before moving to the next item; a retry starts fresh state for only the failed/deferred item and never reopens a completed item's sealed artifacts.
3. Consult prior results as explicit evidence when useful. Record fully qualified citations in informed_by_results; never copy an earlier result merely because an asset looks similar.
4. Write one independent AssetTaskResult per completed work item, including original-path mapping, domain payload paths, plan revision, validation, and warnings.
5. Commit the result, validator report, and matching DecisionLedgerEntry in one commit-item call. Do not write the ledger and result index as separate manual steps; partial commits intentionally fail the handoff gate.
6. Keep each domain's preview layer separate and provisional. Preserve failed or deferred items for explicit retry. Use an AcceptedWaiver for any required item intentionally omitted.

Use the phase module's status, show-item, begin-item, commit-item, fail-item, and waive-item operations for state transitions. These are a thin script over the package runtime, not another product-level CLI.

Material Tasks

Before processing material work, read references/material_tasks.md. It defines the survey and batch commands, authored-appearance evidence policy, display-color matching route, visual review gates, and frozen task-request digest contract. Run those steps through usd-cli for low-level scene operations, then commit through the pure-Python asset_task_processing state machine:

content-workflow-cli scene material-task \
  match-display-color \
  --processing-dir RUN/02-asset-tasks \
  --work-item-id TASK_ID:MANIFEST_ID:ASSET_ID \
  --scope /EXACT/SOURCE/ROOT \
  --top-k 5
content-workflow-cli scene material-task run-batch \
  --processing-dir RUN/02-asset-tasks \
  --batch-plan MATERIAL_BATCH_PLAN.json

Complete

Finalize and seal the phase only after required work is completed or waived:

content-workflow-cli scene process finalize \
  --output-dir RUN/02-asset-tasks

The runtime computes processing_result.json and its output digest from the catalogs, referenced manifests, immutable inventory, mutable state, plan revisions, ledger, index, completed results, validator reports, and domain outputs. Return that result to the umbrella handoff validator.

Do not author durable opinions onto the original scene here. Workflow 3 owns collection and harmonization.

When changing processing behavior, preserve immutable inventory semantics, task-request digests, per-item result independence, decision ledger integrity, and deterministic handoff validation.