How the workflow was tested before the extension existed.

This closed validation phase used manually entered values to test whether users would complete a three-layer comparison and a correction/recheck loop. The website did not parse pages. Version 0.1.7 of the Chrome extension is now the current product and must be evaluated using actual installed-extension evidence.

Historical user boundary

• Agencies, feed specialists, and freelancers managing multiple stores.
• One public product page and one selected variant per case.
• One manually supplied, redacted feed row.
• No Merchant Center credentials, bulk crawling, or account diagnosis.

Historical pass conditions

• Five complete real cases from at least three independent organizations.
• Two multi-store operators each submit cases from at least two stores.
• At least four cases are solvable from page/schema/local-row inputs.
• Published and hands-on free-tool review does not satisfy the same three-layer comparison.
• At least three actionable mismatch cases are found.
• At least two cases produce a correction followed by a clean recheck.
• At least two qualified users make paid, refundable beta reservations.
• A repeatable non-founder channel produces qualified submissions.

Historical caps

• Five calendar days from verified public deployment.
• Eight founder hours.
• US$300 cash cap unless explicitly changed before spend.
• No production extension parser during the manual validation phase.

Evidence limitations

Manually entered values established workflow behavior, not parser accuracy. They do not prove extension installs, scans, retention, repairs, telemetry consent, or Store traction. Current validation must use the installed version 0.1.7 workflow and keep its pseudonymous telemetry separate from this historical ledger.