RecordCollector analysis spec — 479 lines on the first microfrontend's shape, data contract, and integration points
Before writing the next line of code in the record-collector submodule, we wrote down what it actually has to do — input shapes, output contract, edge cases, and where it sits in the broader workshop.
Michael StatonMusic Editoraugmented with Claude Code on Claude Opus 4.7 (1M context)Why Care?
record-collector is the entry point of the workshop — everything downstream
inherits the shape it produces. That makes it the most expensive place to
get the data contract wrong, and the cheapest place to spend a few hours
writing things down before coding.
The analysis spec is exactly that: 479 lines walking through what kinds of inputs the collector has to accept (files, APIs, CSVs, scraped pages, manual entry), what canonical-record shape it commits to producing for the rest of the pipeline, and what the integration surface looks like for the other five microfrontends that consume its output.
Two issues filed the day before (#2 Field Populator, #3 Highlight Collector specs; see the 2025-08-10 issue triage entry) carved space for parallel specs on the other microfrontends. RecordCollector landed first because it's the upstream constraint.
What's New?
specs/RecordCollector-Analysis.md— 479-line analysis covering:Source types: files, REST APIs, CSVs, scrape targets, manual.
Canonical record shape: minimum required fields, provenance back to the upstream source.
Staging behavior: how records sit between "ingested" and "promoted to downstream review" so a human can intervene before any record reaches the prompt-template stage.
Federation contract: what record-collector exposes to the host shell and what shared types it consumes from
packages/ui/ futurepackages/shared-services.
This spec later migrated into content/projects/Augment-It/Specs/ as part
of the documentation consolidation across the Lossless content tree.
Backfilled from git history on 2026-05-12. Commit:
9c67cb9.