1117-3.3

Three problems, found on this page and verified to be systemic. The first can put the wrong part on a board; the other two are data quality.

1. "Ordering variants" mixes reel suffixes with DIFFERENT PARTS

The README lists eight MPNs under one heading on a page titled 1117-3.3:

1117-3.3H      1117-3.3R      1117-3.3T      1117-3.3S      1117-3.3D
1117-3.3H-3.3  1117-3.3H-1.8  1117-3.3H-ADJ

-R, -T, -S, -D are packaging/reel options: same die, order any of them. But -1.8 is a 1.8 V regulator and -ADJ is adjustable. They are presented, with equal confidence and no distinction, as orderable variants of a 3.3 V part. Someone can order 1117-3.3H-1.8 from this page expecting 3.3 V and get a board that does not work.

The root problem is that a variant currently has no type. The list holds "same die, different reel" and "different part entirely" in one bag. Worth deciding whether a variant carries a kind (packaging / same-spec-different-mfr / different-part) before anything renders this, because rendering an untyped list is what makes the wrong entries look authoritative.

2. Variants are markdown only, with nothing behind them

page.json for this slug has no variants key. Top-level keys are: schema_version, type, slug, title, brief, version, license, tags, component, metadata, sections, discovery_triggers, discovery_pitch, author, dependencies, hero, files, visibility.

The eight MPNs exist solely as bullets in README.md. Nothing can drive a selector from them, nothing is queryable, and a BOM tool cannot resolve one. Note the variant backfill already touched this area (1,921 pages), so anything added here should extend what it wrote rather than introduce a second representation.

3. The MPN bleeds into Manufacturer, on ~5% of pages — FIXED, needs a backfill

ray/1117-3-3   specs.Manufacturer = "IDCHIP 1117 3 3"

Measured, 150 random published pages, 116 with a Manufacturer field: 6 contaminated (5.2%).

LM2576R-5.0        'HTC Korea TAEJIN Tech LM2576R 5 0'
LP5907MFX-2.5      'Texas Instruments LP5907MFX 2 5 NOPB'
HG809RM3-2.63      'HGSEMI HG809RM3 2 63 TR'
AZ1117CH2-5.0TRG1  'Diodes Incorporated AZ1117CH2 5 0TRG1'
LM3480IM3X-5.0     'Texas Instruments LM3480IM3X 5 0 NOPB'

Root cause is upstream, in the worklist itself — 773 of 10,405 rows (7.4%) carry the MPN inside the Manufacturer column, with its punctuation already flattened to spaces:

MPN=SK1117-3.3    MFR=Shikues SK1117 3 3
MPN=LM2576R-5.0   MFR=HTC Korea TAEJIN Tech LM2576R 5 0

That flattening is why it survived: clean_mfr never looked for the MPN, and comparing against the raw MPN would not have matched anyway (LM2576R-5.0 vs LM2576R 5 0).

Fixed in clean_mfr by normalising both sides to alphanumeric-plus-single-space before searching. Validated across the entire worklist: 1,246 rows corrected, 9,159 unchanged, 0 emptied (no row loses its manufacturer). Control case STM32F103C8T6 / STMicroelectronics is untouched.

The fix only applies to pages built from now on. The ~5% already published still carry the bad string and need a backfill pass to rewrite specs.Manufacturer — worth folding into the next sweep rather than running its own.

Attribution

Findings 1 and 2 were spotted by the session working the passives design; I verified all three independently and measured 3, whose rate differs from the first estimate (the earlier 4% came from index-data.json, which has no manufacturer field at all — the string being measured was brief, which merely begins with the manufacturer).