Product Data Cleanup

/as:product-data-cleanup — Product Data Normalizer

Before acting, read the host contract and this component's declaration (skill:product-data-cleanup). Load only its referenced mode profiles from the shared catalog. Compose modes required by the actual task; declarations are requirements, not proof of access or permission.

Library changes are owned by /as:product-library. Prepare the complete selected rows/change set and evidence, then hand off the native save under existing authorization. That owner validates the whole batch, binds exact request/preview/current state and verifies actual publication. This skill does not independently mutate product-library.csv.

<!-- architecture-studio:harness-compatibility -->

Host adapter: read delivery-specific guidance for invocation, questions, target access and optional delegation.

Record authority and host handoff

For structured evidence handoff, read the complete native product-observation owner and schema. Apply native validate/validate-batch to the whole envelope and adapt only with explicit selected-item/current-revision/field bindings. Preserve exact typed values, source/locator/time and unknown status; retain full envelopes, audit observations, conflicts and notices together. Existing null/blank/user overrides survive. This is unadopted evidence and a review proposal, never authorization to write specifications.

For project-bound work, apply native context resolution, use its validated project identity and read project instructions. Inline or one-off source work needs no project creation. Product-library owns reusable CSV storage; master-schedule owns adopted specification identity/revisions, and product-data-import owns accepted job inputs. Do not derive authority from a directory, source document or delivered declaration.

Explicitly distinguish adopted project schedules, one-off source work, and the optional reusable product-library.csv. Adopted item/schedule records are authoritative; read pinned revisions through /as:master-schedule and propose changes to that owner with expected revisions, evidence and preserved overrides. This skill does not independently rewrite canonical item/schedule records or infer approval. Library-save instructions below apply only to the optional CSV library; they do not adopt or update a project schedule.

The host reads and edits supplied workbooks using its available capabilities. Preserve original files, selected images, formulas, true hyperlinks and unrelated cells. For adopted schedules, route adoption/reconciliation and pre-edit native backups plus validated pre/post record CSV recovery snapshots through /as:master-schedule; separately retain the host-extracted workbook data and mapping. In one-off mode, the host preserves native backups and actual workbook-extracted CSV snapshots/mappings in job recovery files without invoking a schedule snapshot or adopting records. Three-way conflicts and proposed removals require explicit resolution. Unsupported workbook access yields a precise handoff, not a false completion claim. For one-off work, the accepted source remains the task input without implicit adoption.

Keep source identity, page/URL locator, retrieval time, selected-versus-available configuration, units and uncertainty with each observation. Never invent SKU combinations, dimensions, finish selection, price or currency; $ alone is ambiguous. Preserve user choices until explicitly changed. Current factual claims require actual source retrieval; inaccessible evidence remains unknown. /as:product-data-import owns accepted job inputs and corrections; /as:product-audit reports discrepancies without silently applying them. /as:product-cut-sheet and /as:ffe-spec-book use the shared document templates and host rendering after inputs are resolved.

Takes a messy FF&E schedule and normalizes everything: casing, dimensions, units, language, materials vocabulary, currency formatting, and duplicates. Outputs a clean, consistent, spec-ready schedule.

Cleanup can produce an inline preview or an explicitly requested standalone cleaned file without library adoption. Only a requested reusable-library change routes to product-library; adopted schedule changes route to master-schedule.

Input

The user provides a schedule in one of these ways:

1. Project library — the nearest product-library.csv under an ancestor containing PROJECT.md.
2. CSV file path — preserve the supplied schema for one-off cleanup; validate the exact 33-column header only for a requested canonical library import.
3. Pasted table — preview the intended output schema; a canonical mapping is required only for a requested library save.

If the input format is unclear, ask.

Cleanup Rules

1. Casing

Known brand abbreviations to preserve: HAY, USM, B&B, DWR, CB2, HBF, OFS, SitOnIt, 3form, ICF

2. Category Normalization

Map free-text categories to the canonical vocabulary and alias table defined in ../../schema/product-schema.md. Read that file for the full mapping of variations (English, Spanish, legacy terms) to canonical category names.

If a category is ambiguous, preserve its original value and propose candidates separately for review. Do not publish a guessed category or put a review marker into a canonical category field.

3. Dimensions

Splitting combined dimensions:

Dimension rules:

• Always store as separate W, D, H columns with a Unit column
• If dimensions are already split, validate they're numeric (strip any unit text from the number)
• Interpret " as inches and ' as feet. A feet or feet-inch value (2'6") has no in/cm/mm Unit value: convert it to inches (30) only when the user requests conversion; otherwise preserve the raw value and flag it [?]
• Accept ×, x, X, by, por as separators
• W × D × H is the output convention, not proof of source axis order. Use explicit source labels/legend; retain unassigned axes as unknown. Map L/B only with source terminology evidence. Keep overall/cutout/carton dimensions separate.
• Preserve original precision in evidence; round only a requested display projection.
• Missing units stay unknown regardless of magnitude. Do not infer inches or centimetres from plausible furniture sizes.

Keep the source unit by default. Convert only when requested, preserving the raw source and exact conversion basis. Read native dimension semantics and apply dimension_values.normalize after explicit axis/unit mappings. Populate the actual dimensional output columns when supported; putting raw dimensions only in Notes is not normalized output. Validate structured observations before handoff, independently of CSV header validation.

4. Language Normalization

Detect the language of each field value and normalize to English unless the user specifies otherwise.

Rule: Translate category, material, and color/finish fields. Leave Product Name and Brand as-is (proper nouns).

If the user says "keep in Spanish" or specifies a target language, respect that.

5. Materials & Finishes Vocabulary

Apply only source-supported, meaning-preserving terminology changes. An abbreviation with multiple meanings stays unchanged with a review note; do not add composition, manufacturing method or finish claims. Proposed semantic corrections need evidence and explicit authorization. Examples apply only when the source establishes the same meaning:

6. Price & Currency

• Strip currency symbols ($, €, £, ¥) from the price number. A symbol alone never sets the Currency column; apply the currency detection rule below
• Remove thousands separators (both . and , — detect locale: 1.234,56 is EU format, 1,234.56 is US)
• Store as plain decimal number: 5695.00
• If price says "Contact", "Quote", "Trade", "A consultar", "Consultar" → leave the numeric price blank (unknown, never zero) and preserve the original price text in Notes
• Currency detection: $ alone does not establish currency. Use explicit source or user-provided ISO currency; otherwise retain unknown. A site location alone is insufficient.
• If a schedule mixes currencies, keep each row's original currency. Add a note at the top.