[ManuelStaggl]

Fixes the severity-A findings of the full audit (2026-11-12) on telling bought standard parts from printed bodies, and the gaps an independent review found in the first version of this change. Everything is measured with the audit harness (tools/audit, cases normteile-policy-*) against SolidCraft 0.40.1, headless.

How a standard part is told now

One recognition (boughtParts in mirror.ts) stands behind print check, plate, size list, export and the list of parts to buy. A body is a standard part only when

1. its component's description is one parts.insert writes: a family's name, one of its sizes and a length, all read from parts.library (no list of names in PartBuddy);
2. the component holds that one body and nothing else (all 13 families build exactly one);
3. the body has the shape SolidCraft builds for that description: solidcraft-cli run builds the part alone, and both are measured with inspect.measure: volume and area, the counts of faces, edges and vertices, and of each face its area, the length of its outline and its radius (all within 1e-6).

Whatever cannot be read, measured or built counts as printed and is logged with the body and the reason: a screw in the print check shows, a printed part missing from it does not. The mirror does not wait for a part being built; export, slicer, size list and the parts to buy do.

S-01 / G2 / N-normteile-policy-1: one of 13 library families was printed and exported

	before	after
families recognised (one part each)	12 / 13 (countersunk_socket_screw missing)	13 / 13
every size of every family, plus odd lengths, a third turned to [1, 2, 3]	not measured	185 / 185
partbuddy_mechanism {kind: screw, head: countersunk}: structure.standardParts	[]	[Body1, Body2]
bodies exported	Block, Plate, Body1, Body2	Block, Plate
STL of the exported bodies	6084 triangles	1364 (Block and Plate alone: 1364)
control head: cap	2 standard parts, 1456 = 1456	unchanged

The tool's sentence "the screws are in the design as standard parts" is true for both heads. mechanismTool.ts and mechanisms.ts are untouched.

H-01: the assistant could turn a printed body into a "standard part"

execute component.metadata.set {component, description: "Hex nut M3"} took a 0.3 mm lid out of print check, plate and export. The policy refuses component.metadata.set with a description (description, values.description, as a batch step). Since review point 2 the forged description would no longer work either: the lid is not shaped like the nut.

	before	after
decide()	allow	deny
structure.standardParts after the attempt	[Deckel]	[]
print check	ready, "nothing found"	block, "walls down to 0.3 mm"

Review

1. The policy compared command ids exactly; SolidCraft runs them in any case. Measured over 50 spellings of tool, command, argument and parameter names: SolidCraft takes a command id in any case (Component.Metadata.Set, File.Export), a batch step's command as id, and a batch's steps from a script file (path); tool names, argument names and parameter keys only as written (Execute, Params, Path, Key are unknown or ignored). Every rule now sees the lower-case, trimmed id, normalised in one place for execute, batch steps and nested steps; a step's id is decided like its command; batch with a path is refused. decide() for Component.Metadata.Set, Document.Metadata.Set with PartBuddy's key, Edit.Checkpoint, Doc.recovery_list, Diagnostics.Crash_Reports, a step {id: ...} and batch {path}: allow -> deny. Test: agent.test.ts, "decides a command id in any spelling SolidCraft runs".

2. Bodies in a library component counted unchecked. A box, a 0.3 mm lid (print check block) and an M3 nut; the steps sent past the policy:

steps	before	after
component.move_bodies of the lid into the nut	ready, lid a standard part	block, lid printed (2 bodies: stage 1)
component.copy_bodies into the nut	reproduced by the review	block (stage 1)
component.activate the nut + solid.box	reproduced by the review	block (stage 1)
solid.combine join of a plate onto the nut	reproduced by the review	block, nut body printed: 310.17 mm³ and 24 faces against 45.91 mm³ and 9 (stage 2)
solid.box {operation: join} onto the nut	reproduced by the review	block (stage 2)
solid.remove the nut, lid moved in	not measured	block (stage 2)
description "Hex nut M3" on the lid's component	ready (H-01)	block (stage 2)
nut described as "Hex nut M4"	not measured	nut printed (stage 2)
"Plain washer M3x8" on the lid, beside the nut	not measured	lid printed, nut still a standard part

