ece3222d3a
- Imported AD1 Claude session files to clients/dataforth/session-logs/ - Created memory: project_datasheet_pipeline.md (full pipeline architecture) - Created memory: project_dataforth_incident_2026-03-27.md (security incident + MFA) - Updated MEMORY.md index - Updated session log with AD1 pipeline rebuild findings Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
928 B
928 B
name, description, type
| name | description | type |
|---|---|---|
| Serial numbers from DAT data, not filenames | Design decision - always extract real serial numbers from DAT record data, never rely on 8.3 encoded filenames. Discussed with John Lehman 2026-03-27. | feedback |
Always pull serial numbers from the DAT record data (e.g., "178439-1","02-09-2026"), not from filenames. DOS machines use 8.3 filename encoding (GETDSFNAME compresses 6-digit WOs via A-J prefix), but that's irrelevant to the server-side pipeline.
Why: DOS 8.3 filenames are lossy encodings of the real SN. The old DFWDS.exe existed solely to reverse this encoding. By reading the SN from the data, we eliminate the rename step entirely and decouple the pipeline from DOS filesystem limitations.
How to apply: Any new import/export code should use serial_number from the parsed record, never derive SNs from filenames. This applies to all product families including future ones.