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>
Two more real placement forms found by comparing against Creo BOM reports:
- A sub-assembly can be referenced only through a "family_name\0<code>\0"
metadata field instead of a textual "Componente ID" placement or the
doubled-NUL pattern (case 9284202452 inside 9284208188_D400.asm, which
contains 9284202452_C01/_C02/_C03 - previously dropped entirely, along
with its three children).
- A bare numeric code immediately followed by a family-table bracket
(<code><GENERIC>, e.g. bearing instances like 2510060303<CUSCI_ACBB7>)
is a real reference to that instance, even though only the generic file
is indexed on disk. Previously the instance code silently vanished before
ever reaching the DB lookup; now it survives placement filtering and ends
up in the "scartati" (discarded) list instead, so it's traceable rather
than invisible.
docs/formato-asm.md documents both, bringing the total to four recognized
placement forms.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The bare root code of an assembly (e.g. 9284208188, without a _D... suffix)
is always referenced inside its own suffixed sub-assemblies as a genuine
placement pointing back to the general assembly. Following it during
recursive resolution pulled in the entire product tree instead of just the
requested sub-assembly (598 components collected instead of ~65 on
9284208188_D600). Fixed by seeding the visited-codes set with each starting
assembly's root code, in both scripts/ExtractCreoStrings.cs and the two BFS
call sites in Form1.cs (RisolviAlberoComponenti, AssiemeCompleto).
Also closes two recall gaps found by comparing against a real Creo BOM
report: some real placements only show up as the code repeated twice
separated by a NUL byte rather than the usual "Componente ID N (...)" text,
and family-table bearing codes (CUSCI_...) use the same <...> bracket
convention as UNI hardware but weren't recognized.
docs/formato-asm.md documents all three findings.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Batch the DB lookup per file instead of per code in scripts/ExtractCreoStrings.cs:
files_ultima_versione is an unmaterialized view, so each query rescanned the whole
files table (~230ms) - batching cuts a multi-minute BFS to seconds.
- Widen the code regex to accept a revision letter and a "_..." suffix together
(e.g. "9284200366A_C01"), and purely numeric "_NNNN" suffixes (e.g. dimensional
variants like "2702220182_8188"), not just letter+digits.
- Require bare digit-only candidates to also appear inside a real
"Componente ID N (...)"/"Component id N (...)" placement, filtering out
incidental references to a containing assembly's own code.
- scripts/ExtractCreoStrings.cs now reports only the direct references of the given
.asm (one level, matching Creo's own tree for that file) instead of recursing into
sub-assemblies.
- Port the regex and placement-check refinements to the production
AssemblyComponentScanner.cs used by the app's "Trova componenti referenziati" and
"Verifica completezza" phases.
- Document the new false-positive categories (parent/container self-reference,
suppressed/removed components with residual placement, placement missing
suffix/bracket detail) in docs/formato-asm.md, generalized beyond the specific
assemblies used to find them.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
These appear in the .asm binary as a family-table instance name (e.g.
"R6--_-_U6592<UNI6592>"), not a separate file on disk - only the generic
"uni6592.prt" is actually indexed. Extract just the "<UNI...>" content
instead of the full instance name, in both the standalone script and the
production scanner, so standard hardware stops being silently dropped as
"not found in index".
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Reverse-engineered the Creo .asm binary format enough to extract referenced
component codes via a text heuristic, mirroring AssemblyComponentScanner's
approach and Form1's recursive resolution against cad_index.db. Documents
known false-positive classes (ModelView# view IDs, self-references, and
phantom references to superseded/renamed codes).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
davideandClaude Sonnet 5