Stage 2 comes from a reference, not from library dimensions: a world bounding box changes with the part's direction, volume and area do not (turned, hidden, resized: at most 6e-11 off the reference). What the reference costs and where it is kept: see the second review, point 1. Tests: structure.test.ts ("counts every body of a library component as printed…", "takes a body for the part only when it has the shape…"), partReference.test.ts, mirrorRevision.test.ts.

3. Body names kept in the design's metadata. The key is neither read nor written any more; parts put in from the menu are library components like any other. Measured: key set to ["SHCS M3x12"], nut renamed, lid renamed to SHCS M3x12: the lid stays printed, the renamed nut stays a standard part. The policy still refuses writes to the key by its prefix.

4. Parts to buy. No longer assembly.bom: the list is the standard parts themselves, counted by their placements through subassemblies, with the part number SolidCraft gives the reference. A nut, a washer in a subassembly placed twice, a printed lid: with the lid given part_number: "ISO 4032 M3" (BOM: one row, components [2, 5], count 2), the nut set to bom_type: reference (BOM: no nut), the nut's part number emptied: the list is 1 x Hex nut M3, 2 x Plain washer M3 in every case. Test: structure.test.ts, "lists the parts to buy from the standard parts themselves".

5. A failed parts.library switched the recognition off silently. A failed batch, a rejected request, no results and an empty library each write a line to the log; the library is read once per engine connection and again after a failure. Test: mirrorRevision.test.ts, "says so in the log when parts.library fails or is empty".

6. A fallback to the former twelve names is left out. A family SolidCraft renames or a size it drops cannot be built by the installed SolidCraft, so there is nothing to hold the body against; a fallback by name alone would be the gap of point 2 again. Such a part counts as printed and is logged.

Second review

1. The reference blocked the mirror, and a failed run was tried again with every mirror.

	before	after
