Test end-to-end su un albero reale (9284218024b.asm, confrontato con la sua
BOM Creo di riferimento tramite scripts/CreoBom.cs) oltre gli 8 campioni usati
per il reverse engineering iniziale.
Trovato: i componenti creati da un pattern/array feature hanno un ConfigName
con suffisso "<codice>#AF<n>" (n = indice nel pattern), non un'istanza di
family table vera - la BOM di Creo lo ignora e unisce le occorrenze duplicate.
AsmRecordReader ora rimuove questo suffisso prima di usare il nome istanza.
Trovato ma non risolto: un intero ASSIEME (non solo le parti normalizzate)
puo' avere una family table, risolta da Creo con un meccanismo diverso da
ConfigName (non decodificato). AsmRecordReader non lo rileva e non lancia
eccezione in questo caso: il fallback automatico di Form1 non scatta, e il
risultato puo' essere silenziosamente incompleto. Documentato come limite
noto in formato-asm-record.md e in CLAUDE.md - nessun fix applicato finche'
il meccanismo non e' meglio compreso.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
AsmRecordReader (spostato da scripts/CreoBom.cs nel progetto principale,
unica fonte di verita' condivisa con lo script via #:project) sostituisce
AssemblyComponentScanner in Form1.RisolviAlberoComponenti (fase "Trova
componenti referenziati") e AssiemeCompleto (fase "Verifica completezza"):
legge esattamente la sezione "members" del binario invece di contare
occorrenze testuali, eliminando i falsi positivi/negativi noti dell'euristica
(riferimenti fantasma, placement senza suffisso, ecc.).
Se un file non rispetta il formato validato (InvalidDataException, coperto
solo dagli 8 campioni usati per il reverse engineering) Form1 ripiega
sull'euristica di AssemblyComponentScanner, che resta quindi come fallback
e come fonte di verita' per gli script BomViaDb.cs/ExtractCreoStrings.cs.
Aggiunti test per AsmRecordReader (fixture binarie costruite a mano: lettura
membri, risoluzione ConfigName, conteggio disallineato, sezione assente).
Aggiornata la documentazione (CLAUDE.md, docs/architettura.md,
docs/formato-asm.md, docs/formato-asm-record.md) di conseguenza.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Due bug reali trovati confrontando l'estrazione BOM con la BOM ufficiale Creo:
un componente scartato per placement fallito in un file veniva bloccato per
sempre anche quando il file giusto aveva un vero placement (perdendo interi
sotto-alberi come 9256510047), e i codici con suffisso (_C01 ecc.) richiedevano
sempre placement esplicito invece dell'eccezione per occorrenze ripetute già
presente nella GUI. Entrambi corretti.
AssemblyComponentScanner reso pubblico e scripts/BomViaDb.cs, ExtractCreoStrings.cs
riscritti per referenziarlo via "#:project" invece di duplicare l'euristica:
un'unica fonte di verità condivisa da GUI e script standalone.
Aggiunti test di integrazione per Indexer.ScanAsync (mai coperto oltre al
parsing del nome file) e test end-to-end che ricostruiscono l'intera pipeline
disco -> indice -> risoluzione albero componenti senza toccare la UI.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Working folder (phase 1): CSV/raw/step/step_finali all used to live split
across two different implicit locations (CSV in the "repo root" found by
walking up for CLAUDE.md, raw/step next to the input distinta file) with
neither shown to the user. That repo-root lookup also silently breaks once
the app runs as a standalone published exe on a machine with no repo/
CLAUDE.md at all. Replaced both with one explicit "cartella di lavoro",
auto-suggested (last used, remembered the same way as the DB path) and
changeable from phase 1, with no dependency on any repo marker file.
Rename: CadSearchGui was the working name from before the app had a
product identity; renamed folders, csproj files, namespace and the
AppData settings folder to PrepStep throughout, matching the exe name
already in use. Product-facing name stays "Cevolani StepPrep".
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
davideandClaude Sonnet 5