Turning Product Findings into Field-Level Shopify Tasks

“Fix schema” is not a task.

Task contract

{
  "finding":"offer.availability.visible_match",
  "affected_url":"https://thewoobles.com/products/penguin-crochet-kit",
  "observed":{"visible":"Sold out","structured":"InStock"},
  "probable_owner":"theme or SEO app Product offer",
  "shopify_path":"Online Store > Themes > Edit code",
  "risk":"high commercial fact",
  "fixtures":["sold-out product","in-stock product"],
  "rollback":"restore previous theme/app block"
}

Owner resolution

Catalog tasks go to product/variant/metafield records. Theme tasks go to a duplicate theme. App-owned schema tasks identify the app embed. WAF tasks point to the security rule, not Shopify product admin.

Generation rules

• never propose a value not observed or merchant-approved
• include all affected variants
• distinguish automatic fix, suggested fix, and needs review
• attach exact verification command
• retain before evidence

Rhode’s shared SKU remains needs review; HexClad’s Default Title can produce a deterministic theme task after ownership is identified.

Map evidence to the owning surface

The public symptom does not identify the write target by itself. A wrong price may originate in a variant, market price list, subscription app, product feed, cached section, or theme JSON-LD. Task generation first builds a candidate ownership map and then asks for enough evidence to select one owner.

visible HTML wrong, Shopify variant correct       -> theme or app rendering
visible HTML correct, Product JSON-LD wrong       -> theme/app structured data
storefront correct, external feed wrong           -> feed or channel mapping
one market wrong, another market correct           -> market-scoped commerce state
all public facts correct, provider answer stale    -> monitor and verify; no Shopify write

A task remains needs_review when ownership cannot be established safely.

Task states

Use explicit states: draft, evidence_ready, awaiting_approval, approved, executing, verified, failed, rolled_back, and needs_review. State transitions retain actor, timestamp, input version, and reason. Approval applies to one immutable change envelope; editing the proposed value invalidates the prior approval.

Verification contract

Every executable task carries a before fixture and an expected after condition. For a structured-data repair, verify both the JSON-LD node and the visible commercial fact for representative in-stock and sold-out variants. For a canonical repair, follow redirects and verify the final page, canonical element, sitemap URL, and internal link target.

{
  "checks": [
    {"path":"$.offers.availability","expected":"https://schema.org/OutOfStock"},
    {"selector":"[data-product-status]","expected_text":"Sold out"},
    {"http_status":200,"expected_canonical":"https://example.com/products/item"}
  ]
}

Failure and rollback

If a write succeeds but public verification fails, do not retry blindly. Capture the deployed state, identify cache or publication delay, and keep the task in failed_verification. Rollback is permitted only when the current value still equals the value applied by the task. A later merchant edit creates a conflict and requires review.

The user-facing task should answer five questions without opening logs: what is wrong, what evidence supports it, where the change will occur, what can break, and how success will be checked. That is the difference between an actionable Shopify task and generic “improve your schema” advice.