"File -> Nuova estrazione" (Ctrl+N) azzera distinta/raw/verifica per ripartire
senza ricaricare DB e cartella di lavoro; "Aiuto -> Guida" (F1) apre una sintesi
interattiva delle 5 fasi. Rimossa "Verifica completezza assiemi": bottone,
ReportCompletezzaForm e VerificaCompletezzaAssiemi non più necessari.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Il doc elencava i file sorgente e una tabella delle fasi, ma non il
processo: cosa entra e cosa esce da ogni fase, e perche' la 4 e' piu'
complicata di "leggi i componenti e copiali". Aggiunta una sezione che lo
descrive come pipeline, con in chiaro le tre liste che la fase 4 raccoglie
da ogni .asm - distinta, soppressi, riferimenti esterni - e per ognuna se
si ricorre dentro e se un codice mancante va segnalato.
Allineati alla stessa modifica i punti rimasti indietro: la riga della
fase 4 nella tabella, la sezione sulla lettura dei .asm (che citava solo i
soppressi), e l'elenco dei file di test, fermo a quattro su sette.
Terzo caso di "[-4] Dati di input non completi" in Creo Distributed
Batch, dopo i soppressi e le copie ambigue del commit precedente: falliva
9255728001, e solo lui fra i sei assiemi del batch.
Il file in raw/ era identico bit per bit a quello sulla share, quindi non
era il modello: mancava il contorno. Il suo sottoassieme _200 e' legato
ad altri due (9255708017, 9255708018) da assembly feature e datum
copiati, e monta una vite V6-12--_-_U5933_C il cui generico uni5933.prt
non era in raw/. Nessuno dei sei file compariva in "members" ne' fra i
piazzamenti: i due lettori esistenti non potevano vederli.
Quei modelli stanno in una tabella a parte del .asm - array \xf2\xf7\x05
… \xf3 con elementi \xe3\xe2<tipo><nome>\0 - che ora si legge con
EstraiCodiciRiferimentiEsterni, riusando la normalizzazione di #AF<n> e
istanza<generico> gia' fatta per i membri. A differenza dei soppressi si
ricorre dentro: Creo carica il modello citato con tutto il suo albero, e
infatti 9255700182 arriva solo per quella via.
La tabella contiene anche nomi di feature (MIRROR3, CHAMFER1) che dal
record non si distinguono dai modelli. Non e' un problema: come per i
soppressi si cerca ogni nome nell'indice e si ignora quello che non c'e'.
Per lo stesso motivo questi codici restano fuori dai "non trovati", e la
coda di scansione porta ora un flag che tiene fuori anche i rami
raggiunti per riferimento esterno - la lista dei componenti mancanti
continua a parlare solo della distinta.
Documentato in docs/formato-asm-record.md §7.5.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Creo Distributed Batch falliva su 8 dei 22 assiemi con "[-4] Dati di
input non completi", un messaggio che non nomina il file mancante. Erano
due cause distinte, entrambe emerse aprendo gli assiemi da raw/ e
cercando nell'albero il componente con l'icona rossa.
Copia sbagliata del componente. Lo stesso codice esiste spesso in piu'
cartelle della share con pari versione e contenuto diverso (13% dei
codici): non sono revisioni, sono istantanee parallele lasciate da studi,
allestimenti fiera e cartelle temporanee. La vista dell'indice rompeva il
pareggio in modo arbitrario, e poteva vincere una copia obsoleta -
nascondendo del tutto quella buona. Creo poi caricava un modello diverso
da quello atteso, non risolveva i vincoli e non apriva l'assieme. Il
.asm non dice quale copia usa (ne' percorso, ne' UOBJ_ID del figlio, ne'
revisione attesa), quindi si replica la regola di Creo: vince la copia
nella stessa cartella dell'assieme che la referenzia. La vista ora rompe
il pareggio in modo deterministico e viene ricreata a ogni scan, cosi' un
DB esistente prende la definizione nuova senza reindicizzare.
Componenti soppressi. Spariscono da "members" ma restano citati dalla
feature che li posiziona, e il loro file serve comunque per aprire
l'assieme. Da quando la lettura usa il parser esatto - che legge solo
"members", ed e' la scelta giusta per la BOM - non venivano piu' copiati.
Ora si copiano a parte, senza entrare nel conteggio dei "non trovati":
non sono componenti della distinta, segnalarli come mancanti sarebbe un
falso allarme.
Documentate entrambe in docs/formato-asm-record.md §7.3 e §7.4, insieme
alla distinzione che le accomuna: la lista della distinta e la lista dei
file necessari a Creo non coincidono, e la seconda e' piu' lunga.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Il record "model_name" veniva preso per l'identita' del file, ma sui file
reali nomina quasi sempre un altro modello - tipicamente uno dei membri del
file stesso. Il parser esatto rifiutava percio' file perfettamente
leggibili, il chiamante ripiegava sull'euristica testuale e quella
estraeva codici inesistenti, riportati poi come componenti non trovati
nell'indice.
Il segnale ora richiede la conferma del nome proprio del modello
(objname): scatta solo se il file dichiara davvero se stesso come istanza.
Verificato contro le BOM esportate da Creo per 7 assiemi reali: 6 vengono
riprodotte byte per byte (3 di queste prima non si generavano affatto), e
la settima differisce per una sola parte, presente nella revisione di un
sotto-assieme che Creo ha caricato ma assente in quella piu' recente. La
verifica di completezza passa su tutti e 7 (prima 3 risultavano
incompleti), e tutti i 351 .asm di una cartella raw/ reale si leggono col
parser esatto, senza mai ricadere sull'euristica.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Alcuni membri di family table non-UNI portano la notazione "<istanza><generico>"
direttamente nel campo name/family_name di members, senza un ConfigName
associato: AsmRecordReader cercava quella stringa intera (parentesi comprese)
nell'indice e non la trovava mai. Ora separa istanza e generico.
Corretta anche l'etichetta di PrtMancantiForm, che usciva dal bordo della
finestra invece di andare a capo.
Documentato il nuovo meccanismo in docs/formato-asm-record.md, e aggiunta una
nota sul segnale di rilevamento family table di assiemi: validato su un caso
reale ma non affidabile al 100% su scala (trovato un falso positivo).
AsmRecordReader.LeggiMembri ora lancia InvalidDataException quando un assieme e'
esso stesso un'istanza di family table (members descriverebbe solo una
rappresentazione, non le istanze sorelle) invece di restituire un risultato
sbagliato in silenzio - il chiamante ripiega sull'euristica testuale, che risolve
gia' correttamente il caso. Aggiunti due controlli di coerenza analoghi (conteggio
grezzo vs interpretato dei record ConfigName; occorrenze multiple di "members"),
verificati senza falsi positivi su tutti i 350 .asm reali della share.
Documentazione riorganizzata per distinguere cio' che e' verificato contro una BOM
Creo di riferimento da cio' che e' verificato solo su scala (conteggi), e cio' che
resta genuinamente non risolto.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
Porting C# del reverse engineering della struttura a record del .asm Creo
(sezione "members" + parametro "ConfigName" per le family table): legge
esattamente i componenti diretti e genera la stessa BOM esportata da Creo,
senza le euristiche testuali (conteggio occorrenze) di AssemblyComponentScanner.
Resta uno script di analisi indipendente, non integrato nella GUI.
Aggiorna anche formato-asm.md (non e' piu' vero che "non esiste un parser
strutturale") e architettura.md (script mancante nell'elenco).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Schema, logica di scansione/upsert incrementale di Indexer.ScanAsync,
come l'app individua il DB all'avvio (incluso il caveat sulla cartella
di build in dev) e le query piu' usate.
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>
Not needed anymore: the app no longer copies matched .stp files from
step/ into a separate step_finali/ folder, or reports which distinta
codes are still missing a STEP. Removed the "Crea cartella step_finali"
button, GeneraReportStep, and ReportStepForm/EsitoStep. Phase 5 keeps
"Verifica completezza assiemi" and the drag&drop .asm list (still how
files get sent to Creo Distributed Batch); renamed from "Verifica
completezza e STEP" to "Verifica completezza" since it's no longer about
STEP output. PulisciRawEStep now only clears raw/ and step/.
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>
- New app.ico (from the Cevolani favicon, background made transparent and
cropped tighter to the logo so it stays legible at 16/24px), wired up via
ApplicationIcon in the csproj and re-read at runtime for the window icon.
- Named the product "Cevolani StepPrep" and set Version=0.1.0 in the csproj;
shown in the window title. The CadSearchGui folder/namespace/csproj keep
their technical name, only the product-facing name changed.
- Updated CLAUDE.md, README.md and docs/architettura.md to reflect the
product name/version, UiStile.cs, app.ico, and that this app is a
pre-process step ahead of Creo Distributed Batch.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
CopiaFileTrovati now copies with Parallel.ForEach (degree 6) instead of
sequentially: the bottleneck is network latency to the share, not CPU,
so overlapping copies gives a large speedup (~5x in a synthetic
benchmark with simulated SMB latency, documented in
docs/copia-raw-parallela.md).
Also adds docs/architettura.md, a full architecture overview of every
source file, the wizard's 5 phases, dialogs, persistence and standalone
scripts.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Pro-E numeric codes cover most components, but parts downloaded as STEP
from online catalogs (rings, bushings, knobs...) get alphabetic Creo names
with no predictable shape. Add a second extraction path that tokenizes the
binary generically and validates candidates against the known codes in
cad_index.db, applying the same placement/occurrence rule used for bare
numeric codes. Numeric extraction is unchanged, so missing-from-index
reporting for renamed/moved Pro-E codes still works.
Also load all known prt/asm codes once per scan instead of one query per
candidate, in both RisolviAlberoComponenti and VerificaCompletezzaAssiemi.
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