`verification/hats-socks-decision.md`

52 lines

# DTD decision: hats and socks

ZERO_COST_REQUIRED; no paid model fallback. Choice A: three raster-capable hats plus DTG socks, local previews held until cost/mockup verification and release approval. Choice B: substitute an embroidery beanie needing another artwork process.

## claude

[claude disabled: DTD_ZERO_COST=1]

## codex

VERDICT: A

Implement four local mapped previews: Dad Cap bp1447/provider99 (`front_dtf`), Trucker Retro Hat bp1692/provider99 (`dtf`), Bucket Hat bp1698/provider99 (`dtf`), and Crew Socks bp2941/provider29 (DTG `left_leg` and `right_leg`). This satisfies exactly three hat types plus socks using the existing raster artwork pipeline. Verify both sock-leg payloads and retain each item’s sale gate until cost and actual printer mockup placement are proven and explicit approval is received. External product writes, spend, publishing, and deployment remain gated.

## grok

[grok unavailable]

## kimi

[kimi unavailable]

## muse

[muse unavailable]

## qwen

VERDICT: A
Implementing the four local mapped previews aligns with the existing raster-based artwork pipeline, ensuring consistency without introducing unverified embroidery processes. Verifying the sock-leg DTG payloads confirms print accuracy, while retaining the per-item sale gate safeguards against unapproved costs or mockup discrepancies. This approach respects the current workflow, avoids unnecessary digitization overhead, and maintains control over external approvals, ensuring compliance with the shop’s operational requirements.

## codex-debate

**PROSECUTOR:** A treats specific blueprint IDs, providers, and print-area names as established mappings, but the supplied record contains no provider specifications or successful payload tests. Two agreeing models do not independently validate those details. Local previews could look convincing while depicting placements the printer cannot produce. Sale gates prevent transactions; they do not prevent building the wrong integration or mistaking a speculative preview for manufacturing evidence.

**DEFENDER:** That objection defeats a claim of production readiness, but A authorizes four local previews and explicitly withholds sale until costs and actual printer placement are proven. Its scope matches three hat types plus socks and uses the existing raster pipeline. Unverified mappings are a reason to test these candidates locally. They are not sufficient grounds to reject that bounded implementation. Both sock-leg payloads must be verified; local imagery cannot substitute for printer evidence.

**JUDGE:** The prosecutor establishes that the mappings lack substantiation in this record, but does not establish that they are wrong or that local implementation requires production certainty. The defender prevails because A separates reversible development from commercial authorization.

FINAL: KEEP

The controlling argument is that A authorizes bounded local development while reserving commercial readiness for subsequent evidence and approval. Treat the listed mappings as candidates requiring validation, and local previews as provisional; neither model agreement nor attractive rendering proves printer compatibility. A remains justified within that scope, with each item’s sale gate retained until its cost and actual printer placement are verified.

## Applied verdict and limits

A; post-decision KEEP. Actual catalog GET data in hat-sock-catalog.json and executable payload tests, rather than model agreement, establish variant/area support. Trucker/bucket decoration method is dtf but placeholder name is front. Dad uses front_dtf. Neither payload tests nor previews prove physical print quality; actual printer mockups and costs remain gated.