what the mirror waits for a new part	0.37 s (1 part), 4.2 s (30), 43 s (all sizes), with every start	4 to 14 ms: it asks and goes on
build of the references	in the mirror	in the background: 0.7 s (1 part), 11 s (30), 98 to 112 s (all 185 sizes), once per SolidCraft program; then the design is mirrored once more
after a restart of the app	built again	0.1 s, read from part-references.json in the cache folder (kept under the program's version, size and date)
a part SolidCraft refuses (Socket head cap screw M3x5000)	one failed process with every mirror	one run of 0.2 s, then remembered with its reason, over restarts too
a run that gives no answer	up to (1 + N) x 2 min with every mirror	ends after 20 s + 2 s a part (the slowest single part builds in 0.5 s); its parts are not tried again for 5 min

Until a part's reference is there its body counts as printed, so for that moment the print check sees the screw. What leaves PartBuddy does not: export, send to slicer, the size list and the parts to buy read the standard parts anew and wait for their references. The build takes two runs now (how many faces a part has is known only once it is built), which is why it is slower than the one the review timed.

2. The same reference was built twice by the mirror and the list of parts to buy. A description being built is not started again; whoever waits, waits for the run that is under way.

3. Five numbers did not fix the shape. A ring of R 4.0251, r 3.3699, 1 mm high has the volume, area and counts of the M3 washer to 2.6e-11. The shape now also holds each face's area, outline and radius. model.faces and model.edges were measured and are not used: they give values of the display mesh, up to 2 % apart between the same part straight and turned; inspect.measure of a face is exact. Measured: the ring, described as "Plain washer M3", stays printed; all 185 sizes stay standard parts, a third of them turned.

4. cliReferences was untested. partReference.test.ts, with the program's runs injected: a reference is kept and no process runs for it again; a refused part is remembered, also over a restart; a part that cannot be built lets the others stand; a run without an answer is tried again only after a while; the script file is removed; a background build asks for exactly one more mirror (mirrorRevision.test.ts: "mirrors the delivered revision again, once however often it is asked"); two askers, one build; the ring against the washer.

5. Older designs. No saved design with standard parts lies in the repository (apps/desktop/e2e, tools/fixtures, tools/templates, site: none). Measured instead on the two designs the audit saved on 2026-11-12 (families.sc, one part of each family; screw-cap.sc, a screw joint), opened again by solidcraft-cli run --in: 13 of 13 and 2 of 2 parts are told after the rebuild. Which SolidCraft wrote them (0.40.0-rc.4 or 0.40.1) the files do not say.

Third review

• a. A crash was kept as "SolidCraft does not build this part". Only SolidCraft's own answer is kept in the file: the parts.insert step failing with its reason, or another part built for the words. A crash exit code, an answer that is no JSON, a script that cannot be written or removed are remembered until PartBuddy ends (one try per start, and one more by an export), with a line in the log. Test: partReference.test.ts, "does not take a crash, or an answer that does not read, for SolidCraft refusing the part".
• b. Nobody mirrored again after a run without an answer, and an export could go out with the screw. A timer builds the parts once the five minutes are over; every background build ends in one mirror. Export, send to slicer, size list and the parts to buy try a failed reference once more and, when a body still cannot be checked, write nothing and fail with the reason, which the export's existing error notice shows ("standard parts could not be checked, so nothing was written (…). Try again in a moment."). Tests: "tries a program that gave no answer again after a while by itself…", supervisor.test.ts "exports no standard part, waits for its reference, and says so instead of exporting a body it could not check".
• c. The print check saw the screw while its reference was built. Such bodies are in structure.pendingParts and usePrintCheck.ts leaves them out; after the build they are standard parts or printed bodies again. Marking the report as provisional for that moment is left to the merge with fix(desktop): the assistant sees the print check of its changes, blocks measure before they cut #357 (its measuring field). Test: mirrorRevision.test.ts, "does not wait for a part SolidCraft is still building…".
• d. The kept file was taken on trust. Its key carries a format number; an entry is used only as a complete reference (every field there, every number finite, as many face areas as faces), else dropped and built again. Test: "builds anew what a kept file holds in another form, and takes no entry on trust".
• e. refresh() during a failing mirror was lost. That mirror is tried once more. Test: "does not lose a reference built while a mirror fails, and mirrors nothing again after a reset".
• f. More than 200 descriptions. ready goes on until nothing is being built (at most 20 runs). Test: "waits for every part when there are more than one run takes".
• g. screenshot {path} overwrote any file in the allowed folders (own commit). Every tool of SolidCraft the policy lets through is refused a file argument (path, file, reference, output); kept are compare_picture with the photo PartBuddy saved for the user (the photo note tells the assistant to use it) and skill_reference with a document's plain name. Checked against tools/list of 0.40.1: screenshot (path, wrote 442 140 bytes over a JSON file), compare_picture (reference, reads a PNG or JPEG), skill_reference (file, refuses paths itself) and batch (path, refused since the first review) take a file; the other tools answer "unknown argument". Test: agent.test.ts, "refuses a file argument on every tool of SolidCraft it lets through, but for a photo the user sent".

Still open

• While a part's reference is built (0.7 s once per part and SolidCraft program; 0.1 s after each start of the app) its body is left out of the print check, and the report does not yet say it is provisional (see c).
• An export fails with a notice when a standard part cannot be checked (SolidCraft's solidcraft-cli missing or not answering); it does not offer to export anyway.
• A shape is as strong as these measures: a body that meets volume, area, counts and every face's area, outline and radius of a library part within 1e-6 would pass. For the washer these fix the ring; no other body was tried.
• A library component with two bodies counts as printed altogether, the library's body too (marked shortcut: in mirror.ts).
• A real part whose description is changed in SolidCraft itself counts as printed.
• N-normteile-policy-4 and -5 (B: screenshot {path}, compare_picture {reference}, document.metadata.set {properties}) and S-30 (C) are not part of this change.

Not checked

• The contract tests (e2e/solidcraft.contract.spec.ts) and the app itself were not started. Two of them depend on the reference from solidcraft-cli inside the app ("standard part" on a seated SHCS M3x12, two standard parts after a screw joint); the same flows pass in the harness. One expectation changed: the screw joint test waits up to 30 s for the two "standard part" labels (they follow a mirror after the bodies show), as the other test already does.
• Designs written by SolidCraft 0.30.1 or a 0.40.0-rc, with parts put in from the menu: none is at hand and no other SolidCraft is installed here. If such a part's description or shape differs, its body counts as printed and the log names it: body "<name>" is described as "<description>" but is not that part (…) or …, which SolidCraft did not build to hold it against (<reason>).
• SolidCraft's window as the engine (not headless), and a part placed several times by one parts.insert.

Last review (commits df8c844, ebef1d6)

Six points on 46e330a and c38f5b6. Where this section and "Still open" above differ, this section holds.

1. pendingParts stayed for good when the mirror after the build failed. The body was left out of the print check until a mirror that never came. The scheduler keeps the last revision; when a mirror fails and that revision has bodies waiting, it goes out again without pendingParts, so the body is checked as a printed one. The owed mirror is tried three times, 5 s apart, and a mirror that works ends the debt. Test: mirrorRevision.test.ts, "hands a body that waited for its part back to the print check when the mirror after fails, and tries that mirror a few times only".
2. Without solidcraft-cli export, slicer and sharing package wrote nothing, for good. A missing program is its own state (unavailable), not a failed run: such bodies count as printed, go along, and the result's notice names them ("Included as printed parts, because PartBuddy could not check here whether they are bought standard parts …", German and English). Nothing is listed to buy. A run that fails for now still writes nothing. Tests: supervisor.test.ts (the export test, last block: { unverified: ['Nut'] }, the nut exported, no hardware), partReference.test.ts "says that no part can be built here when solidcraft-cli is missing, without a run or a timer".
3. A failing parts.library locked the export of a design without any standard part. Without the library no body can be taken for a part, so nothing is left unchecked; a rejected request counts like a failed batch. Test: mirrorRevision.test.ts, "leaves nothing unchecked when parts.library fails, so an export is not held up by it".
4. The photo exception was a pattern of the path. The policy compares the resolved path with the files PartBuddy kept and named to the assistant in this run; UNC, device and relative paths are refused before that. Refused in the test: another project's photo folder, a photo not kept, //server/share, \\server\share, \\.\, \\?\, relative paths, an 8.3 name, .., another file in the folder. Test: agent.test.ts, "takes for the user's photo only the file PartBuddy kept, not a path that looks like one".
5. The file lock hung on four argument names. Each tool let through has the list of arguments tools/list of SolidCraft 0.40.1 gives for it (without screenshot's and batch's path); any other argument is refused, also as a batch step. For engine commands file (sketch.replace) is refused like path, and inspect.compare_picture reads only a kept photo. Test: agent.test.ts, "lets a tool of SolidCraft through only with the arguments it is known to take, and with no file but a photo the user sent".
6. Timer chains without an end. A part whose run gives no answer gets three runs, by one timer for all parts that wait instead of one per run; the timer is called off with the design or the engine (forget). The mirror's retries of point 1 end after three. An export still gives a part one more run. Tests: partReference.test.ts "gives up a program that never answers after three runs, and waits for nothing once the design is gone", and the scheduler test of point 1.

Left open by this round:

• With a failing parts.library a real screw in the design is exported as a printed body with a line in the log only; the user gets no notice (unlike point 2, where the bodies are known by name).
• After the three retries of point 1 the body stays checked as a printed one until the next change of the design mirrors it again.

Checked in this round: eslint on the changed files, typecheck, and vitest for mirrorRevision, partReference, supervisor, agent, photo, structure, i18nKeys (all pass). Not run: the whole unit suite, E2E, the contract tests against a real SolidCraft, the app itself; the notice of point 2 was not looked at in the window.

🤖 Generated with Claude Code