TinyMaker 0.17 · testų pultastest checklist

Turn on the printer → animation → main menu with no freeze; WiFi badge appears within ~10 s.

tinymaker.local in the browser → page with live status (sync dot green), no console errors.

Change a setting (e.g., VAT ml) → Save → reboot → the value persisted.

Header shows a small v-badge next to the brand (not in the links row); newer version -> orange with an arrow; tapping it -> jumps to the Update pane; the theme icon top right is aligned with the title; NO reload loop (textContent is plain). Build hash in Update+About.

Origin: 0-39 / GitHub #50 (0.16.2). Verified: 0.16.2 (08-03, desktop+mobile+live)

Top-right of the PRINTER screen, on the main menu screens (not the dashboard): dry run -> orange DR; a newer firmware is available -> green NEW; a notification channel is enabled (Telegram/WhatsApp/Discord) -> bubble; Connect -> cloud icon; WiFi bars always shown (green when connected, gray when not). Packed right to left, no gap for missing ones; redrawn every 5 s. With all four, NEW starts at x=40, so check that the row doesn't run off to the left.

Origin: 1-37 (0.16.0-beta), drawWifiBadge() badge row V2. Text corrected from the code on 2026-08-26: it previously incorrectly said "dashboard" and "new model -> NEW" (NEW = firmware update).

What to do. Upload a model or share the dashboard, and watch the message area the whole time (on the computer and on the phone).

What to expect. The progress message stays in place; the yellow "the printer stops answering" appears only when the printer really isn't responding, and it doesn't alternate with the progress message.

Why. The yellow message used to pop up when the printer was simply busy with its own work (V's finding, 2026-08-22).

On the landing page, empty IP field → "Open" is dimmed; placeholder clearly says "e.g. …" (doesn't look like an entered value).

Origin: a user clicked Open on an empty field and thought it was broken, 07-16.

Open tinymakerwifi.com/demo/ → wait ≥5 s → the URL STAYS /demo/, fwVersion shows the current version, no console errors. (After every demo regen!)

Origin: the shim's hardcoded old firmwareVersion used to trigger the stale-UI guard → location.replace('/') → every demo visitor was bounced back to the landing page (user finding 07-18; fix: build_demo.py patches the shim from platformio.ini).

What to do. In the dashboard header, on the right, click the three icons in turn. With "System", switch the computer's or phone's theme. Reload the page. Open Manual, Feedback, Roadmap.

What to expect. Light and Dark stay independent of the system, System follows the system right away. The choice persists after a reload. Opened links are in the same theme.

Origin: V, 2026-09-23 - unifying themes across the whole site; the old ◐ button only toggled between two states. 0.18.3 (#232).

What to do. In a browser without the TinyMaker extension, open the dashboard and hover over "Browser extension". Then install the extension and reload the dashboard.

What to expect. Without the extension the link sits after "Feedback" on the same row, and hovering shows an explanation. With the extension installed the link is gone and the row doesn't break.

Origin: V, 2026-09-23 - the extension should "arrive together with the printer software"; the first version was a separate row, which broke. 0.18.3 (#232).

What to do. Put links.json with two links (format - docs/api.md) in the SD root, reload the dashboard. Then delete the file and reload again.

What to expect. With the file, the links appear in the header after "Feedback" / "Browser extension". Without the file the header is exactly as always.

Origin: V, 2026-09-23 - a manufacturer or school wants their own links (support, a resin list) on their printer's dashboard. 0.18.3 (#223).

What to do. In the dashboard header, click "?" (Getting started).

What to expect. The second step is called "Slice a model - built-in slicer or PrusaSlicer", and the description suggests turning on the dashboard's slicer or setting up PrusaSlicer. You check it off yourself.

Origin: V, 2026-09-23 - a new user used to think they couldn't start without PrusaSlicer, even though the dashboard has a slicer. 0.18.3 (#225/#226).

Upload an SL1/ZIP through the dashboard → "Receiving" bar grows → LCD "Unpacking layers" bar+counter → the model is in the SD list with the correct layer count.

Delete a large model through the dashboard → LCD "Deleting:" bar, the snackbar stays up until the end → the list refreshes. The message must be ONE: from the click to the end it's the same box, in which only the numbers change.

Origin: user finding 0.14.3. On 2026-08-27 V caught that it looks like three messages, and there were three causes: (1) the first snack had no bar at all - once the printer announced the job it suddenly appeared and the box got taller; (2) the empty number field collapses to zero, so once "120/240" appeared the box widened and re-centered; (3) between the HTTP response and the job being announced, deleteBusy is already cleared but sdJobCur isn't set yet - in that gap the yellow "Printer not answering" popped up, and msg() rips the progress snack out from the middle. Additionally: the moving bar was scrolling right and getting clipped (looked like it was shrinking), while the real one was growing from the left - two opposite directions. Fixed in c7264a1: a reserved box, a quiet track with "starting…", a silence window before the job is announced (20 s limit), and a fixed-width counter (U+2007).

On the phone, the yellow message at the start is KEPT (V's decision, 08-27): the other device didn't click, and for it that message meaningfully says "something is happening" until the layer snack arrives.

Verified: 0.17.0 c7264a1 (2026-08-27, on the hardware - V: "Deleting is very good")

What to do. Upload a bigger model (a few megabytes) through the dashboard's Upload and watch the message for the whole upload. Repeat the same uploading from PrusaSlicer, just watching the dashboard.

What to expect. One message: Uploading <name>, below it a second line "Progress shows on the printer screen", at the bottom a sliding stripe - no seconds and no megabytes. When the printer starts unpacking, the same message rewrites itself to Unpacking <name> with its real numbers. The sentence doesn't alternate with "the printer stops answering", the message doesn't disappear or pop back up, and its position on screen doesn't jump. The model name is always bolder than the sentence.

Why. While the printer is receiving bytes, it doesn't respond to polls - and the error message used to push out the progress message, which the next chunk of bytes then redrew. Flickering every two seconds (V's finding, 2026-08-18).

What to do. On the computer, slice an STL and click Save to printer. On the phone, at that time just watch the dashboard - don't click anything.

What to expect. On the phone there is one message "Receiving <name> from another device", it doesn't flicker and doesn't disappear while the bytes are transferring. Afterwards it switches on its own to Unpacking with the real layer counts. The "the printer stops answering" complaint may flash once right at the start and won't come back.

Why. While receiving a file, the printer barely responds, and in the gaps between the two transfers (preview cache, then the model) it used to answer "free" - the phone turned that into a message that appears and disappears. V saw three flashes (2026-08-19). Now the printer itself says that it's receiving.

What to do. Upload a ZIP; separately - delete a model. Watch the dashboard message.

What to expect. "Unpacking name N/M (xx %)" - the same wording on the dashboard, the printer screen, and in the status. No "Stopping - finishing the current layer".

Why. The stopping message was tied to "busy", and the printer is also busy during an SD card job, while the stopping flag stays set from the previous print. Verified: 0.17-dev a18d12d + b8d6f23 (08-14, on the hardware)

What to do. Click Share and watch the button and the message; separately - upload a model through the dashboard; separately - open a preview while another window has already taken the printer.

What to expect. Share locks with a spinner until it's done (a second click is impossible), then turns into "Shared". While it's quiet, the message names the actual job ("Sharing this model…", "Uploading the model…"), not a guess; when we haven't started a job - one line with possible reasons. A failed preview shows the reason and retries on tap (not a dead "Preview failed").

Origin: V, 08-13 - after clicking Share the dashboard used to show a long guess "probably uploading", the button looked dead, and after a failure only F5 was left. Verified: - found and fixed on 2026-08-27: Share on models with a saved preview used to break with localPreviewBlob is not defined (V's finding). The function had been removed as dead code (dbaa417) - our dashboard truly has no caller for it, but the Connect app calls it, loaded FROM THE SERVER, so a search across the repo doesn't see it. Restored + exported to window + a comment DO NOT DELETE. Retest specifically a model with a saved preview (V's case: Bibigon), not just any model.

What to do. 1) In the SD list, click the model's row - the preview opens, check that the model is whole. 2) In the same card, click Share and wait for it to finish - the dashboard will take you to Connect (that's how the Connect app itself is designed, not on our side). 3) Go back with the top printer button and click the same SD row again. Don't go to another model - it was exactly that switch that used to hide the bug.

What to expect. After the third step the model is drawn whole, the same as after the first - not cut off flat at the top. The same after clicking again.

Origin: V's finding, 2026-08-29, while testing T-48. The Connect app (loaded from Brian's server) calls our own fetchSlices(..., 'source05'|'print1') during sharing, and it writes into the same global slicesCache. Those previews are built with a different layer count and height, so the cache would keep the same model's name with someone else's height, and the dashboard would accept it as its own - the model looked cut off. Switching to another model reset the view, because the cache is rejected when the name doesn't match. Fixed in 4e70ea3: slicesFit() only accepts its own modes.

Verified: model whole even after Share. Red: cut off. After the fix, the dashboard in the browser needs to be reloaded with Ctrl+F5 - the old page keeps the old code.

What to do. 1) In the SD list, click the model's row and wait for the preview to settle. 2) Click Share - the dashboard will take you to Connect. 3) Go back with the top printer button. Repeat the same after going to Settings and back.

What to expect. In the card - the model's image, the same as before leaving, and detailed: the preview never shows the coarse image, coarse is only for print progress. After Share the image resettles from scratch (a few seconds with a bar) - that's normal; what matters is that at the end there's a detailed model, not coarse cubes. Not a frozen "Building the 3D view 100%" with a full orange bar that only lets go after clicking the row again.

Origin: V's finding, 2026-08-29, right after T-101. Connect and Settings are separate views, so during them the preview canvas is hidden, and openView also cancels the ongoing layer load. If the cancellation lands right after the last layer, the loop guard no longer throws "preview superseded", the trap doesn't trigger, and the build finishes onto an invisible canvas. V's question was also the answer: after Share it should stay the same as after going to the slicer - and the slicer lives in the same view, so its canvas never goes anywhere. Fixed: on returning to the printer view, the image redraws itself.

What to do. Share a model, finish the upload in the Connect window, then go back with the top printer button to the preview. Don't go anywhere else and don't click anything.

What to expect. The Share button immediately shows that the model is already on Connect (turned yellow, "Already on Connect"). No need to reload the page or navigate through tabs.

Origin: V's finding, 2026-08-29. The Connect app writes the public ID into the model's metadata, and the actual publishing happens even later - once the person clicks Upload on their side. Our refreshShareStateSoon would have already stopped asking by then: it gives up when the printer is busy, and Connect is exactly then pulling all its layers into the archive. So the mark only appeared after any move that re-reads the model. Fixed: returning to the printer view is exactly that move - now it re-asks there.

What to do. Upload a new, not-yet-shared model to the SD card and click Share. Watch the Connect window while it builds both previews (0.05 and 0.10 mm).

What to expect. Both times the whole model is drawn. The second preview may have coarser cubes, but the same height - not cut in half with a flat top. Back in the dashboard preview, the model is whole too.

Origin: V's finding, 2026-08-29 (sittingPredator4, 540 source layers). Connect asks for a 0.10 mm preview and passes the print layer count (270), and our fetchSlices used to take that number as the source index limit - i.e. it drew the bottom half of the model. mode was accepted but not used for the indices. The cut-off preview would travel to Connect and stay in the card. Fixed: 0.10 mm now takes every other source layer.

⚠️ For models shared before this fix, the card holds the wrong 0.10 mm preview and Connect will reuse it. To fix it, it has to be removed so it gets rebuilt.

What to do. Click Share and, while it's working, deliberately navigate around: go back to the printer view, open Settings, return to Connect. And separately - try to open another model's preview while the sharing is still running. Don't rush - do this during the first preview.

What to expect. The sharing continues: Connect goes through both previews, packages the model, and offers Upload. There's no "preview superseded" and the progress doesn't stop halfway. Clicking another model, the dashboard says "Not now - sharing this model…" and doesn't start loading the preview - the printer serves one request at a time, so that preview wouldn't have loaded anyway. Once the sharing is done, that model opens normally.

Origin: V's finding, 2026-08-30, also reproduced on a clean morning base - i.e. an old bug. openView, when leaving the model view, used to cancel the ongoing layer load (fetchSlicesSeq++), and Connect builds its previews using exactly that same load - and its own progress carries the person into the Connect view. Fixed: while sharing is in progress (shareInFlight), the load is no longer cancelled; only our own background job is stopped.

What to do. Share a model that hasn't been shared yet (important: for models already shared, Connect takes the saved previews and draws nothing, so the bug wouldn't show up). Wait until its image appears in the Connect window, and go back to the printer view.

What to expect. The model is still there in the preview. Not the text "Building the 3D view 100%", appearing at the exact second Connect drew its own preview.

Origin: V's finding, 2026-08-30. The detailed image is drawn as a GPU layer above the canvas, and the canvas underneath keeps the last 2D frame - right after a detailed build that frame happens to be the progress text. drawIso is a shared function, and Connect calls it with its own canvas; at the end it used to clear the layer for any canvas that wasn't ours, and the old frame would show through underneath. A temporary trace inside buildIso showed zero new calls - that ruled out every other theory. Fixed in fcb726e: drawing to a foreign canvas no longer touches the layer.

Upload a large model → right after Unpack the SD list is FULL (doesn't disappear, doesn't shrink).

Origin: feedback #4 - truncated JSON on a fragmented heap → out.reserve + an ok field + integrity check, 0.15.3.

Delete a large model → LCD shows "Deleting:" + a bar, the dashboard message stays up until the end, the list refreshes, the printer returns to the main menu.

Origin: user finding 07-17 ("looks stuck") → aef9cbb, 0.15.5.

Model A's preview left open in the browser; start model B from the LCD → the card shows a note, NOT the wrong model A.

Origin: the always-on card preview, 0.15.0.

Printing / no SD / Web control off → the Upload button is disabled with a clear hint; idle with SD - active.

Origin: the "why is Upload orange while printing" finding, 07-16 → syncUploadGate, 0.15.4.

Open the dashboard on two devices; on one delete a model or import a ZIP/SL1 -> the job is visible on BOTH with a snackbar, the list refreshes when done, the printer stays responsive.

Origin: 1-32/1-33 (0.16.0-beta) - long SD jobs moved out of the HTTP handler into the idle loop (sdJobRun, responds every 200ms); printerBusy() covers the job.

What to do. Upload a model (any way) and look at the list. Then upload another one.

What to expect. Every new model lands first, old ones (uploaded before 0.17) stay at the bottom in alphabetical order, archives at the very end. There's no toggle, and there's no date row.

Why. The list is a work queue, not an archive. It's sorted by the printer's counter, not by date - without internet the clock doesn't sync, and the date would be an eternal zero (V, 2026-08-19).

What to do. On the computer, hover over a few rows, then click Start without selecting the row. On the phone, open the same list and look at the unselected rows.

What to expect. On the computer, hovering over a row reveals Start and Delete, the list doesn't jump from this, and Start launches without ordering a preview (the "Start this print?" question stays). Delete is pulled back from the edge by the same amount as the icon on the left. On the phone the rows are compact - no empty bar; the buttons only appear on tap. The Tab key also reveals the actions.

Why. Clicking a row orders a preview, and that occupies the printer itself; the mouse is an intent signal that the phone doesn't have. On the phone, the space for the buttons used to turn into an empty bar (V, 2026-08-19).

What to do. In the SD manager, go to the second page and then upload a model - through the dashboard or from PrusaSlicer. Don't navigate anywhere yourself.

What to expect. Once unpacking finishes, the list returns to the first page on its own and scrolls to the model just uploaded (it's on top - see T-79). Typing in the filter field doesn't take away the view.

Origin: V's finding, 2026-08-27 - after uploading while standing on the second page, the person stayed there, while the model they had just sent sat on the first. Fixed in c7264a1.

Verified: 0.17.0 c7264a1 (2026-08-27, on the hardware - V: "OK")

Verified: 0.17.0 0b6e5a0 (2026-08-31, Claude browser via Chrome)

What to do. On the dashboard upload an STL bigger than the plate, click Fast fit, then PLACEMENT → lifted and Slice.

What to expect. In the line "Sliced in N s · N layers · ~N ml" and further on - "Scaled down N% - the supports reached past the plate, and they still do. Scale the model down by hand before printing." The same sentence at the bottom of the list with ⚠ and yellow. The key point: if it still doesn't fit after scaling down, that has to be stated, not left unsaid.

Origin: the FIT-real work, 2026-09-12 (PR #137 engine + #138 dashboard). Before that, the "fits or not" verdict was decided BEFORE the supports, from the worst case, with the cost fixed at 15-20%; and after scaling down, the card would just say "scaled down" and go quiet, even though the part could still not fit. A test bench confirmed the audit's calculation: a 96 mm cup is scaled down 73.2% and still sticks out 3.5 mm.

Verified: 0.17.1 + module 3.4.0 (2026-09-12, build 911fb38) - Claude on the dashboard: `aukstas.stl` 62 × 44 mm got "Too large - width +60%", Fast fit fit it to 38.8 × 27.5 mm (1 mm from the edge), with "lifted" it scaled down 25.2% and said it still doesn't fit. V's model (996,658 triangles, 48 MB): scaled down 11.6%, two passes took 101.8 s. V confirmed by eye: "3 tests OK".

What to do. Have a sliced model that the engine scaled down (see T-125). In the name field, type a name that's already in the card, and click Send to printer. In the prompt pick Rename.

What to expect. At the end, one message: "Saved as "X-2" - that name was taken. · Scaled down N% - …". The scale-down warning has to be attached, not dropped.

Origin: findings from the fifth and sixth gate rounds, 2026-09-12. The rename branch read the flag AFTER the saved file's data had already been cleared, so the condition was always false and the warning was never said on that path - the card closed, the warning line cleared, the snack showing only "Saved as X". Before that, the same spot relied on a variable from a different function, i.e. a loud failure had been replaced with a silent one. Neither `node --check` nor compilation catches this - the bug is in the execution order.

Verified: 0.17.1 + module 3.4.0 (2026-09-12) - Claude recorded the message bar: "Saved as "aukstas-3" - that name was taken. · Scaled down 25.2% - the supports reached past the plate, and they still do." Along the way it was confirmed that the messages go one at a time, without overwriting. V confirmed: "3 tests OK".

What to do. Upload a flat model that fits, PLACEMENT → auto, and click Slice.

What to expect. "No supports needed - nothing on this part hangs in the air" and no scale-down message. Silence here is the correct answer: without supports and a pad, the true footprint equals the model itself, and it fits.

Origin: FIT-real, 2026-09-12. This row guards against the opposite flaw - a new message showing up without reason. If it appears for every model, people learn to ignore it, and then it won't help where it's actually needed.

Verified: 0.17.1 + module 3.4.0 (2026-09-12) - Claude: `aukstas.stl` flat, 100 layers in 8.6 s, "No supports needed", not one scale-down sentence. V confirmed: "3 tests OK".

What to do. In the slicer card, upload cup15.stl at full size and click Slice. Wait until the card shows the scale-down sentence.

What to expect. The row under the file name ("cup15.stl · … mm · … triangles") shows the already scaled-down size, the same one the scale slider shows, not the size before scaling.

Origin: V on the printer, 2026-09-12, with cup15.stl saw 24.0 mm, even though the engine had scaled the part down to 19.7. The slider and the height field would update, but this row didn't. Someone who needs the real size (a ring, a holder on a shaft) would read the old number and get a smaller part. Fix in PR #140.

Verified: 0.17.1 + d12f9f6, module 3.5.0 (2026-09-13) - V's photo: "cup15.stl · 19.7 × 19.7 × 17.3 mm · 1,024 triangles".

What to do. In the slicer card, upload any model, in the 3D toolbar click % (Scale) and in the percentage field click the up arrow a few times, then down.

What to expect. Up: 100 → 101 → 102, down goes back. Once it reaches the plate limit, the card says "Too large".

Origin: V on the printer, 2026-09-12 - the up arrow didn't work at all, down worked. The field's min was 0.1, and the step was 1, so the browser climbed to 100.1, which the card rounds back down to 100. Fix in PR #141.

Verified: 0.17.1 + d12f9f6, module 3.5.0 (2026-09-13) - V: "the arrow works".

What to do. On the dashboard check how many resin profiles you have. Then through PrusaSlicer "Send to printer" (or a dashboard upload) send any model named resin. Then another one named Lib. After that, send an already existing model under the same name again.

What to expect. The models appear in the list as resin-model and Lib-model. The resin profiles and the slicer module stay untouched (same profile count on the dashboard, the slicer opens without internet). Re-sending an existing model quietly replaces the old one, same as before.

Origin: the security audit before 1.0.0 (2026-09-17) - a PrusaSlicer upload named resin.sl1 used to overwrite the /resin folder and delete all resin profiles with their calibrations; lib - the slicer module. Fix c14b6e9 (PR #172).

Verified: 0.17.5 + 2e6f5e6 (2026-09-17) - via /api/files/local: resin → resin-model, Lib → Lib-model, re-sending resin replaced the same model (no -2); 9 profiles and slicer module 3.5.0 untouched.

What to do. On the computer (wide window, two columns) open the dashboard and leave it open. From another device or from Resin Lab, upload a model with a long name and no spaces, e.g. Lab-Test_03_kubas_tm-005. When it appears in the list with the New mark, click it (select it) and click Next and Prev a few times.

What to expect. The name is on one line (if it doesn't fit it ends in "…", the full name shows on hover), the New mark sits at the end of the date row, all rows the same height. The page counter (e.g. "1 / 5") stays in place and only changes on click - the list doesn't jump between two pages.

Origin: V, 2026-09-19 - a long new name used to wrap onto three lines, the row-height measurer then gave 3 rows instead of 5, and after Next the list would jump between "1 / 5" and "2 / 8" several times a second. An old model with no time or size (no date row) did the same. Fix PR #200, released in 0.17.7.

Verified on the bench (2026-09-19): old dashboard 43-45 switches in 3 s, new one 0; rows 58-59 px.

Verified: 0.17.7 on the printer (2026-09-19, V) - the list no longer flickers.

What to do. Open the slicer in the dashboard and load an STL. Supports → no → Slice. Then Raft layers → 3 → Slice. Then Supports → regular, Size → keep → Slice with a model whose supports reach the edge of the plate (e.g. cup15).

What to expect. With "no": Strength, Placement, Tip and Fit by are locked, Raft shows off, the button is called "Fit size", sliced without supports and without a raft. With raft 3: the raft rings around the base. With keep: the size does not change, the card warns that edge supports will be cut off. If the printer's slicer module is older than 3.6.2 - "no" is locked, the card hints to update and reload the page.

Origin: slicer module 3.6.2 (PR #202), released in 0.17.8 (2026-09-19).

Verified: 0.17.8 content (`ec66324`) on the printer 2026-09-19 - V and Claude (9 frames: no, raft, keep, locks, sending to SD).

What to do. SD manager → tap a model, wait for it to load. Open an empty slicer (no STL), go back to SD. Repeat with a loaded STL. Then tap the SD model and, while it is still loading, immediately open the slicer.

What to expect. The header changes together with the card: on the slicer "Slicer preview", on SD - the model name. Going back to SD, the model returns (also after an empty slicer). The slicer view stays as it was. While SD is loading in the background, the slicer view shows "?", the pan and rotate buttons are visible, Share is disabled; on an empty slicer the SD model is not drawn.

Origin: V 2026-09-19 - going back from SD while it was still loading used to lose the "?" and rotation (since 0.17, `cardBusy`), and an empty slicer used to forget the SD model and show "Model preview" (since 0.17.0). Fix PR #203, released in 0.17.8.

Verified: 0.17.8 content (`ec66324`) on the printer 2026-09-19 - V ("works OK") and Claude (bench A-D, 6-path regression live).

What to do. In a browser where the dashboard has never been opened (incognito or a new phone), open the dashboard. Then ▶ next to “STL slicer”, then ▶ next to “SD manager”.

What to expect. The first time, SD is open with its list and Upload, the slicer is collapsed. Opening the slicer leaves the SD card's header and space strip (how many files, how much space), no Upload. Opening SD brings the list and Upload back. The choice is remembered after a reload.

Origin: V 2026-09-22 - collapsed SD showed Upload, and a collapsed slicer showed only its header; a new person saw the slicer first. PR #207, released in 0.17.9.

Verified: `ba00a47` on the printer 2026-09-22 - Claude (Chrome, empty browser storage).

What to do. SD manager → a small unneeded model (a few hundred KB) → Delete → OK. Then the same with a larger model.

What to expect. Small: “Deleting X · starting…”, after 1-2 s “Deleted X”, the model disappears from the list without an F5, the message clears itself. Large: progress with numbers, one “Deleted X” at the end.

Origin: V 2026-09-22 - a small model was deleted faster than the next poll, and “starting…” used to hang with the model still in the list until an F5 (since 0.17, reproduced on the bench). PR #213, republished as 0.17.9.

Verified: `21cbdb4` on the printer 2026-09-22 - V ("works"); bench: instant and normal deletion.

SD row Preview → 3D view in the card, "In preview" mark on the row.

What to do. Open the model preview in the dashboard. Flip the view, look from the top and from the side. Close and open the same model a second time - measure how long the view takes to settle, the first and the second time.

What to expect. Supports touch the part, they don't hang with gaps. Smoothness is the same from the top and from the side. The box is the same, both while loading and once the 3D is ready - the same angle and the same proportions. The loading bar sits below the label, not on the edge of the box (it is visible for every model - the view is always rebuilt from scratch; pick a bigger one, e.g. Predator or xenomorph, so you have time to see it). The second open is noticeably faster than the first, but not instant: the view is always rebuilt from scratch and always detailed, so the cache shortens the build rather than skipping it (measured 2026-08-31, 3 MB models: first 34-42 s, second 14-24 s).

Origin: 0.17 #93 (PR #97). Split on 2026-08-27 - four tests had been merged into one, three of them needed the browser console and deleting files from SD (V: "I understood nothing"). The technical part moved to T-98 (stage chain) and A-6 (checksum). Dust wiped off on 2026-08-31: all mentions of the "Detailed" button were removed - it hasn't existed since 08-20 (#gl3dZoom #gl3dDet{display:none}, V's decision: the view is always detailed), so the test used to wait for a button that doesn't exist. This also fixed the "second open is instant" claim - measured, and it wasn't true and can't be.

Verified: 0.17-dev 01fa716 (08-12, on hardware: full 154-layer dry run, 8 models re-scanned into TMV2)

What to do. With "Detailed" on, open a large model (scull, 240 slices) and, during the whole load, scroll the page, tap tabs, switch theme.

What to expect. The page keeps responding the whole time; Chrome does not show "Page Unresponsive"; above the box real percentages grow ("Building the 3D view — 42 %"), then the surface itself crawls from the bottom to the top.

Measured. In the console with a MessageChannel ticker (not requestAnimationFrame — it is throttled in the background): the longest single-thread block must be < 0.5 s. On "scull" measured 855 ms → 403 ms, total duration 66 s → 45 s.

Origin: V 08-13 — the browser offered to close the page at "smoothing 240 slices". Reason: the mesh, surface and drawing ran on one thread with no break. Fix: the same calculations rewritten as generators + a MessageChannel pause (a background timer would be throttled). The mesh result after the rewrite is bit-for-bit the same (46584 vertices, 62080 quads). Verified: 0.17-dev 4425977 (08-13, on hardware: blocks ≤ 403 ms)

What to do. In the dashboard click the square in the card's header: the block expands to the proportions of the print volume; click again — it returns. Repeat on a phone and in a narrow window.

What to expect. Once expanded the box fits WHOLE (neither top nor bottom cut off); the tools stay next to the view, not in the screen corners; one border; the icon turns into "two squares" (like Windows "restore"), and in the normal state — one square. An un-maximized dashboard fits the screen together with the orange page border.

What to look at. The box must be the same size before and after the 3D loads (3D frames the whole volume, same as the drawing). While loading the box is smaller — that is expected, it is a sign of loading.

Origin: V 08-13 — the full-screen preview used to cut off the view in a narrow window, "Close" used to stick to the browser bar, on a wide screen the tools scattered into the corners, a border showed inside a border, and the card no longer fit. Fix: full screen dropped — the block simply expands to width/0,611 and does not grow further after that. Verified: 0.17-dev 03d62dc (08-13, on hardware: 486×795, ratio 0,611)

What to do. Open the model preview and use the section control to lower/raise the section height; check whether real layer steps are visible.

What to expect. The model is cut at the chosen height, voxel steps are visible on the cut plane; restoring it shows the whole model again.

Why. PR #104: lets you see what is inside and how the layers will lie, before printing. Verified: 0.17-dev adb9644 (08-15, on hardware - V's verdict "very good")

What to do. Open the model preview and switch to the flat (2D) view. Look at the model's corners and at the block's own height; switch back and forth several times.

What to expect. The whole model fits in the frame - not a single corner is cut off. The block stays the same height as in the 3D view, the window does not jump. The plate's edges are marked with corner marks.

Why. The flat view used to change the block's height and cut off the model (V's finding 2026-08-22).

Verified: 0.17.0 0b6e5a0 (2026-08-31, Claude browser via Chrome)

What to do. Open the slicer preview and use the layer slider on the right. Then open the SD card's model preview and the section slider in the same place. Check both in a large window and on a phone.

What to expect. Both sliders are the same length, they don't stretch the full edge (mostly about three quarters of the height) and don't overlap either the buttons above or the bottom bar.

Why. There are two of them: the slicer's and the SD preview's. Fixing one left the other untouched (V's finding 2026-08-22).

Verified: 0.17.0 0b6e5a0 (2026-08-31, Claude browser via Chrome)

What to do. In the preview, find the two view buttons. Use the first to switch 3D: with supports ↔ without supports. Use the second to switch 2D: with supports ↔ under UV light.

What to expect. Four views, all on the same plate. The buttons are found right away - no views hidden in a rotation. The UV view is purple. verified: 0.17 (2026-08-22)

Why. Previously all views lived in one rotation, and the UV view was hard to find (V's finding 2026-08-22).

Verified: 0.17.0 0b6e5a0 (2026-08-31, Claude browser via Chrome)

What to do. In the dashboard open the model preview, turn on Raw voxels and drag the section slider.

What to expect. You see real 0.13 mm steps (our pitch is 0,1275 mm), not a smooth surface and not a blurry mush.

Why. The toggle came with PR #104 (e40f58e); its purpose is to show how the print will actually look. Origin: issue #101.

What to do. Toggle smoothing (the wavy icon), open another model - the toggle should stay where you left it. Then reload the page.

What to expect. Within one page load the toggle stays (it is that window's view mode), and after a reload it returns to the default - real layers shown, no smoothing. This is not a bug: it was decided this way on purpose. For comparison, the cage behaves differently - it is remembered (tmViewCage), because it is a setting, not a mode.

Why. Issue #101 asked for it to be remembered, but the decision was reversed: smoothing is a view mode, not a setting, and it lies - measured that 24% remains from the raft, while the raft itself disappears from the view. Remembered silently, it would show a piece without a raft for the rest of the session. The code says this out loud: dashboard.html:3278 "Not saving: this is a view mode, not a setting".

2026-08-31: the line was reversed to match the code - it previously required the opposite of what the firmware deliberately does.

What to do. Preview the same model with Raw voxels on and off, back and forth. Repeat in light and dark theme and on a phone.

What to expect. Each time that mode's view is drawn. No old mesh, no gray flash when switching.

Why. The model mesh is cached; if the cache key doesn't include the mode, the old mesh is returned. Origin: issue #101.

What to do. Open a model and click the square at the top of the preview card. Repeat on a phone.

What to expect. On a computer the layout collapses into one column and the view takes up the full width to the orange line, and the right-hand cards drop below; the height does not exceed the window. On a phone - as before: just a taller block. In both cases the tools (bar, zoom, layer slider, pads) stay inside the view, and the page does not scroll sideways. A second click restores it.

Why. On a computer the second column takes up half the window, and the model without a cage is best seen in a wide window (V, 2026-08-19).

What to do. Switch the dashboard to light theme. Open a model preview and check all preview buttons (rotate, zoom, pads, view buttons, help). Switch back to dark.

What to expect. All icons are visible in both themes - none dark on dark or light on light.

Why. In light theme, nine buttons were dark on dark (V's finding 2026-08-22).

What to do. Toggle "as printed" back and forth; open the preview and switch to 3D; rotate the 3D view, open another model and go back.

What to expect. The diamond does not change shape when flipping; 2D and 3D don't differ in angle; "Preview" always starts at the default angle.

Why. There used to be two different angles (23.8° upright, 13.4° inverted) and five hand-written sizes. Now everything is calculated from one CAM_PITCH_DEG (20°). Verified: 0.17-dev 9f400e2 (08-14, on the bench + on hardware)

What to do. While printing, compare the same model on a computer and on a phone, opened after the print has already started.

What to expect. Gaps between the part and the supports are the same; the ring's hole does not turn into a pancake.

Why. The live buffer was 64×48, and the cache 80×60 — downscaling used to fill in ~19 % more area. Since 08-14 both are 80×60, so pre-filling is a simple copy. Verified: 0.17-dev cf11c1d (08-14; maxAllocHeap unchanged — 49 140 B, Telegram message arrived)

What to do. Unlock the slicer (seven taps on the version), open a model, in the preview tools click the target button. Tap the model (point), then drag your finger across the model (area). Click Copy.

What to expect. Turning the tool on puts an orange border around the view, and the view no longer rotates (that is expected). A point gives millimeters and the layer with the pitch ("~L152 @0.10 mm"), an area gives the size in mm and the layer range, a wireframe cage shows on the model. The mark list is below the preview card, it doesn't cover anything, and the tool can be turned off with the same button. The copied report has the slicer version, the dashboard's ETag and the firmware build.

And more. Mark a spot without slicing, then slice and mark the same spot. The report must have two groups - BEFORE SLICING and SLICED - and the contact sheet must show the stage next to each number.

Why. A verbal description no longer says, a week later, which version it was; a floating list on a phone used to sit right on top of the button itself; and a mark without a stage doesn't say whether it is about the model or about what the slicer did with it (V, 2026-08-19).

What to do. Start slicing and, while it runs, try clicking dashboard buttons (Start, Settings, SD actions). When it finishes don't reload the page and try again.

What to expect. During slicing the controls are inactive and a spinner turns - exactly like during a print. Once it finishes everything unlocks by itself. verified: 0.17 (2026-08-22)

Why. Slicing was not recorded into the "printer busy" state, so the dashboard stayed unlocked (V's finding 2026-08-22).

Verified: 0.17.0 0b6e5a0 (2026-08-31, Claude browser via Chrome)

Stop/Pause/Resume via the dashboard OR the printer's button, on PC and on a phone, + a cold refresh -> every snackbar in the middle of the screen (no longer stuck at the top on a phone, nothing scrolls under the bar).

Origin: V field tests (07-22) - tap-anchored toasts on a phone used to stick to the top / content used to scroll under the bar. Doctrine: all centered (snackCentre).

What to do. 1) In the SD list, look at the model rows - under the name there should be a time and a size (about 1h 12m · 3.4 MB). 2) Click a model - in the card Estimated time should match what the row showed. 3) In settings switch the resin profile and go back to the list.

What to expect. The time is shown for every model uploaded with 0.17, and switching resin all rows recalculate (a different exposure - a different time). Old models uploaded before 0.17 don't show a time at all - that is expected: their layer count was never recorded, and re-reading them would be slow.

Origin: plan item EST-model (V 2026-08-07, #83), done together with the resin profiles (0-16). Added to the test list on 2026-08-31 by V's decision - until then it hung next to the list as review and would have stayed unclosed.

Verified: 0.17.0 0b6e5a0 (2026-08-31, Claude browser via Chrome)

Settings → Update: shows installed/latest correctly, the picker list = window size (not infinite).

Disconnect the internet (not LAN) → Update tab opens, the UI doesn't stall; a failed check is cached (reopening doesn't block).

Origin: "GitHub freeze" — an uncached failed check used to stall the whole printer, 0.15.x.

With an older version on the printer: the Update screen itself offers a new one → Install → reboot → new version; the "Install update?" confirmation is shown.

Origin: 0.15.4 promotion rehearsal 07-16 — first full check.

After --beta: /releases/latest and version.txt still show the old stable; the picker shows the beta.

Origin: 0.15.0 beta became GitHub's "Latest" and the web flasher handed out the beta — flipped back by hand; now --beta marks a prerelease.

What to do. In the dashboard open Settings → Update. On the printer screen open System → Update. Then in the card pick another version (e.g. an earlier beta) and click Install selected; afterwards go back to the latest the same way.

What to expect. The card and the screen show the stable channel's version, not "unknown" and not "Version check failed". The chosen version downloads with a progress bar on screen and the printer reboots into it in about 35 s. If anything answers "Update refused" or the check fails - that is a red flag, because that printer's self-update does not work.

Origin: PR #146 (@DeadlySIn777) - the update used to not check GitHub's certificate, so on someone else's network anyone could have installed their own firmware; + PR #166 (extra Let's Encrypt root certificates). Released in 0.17.5.

Verified: 0.17.5 + #146 + #166, build 0110eec (2026-09-16) - version check "Up to date", screen "Latest: 0.16.2", 0.17.4 installed over a verified connection and rolled back, bad versions rejected (400), slicer manifest 1.5 s, memory unchanged.

What to do. Still on 0.17.5 in the dashboard, turn off the slicer (Settings → Network → STL slicer in the dashboard → Save config). Then power the printer off and on - once booted it checks for an update itself and offers Install. Install it and check the dashboard. Then turn off the slicer again, now on 0.17.6, save, and reboot the printer again.

What to expect. After the update the slicer IS in the dashboard (the card is visible, the toggle is on), even though it was off before that - this is a one-time turn-on. After the second turn-off and reboot the slicer stays OFF: the owner's word wins, and nothing turns it on again.

Origin: K9 (PR #162), released in 0.17.6 (2026-09-18). 0.17 wrote "off" on every settings save, so just changing the default value would not have been enough - a one-time switch with an NVS flag was needed.

What to do. In the dashboard check which resin profile is active (the pill under the status fields), then open the resin picker. Compare: is that same name in the list.

What to expect. The active profile is always visible in the picker with a checkmark. If its file is not on the card, the dashboard must say so - not show a name with nothing behind it.

Origin: Claude's finding 2026-08-31 while testing T-112. The printer showed sunlu-tough2, but /resin/sunlu-tough2.json was no longer on the SD card - the picker only had fast and slow. Profiles live on the card, while the selected name lives in the device settings, so they can drift apart. The danger is real: V's actual calibration values were only in /api/config, so switching profiles would have lost them for good. Worked around by deleting the dangling name and keeping the library's sunlu-tough. Note: the printer SCREEN already shows this - Interface.ino:739 writes slugToTitle(name) + " (missing)". Only the dashboard doesn't know this, so the fix is purely a dashboard.html job: /api/resin-profile already returns both selected and the full profiles list, so it's enough to check whether the name is in the list. This does not and should not block printing - the EEPROM values are correct; the only danger is that switching to another profile is a one-way door with no warning. There is no fix yet.

What to do. System → WiFi Info → OK → OK (Reset WiFi), then in the portal enter a deliberately wrong password. Wait for the bar to finish. Then go to System → WiFi Info. At the end repeat with the correct password.

What to expect. After the bar the screen shows two lines: "WiFi: offline mode" and below it a reason with a code — Wrong pass? (204). The same line stays on the WiFi Info screen below "Not connected". The text fits on one line, it doesn't wrap. With the correct password it connects as usual.

Origin: #118 (jvlobo) — the user's printer wasn't connecting, and the firmware only showed "offline mode", so neither they nor we could tell a wrong password from a weak signal. Done in da08f67, closed #122. Hardware taught us: a wrong password returns 204, not 202 — the handshake simply never finishes.

What to do. Open a model that already has a saved preview thumbnail (it shows right away, with no build bar). Wait about 10 s for the real 3D to build in the background. Look at that model's row in the SD list.

What to expect. The row shows a model thumbnail, not the gray TinyMaker icon.

Origin: V's finding 2026-08-30 (skeltool). The icon is drawn in the browser from the layers and kept in localStorage. For a model with a saved thumbnail the dashboard shows it right away, and the real layers arrive later, in the background — and nothing ever went back to make the icon. Measured: a manual ensureRowIcon call made it right away, so the function was fine, the call's timing was at fault. Fixed in 92be692: the icon is made at the end of the background build.

What to do. Open any model's preview and wait for the 3D to build. Go to Settings and run "Prepare 3D for all models". Wait for it to finish and go back.

What to expect. The card shows the same view as before the rebuild. Not chunky cubes, not a zoomed-in and off-center corner. Same after switching theme and maximizing the window. The list icons must refresh during this — including models nobody has previewed.

Origin: V's finding 2026-08-30. The loop turns off the detailed view (it only needs the coarse cache), used to redraw the card while still in coarse mode, and at the end cleared the cache — leaving a chunky drawing over emptiness, with dimensions computed for a different density. Measured: right after the loop the cache is /80x60/0, and the drawing field is 720×420 instead of 240×150. Fixed in 4aad9e0: the card is only redrawn in coarse mode, and the visible view — in the GPU layer — is left untouched.

What to do. On a computer open the SD list and wait about half a minute (icons travel to the card in the background). Then open the dashboard on a phone or in a browser that has never opened this printer before.

What to expect. The list shows model thumbnails, not gray icons. Nothing needs to be clicked and nothing needs to be prepared. In a paginated list, icons are sent for the rows that were shown — the next page's models send their own once it is opened (V's decision: sending all of them at once makes no sense).

Origin: V 2026-08-30 — "there's no sense showing it in the PC browser, and you open it on a phone and don't see it there". Since e06e402 (08-16) the icon lived only in localStorage, up to 24 most recent, and belonged to the browser, not the model. Now a 56×56 PNG (~5 KB) sits next to the model on the card (icon.png), and the list takes it from there. The moment it's generated didn't change: preview or "Prepare 3D". Checked by deleting all 25 browser bookmarks: 10 out of 10 rows in the list had thumbnails from the card (1da71bd).

What to do. On a computer (wide window) slice an STL and upload it to SD. When the SD section expands, count the rows.

What to expect. 5 rows and the list doesn't run off below the left column. In a narrow window (phone) — 10, and that is correct: there are no columns there.

Origin: V's finding 2026-08-30. The row count is measured against the bottom of the left column, but right after a slicer upload SD expands immediately while the preview is still loading — the measurement conditions don't hold, and the initial value 10 was left in place (the phone layout, not a measurement). Fixed in 571ec77: the starting value is taken from the layout (5 on a computer), not always 10. The first attempt (ada342f) targeted the wrong spot — it fixed the inside of the measurement, which wasn't even reachable yet.

Verified: 0.17.0 0b6e5a0 (2026-08-31, Claude browser via Chrome)

What to do. Check in four modes: normal preview from SD; an STL just loaded in the slicer; sliced; right after uploading to SD. Also — with the preview window maximized.

What to expect. The cage button is always first from the left.

Origin: V's finding 2026-08-30. In the slicer gl3dDet, gl3dClip and gl3dRaw are hidden, so the cage used to end up sometimes at the front, sometimes at the back, even though it never moved itself. Fixed in 0b6e5a0: order:-1 — not a DOM reorder, so the slicer's bridge is left untouched.

Self-update via the dashboard/printer -> once the browser reconnects after the reboot, a one-time 'firmware updated' notice is shown; it does NOT repeat on later refreshes.

Origin: 1-35 (0.16.0-beta), sessionStorage tmFwUpd.

Advanced -> Network -> WiFi Off, reboot. System -> Update: temporary WiFi COMES UP, self-update is possible (used to be a deadlock). networkStarted latch no longer blocks (case 423 unlatch).

Origin: 0-35 / GitHub #38 (0.16.2). Verified: 0.16.2 (08-03, on hardware)

What to do. Turn off the router (or its WiFi). Turn on the printer and wait until the screen shows "WiFi: offline mode". Only then turn the router back on and wait about 1 min. Don't touch anything on the printer - no reboot, no System → Update.

What to expect. The WiFi icon turns green AND the dashboard opens over IP; tinymaker.local also works; PrusaSlicer's "Send to printer" connects. Second variant of the same thing: start the printer while the router is still coming back up after a power outage - the result must be the same.

Why. A failed 15 s connection attempt at boot used to return from network_setup() too early, and behind that ALL the HTTP routes and server.begin() were left un-started. A watchdog would bring the radio back - green icon, correct IP - but the printer would stay silent to every request. The only way back was System → Update. Origin: feedback #24 (Simon, 0.16.2) - two printers at the same time, both on the network, both unreachable; a reboot didn't help. Fix 836d6d3.

While printing AND while idle, reboot the router (or briefly turn off WiFi) -> the printer reconnects to the network on its own without re-entering the password; tinymaker.local recovers. Exposure (CURE) is not affected - the watchdog only touches network_loop(), it does not run during UV; auto-reconnect runs in the background. Verified: 0.15.6+dirty (07-18, field test - "recovered")

Origin: feedback #12 (Jack Butler, 0.15.6) - WiFi used to drop completely, and the credentials had to be re-entered (since ~0.15.4). Cause: no runtime auto-reconnect (only at boot). Fix 07-18: setAutoReconnect(true)+persistent(true) + idle reconnect watchdog + mDNS re-announce.

'Power restored' -> Discard (hold the button down all the way). Then System -> WiFi Info: the printer is STILL on the network. A held Discard must NOT act as a factory WiFi reset.

Origin: field bug (V, 07-22) - 'hold BACK while powering on = WiFi erase' was triggered by a still-held Discard (network_setup from loop). Fix 1c38cfc: button-release drain before network_setup.

Regular exposure is stored/edited with 0.1 s precision (Base stays in whole seconds). Old whole-second Regular x10 -> ds (self-healing migration, addr3 mirror for downgrade). A value set to X.X survives reboot and backup/restore; UV time + estimate use /10 (not off by 10x); factory reset -> 14.0.

Origin: 0-3 (0.17, PR #85). Verified: 0.17-dev (08-08, on hardware: #3 real print Sunlu Rapid @ Regular 8.0/Base 18 - clean part + adhesion; migration auto-OK 14->14.0)

Exposure test end screen, WiFi Info, Update screens - text does not overlap itself, does not cross the frame.

Origin: blue text overlap + "(Good)" colliding with the bars, 0.14.3/0.15.4.

Start uploading an animation and cut the network -> the old animation stays intact, the partial file is not installed.

Origin: Brian's 538 KB truncated file - the installer used to accept partial files; fix: TMB header size + magic check before writing.

What to do. Settings -> Update -> "Install selected" with an earlier version (e.g. 0.18.2), then "Install latest". Then "Choose & flash…" with any other file (e.g. a PNG renamed to firmware.bin).

What to expect. Both versions install, the printer reboots on its own, the version on the dashboard changes. A foreign file is rejected with an error (the file header is checked; a manual upload does not check the signature - it is meant for your own builds), the printer keeps running the old version. No "Version check failed - could not reach GitHub".

Origin: Garry (#118) - in some regions GitHub presents a different certificate, and the printer could not update. 0.18.0.

Verified: 0.18.0 on the printer 2026-09-22 - rebooted via the signature path; found and fixed a whitespace bug in the JSON.

What to do. Claude only: a test build with ENABLE_CRASH_TEST 1 (never in a release) -> /api/crashtest -> the printer reboots -> the crash inbox.

What to expect. A new entry: reason "crash (panic)", layer and time empty (nothing was printing), backtrace shows Network.ino, the Build column - "self-built ⚠" (test build) or "vX ✓" (release). On a release build, /api/crashtest -> 404.

Origin: V 2026-09-24 - the 0.18.2 report showed "power-on · layer 100": that was an old event stuck to the new one, and there was no way to tell which build it came from. 0.18.1 (backtrace), 0.18.3 (#243).

Verified: test build `01691ee+dirty` on the printer 2026-09-24 - Claude ("crash (panic)", layer 0, elf = run); `07aeafa` - crashtest 404.

What to do. Turn the printer off and on five times in a row (wait each time until the dashboard appears on the network).

What to expect. Each time the printer connects on the first try and does not reboot again; no new entries in the crash inbox.

Origin: 0.18.1 crash reports - WiFiManager sometimes dereferenced a null pointer when closing the settings portal. Fixed in 0.18.2.

What to do. Turn on notifications and press "Send test" - the message should arrive on the phone. Then run a dry run and wait for an automatic message (start or finish) - only after that does a line appear in Settings below the channel switches. Then break the settings (wrong Chat ID, or turn off the router), repeat the dry run and watch the same line.

What to expect. In the first case, "Last automatic message: delivered just now.". In the second - a red "NOT delivered" with a reason. As long as there has been no automatic message yet (e.g. the printer was just rebooted), the line is not there at all - even if "Send test" just worked perfectly.

Important. "Send test" does NOT change this line, and that is intentional: the test takes its own path, so a green test message can sit above a red line - and exactly that mismatch ("the test works, but not while printing") was the symptom of #40.

Why. The send result was computed and then discarded, so a memory bug (#40) silently killed messages during printing for weeks, while "Send test" kept working fine. Origin: issue 88, 0.17.

Verified: 0.17.0 (2026-09-02) - Claude + V, build Sep 1 21:42:17. Both sides. "Delivered": after a real automatic message the line showed "Last automatic message: delivered 5 min ago." "NOT delivered": after temporarily setting the chat ID to an invalid value and running `Test2min`, after it finished - "Last automatic message: NOT delivered just now - Telegram returned HTTP 400." (`notifyLastOk false`). The chat ID was restored.

Cancel a print during the final lift -> Telegram/WhatsApp receives "canceled", NOT "finished".

Origin: canceling during the final lift used to land without a notification / as finished - caught in the 0.15.x review.

Dry run, full vat, maximum descent speed. 0) After a real print, at park press +0.1 mm until it rests against the ceiling and count: ~23 = no drift (park 68.0, ceiling 70.3); ~0-5 = the build plate is higher after the job than the counter thinks. 1) Cycles flash -> boot -> start (homing from park to full vat) - 5+ rounds. 2) When the error triggers: press OK and touch NOTHING, then read the /api/status field endstop: false = the plate did not reach the sensor (mechanical - a gap / sticking to the FEP), true = it reached it, but the reading lied while moving (electrical/noise). A retry must start "not having moved".

Ruled out by measurement (do not repeat): bright light does NOT fool the optical sensor (stayed true for ~2.5 min); the travel-budget version was rejected - the physical travel 70.3 mm < 73.0 mm of the budget, so a too-high-position scenario is impossible; no drift.

Origin: 2x "Homing error, print canceled" on 08-09, both right after a flash. On the evening of 08-11, 5 clean cycles - the error was NOT reproduced, moved to monitoring. Verified: 0.17-dev (08-11, on hardware: 5 clean cycles, 0 drift); the cause of the error REMAINS unfound - if it recurs, run step 2)

What to do. Start a print and do not interfere. Watch the dashboard through the whole descent.

What to expect. The status shows Homing with no seconds, and there is no message on the screen.

Why. Homing is part of printing, not a separate wait; nobody measures the distance to the end stop, so there can be no number there.

What to do. Start a print and watch the phone while the plate descends.

What to expect. In the black block "Loading live 3D…", in the header "Printing 0% · name" - both match; once exposure starts it turns into the 3D view on its own.

Why. The message was drawn only once; as soon as anything redrew the canvas it no longer reappeared, and through the whole homing it stayed on "Pick a model and press Preview". Verified: 0.17-dev 92236f7 (08-14, on hardware)

Cancel a print during the final homing (position below 0) -> the plate returns to 0, HTTP stays alive (the page responds), no freeze.

Origin: stop-during-homing finding -> fff62d3, 0.15.4.

What to do. Start a print. While the status is "Homing", try to press Pause.

What to expect. The button is inactive (grayed out). The printer does not accept a pause at this point.

Why. So there is no command that silently does nothing.

Advanced->Resin->"Pause lift": cycles through 20/25/30/35/40; the dashboard input is the same. During a print, Pause -> the plate rises by the configured height (not a fixed 20), Resume -> returns to the exact Z and continues. Ceiling: for any height, a runtime clamp to max_height (does not exceed it). Default 20 = the old behavior.

Origin: #82 (0.17, PR #86); firmware-auditor clean (ceiling safe, default-equivalent, menu without an off-by-one). Verified: 0.17-dev 488194f (08-08, on hardware: menu cycle + lift OK)

Advanced -> Exposure test starts, the bars are visible, the pick screen works (it can be canceled without saving).

Advanced->Resin->Exposure test: 8 bars are sub-second and distinct, shown as "X.X s" (not the raw ds "44-176"). The Intro/result/Advanced value fits in 160px (does not cut off the end). "Pick bar" applies the decisecond Regular value.

Origin: 0-3 display fix (ffa7685) - the bug was found by V on hardware (showed "44-176", cut off "8 bars: 4.4-17."). Verified: 0.17-dev (08-08, on hardware - shows "4.4-17.6s")

Regular = 1-2 s -> the test bars are ALL distinct and selectable (not identical due to whole numbers).

Origin: a user finding in 0.15.0 tests -> 13c9b4b; will finally disappear with 0-3 deciseconds.

Flash onto an erased/fresh board (erase_flash) -> first boot: exposures get the defaults (35/14), UV lights up, Layer_Height is not 2.55.

Origin: Issue #13 (mwalimu, a new machine from the factory) -> EEPROM validation ead35e9, 0.15.x.

Stop in the middle of an exposure -> UV turns off IMMEDIATELY (esp_timer), not after the phase ends.

Origin: UV safety review 0.15.x (uvOffTimer).

Maintenance -> Level Build Plate -> the red screen says "Plate must be EMPTY. Homing goes DOWN." - the three lines fit, do not overlap each other or the Back/Next buttons; Back returns without homing. Verified: 0.15.6-cand. c1d323e (07-20, photo)

Origin: Simon #8 power-outage incident -> safety comes first; the first version broke due to the width of CAPS (wrap overlap, field photo 07-20) -> three short lines.

Advanced -> Resin -> Power resume OFF: cut the power -> NO resume prompt, checkpoint is NOT written (we print from scratch). ON: the prompt appears + it resumes. The switch is saved (NVS + backup); the printer menu and dashboard show the SAME state.

Origin: 0-34 (0.16.2). Verified: 0.16.2 (08-03, on hardware)

Start (Dry run is fine) -> the LCD and dashboard show progress, the countdown phase changes, the page stays live for the whole print.

Verified: 0.17.0 (2026-09-01) - Claude, browser via Chrome, build Sep 1 00:02:57 (a5587d9), dry run on hardware. Ring, 173 layers to the end; phases changed through the whole print, the dashboard stayed live; V confirmed the printer screen and the raised plate.

What to do. Start a print from the SD list and watch the message area and the status line. Same for the Update button.

What to expect. No message in the middle of the screen. The status moves on its own from Processing files -> Homing. Verified: 0.17 (2026-08-22)

Why. The start message repeated what the page already showed, and it used to stay hanging (V finding 2026-08-22).

2026-09-01 (Claude): VERIFIED: statusMsg stayed empty through the whole start, the status moved on its own from Processing files -> Homing (651 ms). Same at the end of stopping - the message cleared itself.

What to do. Pick a small model from the SD list (a few hundred layers). Press Start and confirm. Watch the message in the middle of the screen and count in your head.

What to expect. Either there is no message at all, or it appears and stays for about 3 seconds. It must not "flash and vanish". Text - Processing files. Please wait...

Why. The message is delayed by a second (so it does not flicker), but once shown it must stay long enough to read - until 08-18 it used to vanish the very moment the job finished.

Verified: 0.17.0 (2026-09-01) - Claude, browser via Chrome, build Sep 1 00:02:57 (a5587d9), dry run on hardware. There was NO message at all (statusMsg empty), and the status line allows this: Processing files -> Homing took 651 ms, so the one-second delay suppressed it.

What to do. Pick a large model (~800+ layers). Press Start and look at the printer screen right away, then at the dashboard.

What to expect. Both say the same thing: on the printer screen "Processing files / Please wait...", on the dashboard - "Processing files. Please wait...". The status line on the dashboard is also the same.

Why. Different names for the same wait made you guess whether it was one job or two.

Verified: 0.17.0 (2026-09-02) - Claude + V, build Sep 1 21:42:17. `Bibio`, 897 layers. Started FROM THE DASHBOARD, on the printer screen (V watched) and on the dashboard at the same time - "Processing files"; on the dashboard it stayed for 12 s, then homing. The words match.

What to do. Watch the status line through several layers. Then stop or pause and look again.

What to expect. Seconds are shown only at Curing and Finished. At Lifting, Dropping, Pausing, Resuming, Canceling - only the name.

Why. Lift and drop seconds repeat hundreds of times and nobody decides anything from them; and the wait message already shows the count.

Verified: 0.17.0 (2026-09-01) - Claude, browser via Chrome, build Sep 1 00:02:57 (a5587d9), dry run on hardware. Seconds ONLY at Curing and Finished; Lifting, Dropping, Pausing, Resuming - without them. Note: in one cycle, Curing stayed at 0.36 s with no number before moving to Lifting.

What to do. Open the dashboard on a computer and on a phone. In one place press Pause or Stop. Watch both screens.

What to expect. Both show the same message with the same number. On screen at any moment - only one message, it does not flicker or jump.

Why. Messages about the printer come from the status, so they are also seen by whoever did not press anything.

Verified: 0.17.0 (2026-09-01) - Claude, browser via Chrome, build Sep 1 00:02:57 (a5587d9), dry run on hardware. Three viewers at once: a computer, V's phone (V confirmed it) and a third window where nobody pressed anything - all the same sentence, numbers within 3 s (the browser throttles timers for a window left in the background).

What to do. Open the dashboard on TWO devices (e.g. a computer and a phone). On one of them, start a large model (~800+ layers). Watch the second one - the one where you did not press anything.

What to expect. The second one shows the same thing as the first: "Processing files". No "Printer not answering" - the printer is fine, it is just preparing the files.

Origin: a Claude finding 2026-09-02, while doing T-57. After starting `Bibio` (897 layers) from a different window than the one being watched, that window showed, for 8-12 s, "Printer not answering - an upload, share or other background job is prepared". Cause: while preparing a large model the printer does not respond for a few seconds, and a window that did not send the start itself cannot explain that silence. This contradicts T-75 (both devices should show the same thing).
Why this is NOT fixed right away (V's question 09-02: "will we break something by fixing it?"): that sentence exists to report a REAL unreachability - and there were four of those that same evening. Making it slower or quieter would mean we stop seeing real dropouts. A fix must be narrow: silence it ONLY when the last known state was "preparing files" and ONLY for a few seconds; a longer silence must still shout. Left as is until it is clear why the printer drops off the network. Related: T-75, T-57.

CLOSED by V's decision 2026-09-12 ("that 119 is closed, enough"): not fixing it - the message stays as it is. The reason is the same one written down from the start: silencing it would mean we stop seeing real dropouts from the network, and those are worth more than a few seconds of an inaccurate sentence. The line stays in the register as a description of behavior, not as a pending fix.

What to do. Start a short print (dry run works) and let it finish. After it finishes, do not reload the page. Try pressing any button.

What to expect. The buttons work right away, there is no message on the screen. While the plate rises, the status shows Finished · Ns with a decreasing number.

Why. Until 08-18 there was a bug here: the dashboard used to stay locked until the page was reloaded, and "Processing files" hung on the screen.

Verified: 0.17.0 (2026-09-01) - Claude, browser via Chrome, build Sep 1 00:02:57 (a5587d9), dry run on hardware. Curing 1s -> Lifting -> Finished 22s->0s over 24 s -> Idle on its own, without a reload. Settings opened within 16 ms, no message on screen.

Unpacking / web OTA / upload / boot-anim download -> the bar only GROWS, the text does not flicker, no orange streaks on the LCD.

Origin: unpacking flicker + SPI streaks findings -> 6d7c874/832e147, 0.15.5.

Reload the page while printing -> the active print is visible (progress, countdown), not an idle card; the page loads in a reasonable time.

Origin: feedback #5 (iPhone) -> mid-print HTTP service 0.15.1-0.15.3.

Verified: 0.17.0 (2026-09-01) - Claude, browser via Chrome, build Sep 1 00:02:57 (a5587d9), dry run on hardware. Reload at 10/173: the page loaded in 162 ms and immediately showed the active print (Layer 10/173, 46m left, controls visible).

Open Settings -> Boot animations in the middle of a print -> a lock message (not an endless "Loading animations..."); once the print finishes, the list loads BY ITSELF. Verified: 0.15.6-cand. c1d323e (07-20)

Origin: a user finding 07-17 -> fix 0.15.6 candidate (not yet built).

Verified: 0.17.0 (2026-09-01) - Claude, browser via Chrome, build Sep 1 00:02:57 (a5587d9), dry run on hardware. Both sides: while printing - the lock sentence, once finished the list loaded BY ITSELF (4 animations), without a reload.

On the dashboard, Pause (the plate rises), then Resume (the plate returns) -> the phase countdown keeps updating through the whole move, the dashboard does not freeze during those seconds.

Origin: a V field finding (07-22) - the 160ms lift/travel window used to miss the 2s poll -> the dashboard froze. Fix: phase countdown + HTTP every 200ms during the move cycle (status 'phased' covers state 5/7).

Verified: 0.17.0 (2026-09-01) - Claude, browser via Chrome, build Sep 1 00:02:57 (a5587d9), dry run on hardware. Pause: the number decreased about every 1 s; resume: the largest gap between updates was 1.9 s over a 26 s move; the page cycle was 827 frames out of 820 expected - no freeze.

After a power loss, instead of the printer buttons, open the dashboard -> a 'Power was restored' card with Resume/Lift/Discard; Resume there continues the print live, no need to touch the printer.

Origin: 0-33 (exp-5), 0.16.0-beta. /api/resume/accept|lift|discard.

Verified: 0.17.0 (2026-09-01) - Claude, build Sep 1 21:42:17, dry run, Test4min, V pulled the plug from the wall. The card on the dashboard: "Power was restored - a print was interrupted. Test4min - 1 of 9 layers were finished" with three buttons (Resume print / Lift plate only / Discard). "Resume print" was pressed ON THE DASHBOARD, the printer was not touched - a confirmation dialog warned about the vat and the plate, the print continued and finished 9/9.

While printing (dry run works), open a FRESH browser / incognito WITHOUT the preview -> it shows "Print progress 3D" with a growing voxel render (not a static photo + "Printing NN%"). It grows live as the print rises. Second part (M1 guard): after a power-loss RESUME, open a fresh window -> the live 3D still grows (from the top), the sampler does not stall starting from resumeLayer. Watch the heap (freeHeap stays healthy with ~13.8 KB liveBuf).

Origin: P-live (0.17 Sprint B, #P-live) - live 3D in every window via /api/live/slices (64x48 1-bit silhouettes, RAM stack). Resume-stall (M1/M2) = a firmware-auditor finding, fixed before the merge (PR #79). Verified: 0.17-dev cc829eb (08-05, on hardware - incognito grew, liveN=36, heap min 77KB)

2026-09-01 (Claude): First part VERIFIED: a fresh window that never opened the preview grows live - between layer 21 and 24, 377 ghost points turned solid, the bar 12% -> 14%. Second part (resume after power loss) NOT DONE - waiting for block 2E.

Verified: 0.17.0 (2026-09-01) - Claude, build Sep 1 21:42:17, dry run, Test4min, V pulled the plug from the wall. SECOND part (the first was verified back on 08-31): after a power-loss resume, a fresh window that never opened that model's preview BUILT the live view BY ITSELF - the canvas had 1 color (empty box), after the resume 35 colors and 8969 points, the header "Printing 100% · Test4min". The sampler did not stall starting from resumeLayer, the heap stayed healthy (~166 KB).

What to do. Turn on Dry run (Dashboard, the button next to "VAT refilled"). Go to Settings, change any setting (or change nothing at all) and press Save config. Go back to Dashboard.

What to expect. Dry run stays on: the button says "Dry run: on", a banner at the top says "Dry run mode enabled". The next print must be dry.

Origin: a Claude finding 2026-09-01. Measured twice in a row: after "Save config" dryRun drops to false, even though nobody touched the switch. Cause Network.ino:1753 uvLedEnabled = !formCheck("dry_run", !uvLedEnabled): the dashboard sends the FULL form, and the dry run switch does not live in that form (it is a separate button), so formCheck, finding no field, returns false = "the user turned it off". The danger is real: someone sets up a dry test, changes a WiFi setting - and the next print already runs with the UV lamp lit.

FIXED 2026-09-01 (commit 3e71888, on hardware, build Sep 1 21:42:17). Cause: `formCheck`, when a field was missing from the full form, used to return "off", and the dashboard toggles dry run via a separate endpoint and does not put it in the form. Now the value changes ONLY if the field was actually sent. Verified: the exact `POST /api/config` request was captured, after it `dryRun` stayed `true`; the other switches did not move.

What to do. Write down the "Resin left (est.)" number. Turn on dry run, start a short model and let it finish. Check the number again.

What to expect. The number has not changed: nothing cures in a dry cycle, so there is nothing to deduct.

Origin: a Claude finding 2026-09-01. A full dry 9-layer cycle deducted 0.5 ml (9.8 -> 9.3), i.e. the whole model estimate. Over a day of tests V's counter dropped 14.5 -> 8.9 ml, even though the vat was empty the whole time. Cause TinyMaker.ino:2688: vatRemainingMl -= (resinUsedMl - resinSampledMl) runs for every layer with no dry-run check (the UV counter has that guard). Not just cosmetic: at 2 ml the "low resin" stop kicks in, so someone doing a lot of testing would get a false warning and a stopped print.

FIXED 2026-09-01 (commit 3e71888, on hardware, build Sep 1 21:42:17). The deduction is now wrapped in `if (uvLedEnabled)`. Verified both ways: a full dry 9-layer cycle - the resin stayed at exactly 7.5 ml (before the fix the same cycle used to deduct 0.5 ml); a REAL 9-layer print - resin 7.5 -> 7.1 ml, UV +137 s, i.e. the accounting was untouched.

What to do. Turn on Dry run and start a small model. On the computer, look at the right column, hover the mouse over "STL slicer", "SD manager" and the preview header "Printing …". Open the dashboard on the phone. Press Pause → OK, wait for "Paused", Resume → OK. Let the print finish.

What to expect. While printing, both cards - just gray headers with ▶, no content, and on the phone too (no "Locked while printing" and no Upload). Hovering the mouse does not turn anything orange, the cursor is plain; "Printing …" is not a link. During the pause the cards stay collapsed. After the print, SD opens with a list, arrow ▼, hovering the mouse turns the header orange again.

Origin: V 2026-09-20/21 - while printing, the SD list was still locked, and the slicer card was dragged along with SD; on the phone SD would not collapse, the locked header was orange. PR #207, released in 0.17.9.

Verified: `ba00a47` on the printer 2026-09-22 - Claude (dry run `test-mazas`, Chrome + 375 px, pause, finish).

Stop from the dashboard mid-print → "Canceling · Ns" countdown → the platform rises → Idle; UV off.

verified: 0.17.0 (2026-09-01) - Claude, browser via Chrome, build Sep 1 00:02:57 (a5587d9), dry run on hardware. Countdown, the plate rises, then Idle. The UV counter did not move (7248 s) - but this is a dry run, so the UV side is not yet verified with resin.

What to do. Wait until the layer exposure starts (status "Curing"). Press Stop and confirm. Watch the message from the moment you press it; if you have a second device - keep the dashboard open on it too.

What to expect. Four things:

1) The first sentence "Stopping the current operation" appears within a second and does not hang for more than ~6 s.
2) During that time the dashboard does not show "Printer not answering", and the second device shows the same.
3) The sentence rewrites itself in place to "Stopping · lifting the platform" with seconds - no second message appears and the first one does not jump to another spot.
4) The platform rises, at the end Idle, the controls unlock.

Why exactly like this. The first stage must exist: when exposure is interrupted, the layer has just cured and is stuck to the vat film, so the printer still performs a gentle peel-off lift (~4.6 s) and only then raises the platform to the top. This is real work, not a hang.

The first version of this row did not know that and required that the first stage not exist at all ("exposure stops at that same instant, so there is nothing to wait for"). Because of that it failed on 2026-09-01 even when everything worked correctly. Rewritten with V's permission.

What this row was actually guarding against: until 2026-09-01 that stage took ~9 s, and during it the printer did not even respond to status requests (the cancellation notification to the phone opened an encrypted connection and blocked the whole loop()), so the second device would show "Printer not answering". Fixed in commit 3e71888: the notification was moved after the platform lift, and the stage got a real estimate. If anyone puts blocking work back into the cancellation path, this row fails. verified: 0.17.0 (2026-09-01) - Claude, build Sep 1 21:42:17: first stage 6.7 s, gap with no response 4.6 s (was 7.8 s), the sentence rewrote itself in place. Related: T-116, T-117.

What to do. Watch the status and catch the moment the platform is moving. Press Stop. Watch the same message for at least 10 seconds - don't look away.

What to expect. At first Stopping the current operation (a number only if more than 5 s remain), then the same message rewrites itself to Stopping · lifting the platform with seconds. The message does not jump to another spot and does not reappear from scratch.

Why. This is one wait with two stages; two separate messages would read as two jobs.

verified: 0.17.0 (2026-09-01) - Claude, browser via Chrome, build Sep 1 00:02:57 (a5587d9), dry run on hardware. When stopping during movement, the message rewrote itself in the same spot to 'Stopping - lifting the platform'; it did not jump and no second one appeared.

What to do. Start a print. While the status shows Homing, press Stop. Watch the message from the moment you press it.

What to expect. One sentence: Stopping · returning the platform with seconds. The platform actually returns to the top in roughly the promised time.

Why. When homing is interrupted there is no final lift - the platform just returns back, so there should be only one sentence.

verified: 0.17.0 (2026-09-01) - Claude, browser via Chrome, build Sep 1 00:02:57 (a5587d9), dry run on hardware. One sentence 'Stopping - returning the platform' 19->0 s, total stop 23 s (promised 19). No first stage.

What to do. Start a print, press Pause and wait until the status becomes "Paused". Then press Stop.

What to expect. Immediately Stopping · lifting the platform with seconds - no first stage, because nothing is moving. At the end status Idle, the buttons unlock.

Why. This is a separate spot in the firmware code (stopping in the pause loop), so it is tested separately.

verified: 0.17.0 (2026-09-01) - Claude, browser via Chrome, build Sep 1 00:02:57 (a5587d9), dry run on hardware. From pause - immediately 'Stopping - lifting the platform ~22 s', no lead-in; at the end Idle, controls unlocked.

What to do. Stop the print. When you see the number, press Stop again (if the button is still active). Watch the number.

What to expect. The number keeps decreasing. It must not jump back to the initial value.

Why. The printer does not recalculate the estimate the second time; in its response it returns the remainder, not the full duration.

verified: 0.17.0 (2026-09-01) - Claude, browser via Chrome, build Sep 1 00:02:57 (a5587d9), dry run on hardware. A second press is not possible: stopButton is disabled while stopping. There is no way to rewind the counter.

What to do. While printing, press Stop and watch the message. If you have a second device - keep the dashboard open on it too.

What to expect. From the press to "Stopping - lifting the platform" with seconds, less than ~2 s passes, and during that time the dashboard does not show "Printer not answering".

Origin: Claude finding 2026-09-01, seven rounds. After Stop the printer sits ~8-9 s in the stage stopTail, which estimates itself as zero, and during that time it does not respond to status requests (a gap with no response captured by the browser itself - 7.8 s). The dashboard is not at fault: it rewrites the sentence 30 ms after the moment it receives the new phase. Part of the blame is a blocking Telegram notification (TinyMaker.ino:2996 -> tgNotifyCanceled() -> WiFiClientSecure): with notifications turned off the stage shortened to 7.4 s, and the gap with no response - to 2.8-4.3 s (two rounds). The source of the remaining ~7 s is STILL UNIDENTIFIED. Related: T-60.

FIXED 2026-09-01 (commit 3e71888, on hardware build Sep 1 21:42:17). Two causes, both removed. (1) The cancellation notification to the phone used to block `loop()` for several seconds - moved after the platform lift, the same spot as "Finished". (2) The first stage used to promise zero, because it was measured from the motor, and the motor stands still when exposure is interrupted - now it takes the time of the previous lift (or half the plate cycle for the first print after power-on), and ONLY when stopping during exposure. Measured after flashing: gap with no response 7.8 s -> 4.6 s, the printer responds the whole time, the stop response returns 4531 ms instead of 0, the cancellation notification went out after 32.3 s (platform already raised, `notifyLastOk true`). The number is still not on screen: 4.6 s < 5 s threshold (`WAIT_BAR_MIN_MS`), V's decision from 08-18 - V confirmed on 09-01 to leave it.

What to do. While printing, press Pause, and after a second, before that same layer finishes, change your mind and press Stop. Watch the message and the platform.

What to expect. Everything the same as stopping WITHOUT a pause: the pause sentence with a number rewrites itself in place to "Stopping the current operation", after a few seconds - to "Stopping · lifting the platform" with seconds, the platform rises, at the end Idle and the controls unlock. No second message appears and the sentence does not jump to another spot.

Origin: `firmware-auditor` finding 2026-09-01 while fixing T-116. It warned that when stopping AFTER a pause request the estimate is not adjusted, because the internal state "pausing" and "rising for inspection" is the same (5), so you cannot tell whether the peel-off lift is still to come. Measured that same evening: the warning was confirmed only partly. The Stop command's response does return etaMs: 0, BUT the printer's status does not immediately follow the real number (stopTail 4615 ms) - it re-announces the UVLED.ino line, where the phase is passed directly, because it is known in advance there. So the dashboard behaves identically: first stage 5.9 s (without a pause - 6.7 s), then lifting with seconds. The first version of this row expected a number in the first stage - it NEVER happens, because 4.6 s < 5 s threshold (WAIT_BAR_MIN_MS, V's decision from 08-18). The row was rewritten to match reality (with V's permission, 09-01), so it would guard against a real regression, not an imagined one. verified: 0.17.0 (2026-09-01) - Claude, build Sep 1 21:42:17, dry run, Test4min. Related: T-116, T-60.

What to do. Start a print (dry run is enough). At layer 2 on the dashboard press Pause → OK. When the platform starts rising (printer's status bar shows "Pausing..."), on the dashboard press Stop → OK.

What to expect. The dashboard shows "Canceling" and stays that way until the end, and Resume is gray. When the platform stops at the top, "Paused" must NOT appear. The printer screen also shows "Canceling...", then Idle.

Origin: V's question 2026-09-11 ("why does it show Paused after Stop?"). The pause lift responds to the dashboard, so Stop is accepted during the movement, but once the platform rose the code still parked the pause: for ~24 s the dashboard showed "Paused" with Resume active, the screen showed pause signs, and during the resin pause a Telegram message would still go out. Fixed in 0.17.1 (3f2c79b): it is parked only if the pause is still pending.

Verified: 0.17.1 (2026-09-12) - Claude with a dashboard recording (0.6 s → "Canceling", 24 s without "Paused") and V's own eyes on the screen.

What to do. Same print: Pause → the platform rises → on the dashboard press Resume → OK. When the platform descends, on the dashboard press Stop → OK. Watch the buttons on the right side of the printer screen.

What to expect. The buttons stay gray until the end. The red square and yellow dashes must not come back, because the print is being stopped.

Origin: firmware-auditor finding 2026-09-11, while fixing T-120. Once the platform descended, the code used to redraw the live buttons over the gray ones that Stop had already drawn. Fixed in 0.17.1 (648563b). The dashboard showed it correctly there, so the bug was only on the screen.

Verified: 0.17.1 (2026-09-12) - V's own eyes: "Gray".

What to do. Wait for "Curing" and press Pause. Note down the promised number. Time it until the status becomes Paused.

What to expect. Pausing · finishing the layer with seconds (roughly 30-40 s at 0.05 mm). Then the same message rewrites itself to Pausing · lifting the platform (~24 s). The actual time differs from the promised one by no more than ~15 %.

Why. Here the estimate is composite: remaining exposure + the whole lift + a 20 mm rise for inspection.

verified: 0.17.0 (2026-09-01) - Claude, build a5587d9, dry run on hardware (TestasLong). Pause 264 ms after the start of exposure of a normal layer (11/28): promised 36.3 s, actual 38.3 s (+5.5%, threshold +-15%); falls within the expected 30-40 s range.

What to do. Catch the moment the platform is rising, and press Pause. Note down the number and the time until "Paused".

What to expect. The number is smaller than when pausing during exposure (roughly 25-30 s) - because there is no more exposure to wait out.

Why. A different code branch: only the remaining movement plus the rise is counted.

verified: 0.17.0 (2026-09-01) - Claude, build a5587d9, dry run on hardware (TestasLong). Pause 466 ms after the start of the lift (4/28): promised 28.1 s, actual 29.5 s (+5%). The number is smaller than in the exposure case (33-44 s), the layer number did not change - as it should be when the lift is caught.

What to do. Catch the moment the platform is descending, and press Pause. Note down the number. Watch how many more layers pass before it stops.

What to expect. The number is the largest (~45-70 s), because before the pause a whole other layer still passes. The layer number manages to increase by one. The reliable sign is not the status text but the layer number: the dashboard's status lags by up to 2 s, and the descent takes ~4 s, so "Dropping" on screen is often already over. If you really interrupted the descent, the printer will stop at a layer number one higher than the one seen when you pressed, and the number will be ~45 s (not ~36 s, as when interrupting exposure). If the number is the same - you hit exposure, and that is a separate test (C1).

Why. The pause point in the code is after the next layer's exposure and lift - if the number did not account for that, it would be off by half a minute.

verified: 0.17.0 (2026-09-01) - Claude, build a5587d9, dry run on hardware (TestasLong). Pause during descent: promised 44.4 s (the largest of all cases), the layer number managed to rise 2 -> 3 - the sign this row calls reliable. Actual ~35 s, i.e. faster than promised (the safe side).

What to do. Start a print and wait for the first layer's "Curing". Press Pause and note down the number.

What to expect. The number is noticeably larger than on a normal layer (the base exposure is longer), and the actual time matches it.

Why. The same branch as C1, but here the error would be most visible - the base exposure is long.

verified: 0.17.0 (2026-09-01) - Claude, build a5587d9, dry run on hardware (TestasLong). Pause on the base layer: promised 33 s, actual 35.0 s (+6%). The message rewrote itself 'finishing the layer ~33 s' -> after 9.4 s 'lifting the platform ~24 s'.

What to do. Power on the printer (or reboot it) and start a print right away. On the first layer press Pause.

What to expect. The number can be too small (the printer does not yet have a measurement from the previous layer) - that is normal. Important: the number does not go negative and the message does not flicker; once the number runs out, the message stays without it.

Why. A known, deliberately accepted limit: better to promise less than to show a negative number.

verified: 0.17.0 (2026-09-01) - Claude, build a5587d9, dry run on hardware. Pause on the first layer right after switching power on (uptime 74 s): promised 41.6 s, actual 48.1 s - promise TOO SMALL, exactly as the row expects for a freshly powered-on printer. The number never dropped below zero (min 0), the message appeared on screen EXACTLY ONCE (no flicker), and once the number ran out the message stayed without it for another 2 s until the pause.

What to do. Press pause on the printer itself (not on the dashboard). Look at the dashboard.

What to expect. The dashboard shows the same message with a number as when pressing on the dashboard.

Why. Until 08-18 a pause from the printer's own buttons stayed silent on the dashboard - only the web command used to announce the number.

verified: 0.17.0 (2026-09-01) - Claude, build a5587d9, dry run on hardware. Pause pressed on the printer ITSELF: it announced the estimate the same way as the web command - waitStage=pauseWork, duration 30.8 s, layer 12/28. The dashboard showed the same message with a number ('Pausing - lifting the platform ~4 s -> 0 s').

What to do. Press Resume. Watch the message and the status line.

What to expect. Resuming · lowering the platform with seconds (~24 s). The status line has no seconds - the number is only in the message. Once printing starts the message disappears.

Why. The same number in two places looked like two different clocks.

verified: 0.17.0 (2026-09-01) - Claude, build a5587d9, dry run on hardware (TestasLong). Resume: 'Resuming - lowering the platform ~23 s' with seconds, the status line has NO seconds, once printing started the message disappeared on its own. Actual 26.1 s.

What to do. While printing, pull the plug at the wall (not the printer's buttons) three times, each at a different moment: E - while curing a layer, M - while the platform is moving, P - during a pause (platform raised for inspection). Each time power on and choose Resume.

What to expect. After each power-on, on screen (and on the dashboard) - "Power restored" with the model and layer. Resume continues from the same layer: neither skipped nor doubled. The platform descends smoothly and does not press against the film. Once the print finishes, the checkpoint clears itself (resumePending: None), heap is healthy.

This row tests the MECHANICAL and bookkeeping side - it can be done dry. The seam at the cut point has been split into a separate T-118 (block 3A), because it needs resin: in a dry run the seam simply does not exist. Split by V's decision on 2026-09-01, so this row would not stay open just for one thing that needs another block.

Origin: exp-5 power-loss checkpoint engine (Tanner PR #11), 0.16.0-beta. Checkpoint /tinymaker-resume.txt on the SD card. verified: 0.17.0 (2026-09-01) - Claude + V, dry run, Test4min, plug pulled at the wall. All three phases clean: each time the printer remembered the layer, continued from the same one and finished 9/9; heap ~166 KB; the checkpoint cleared once the print finished. During phase M, V watched the platform - it descended cleanly, did not press against the film. Measured separately: in the first round, 29 s passed from the start of exposure to power loss, and exposure takes 18 s - the cut landed in the exposure of the SECOND layer, so "finished=1" was correct. Before claiming "it skipped a layer", you must count which phase the cut actually hit. Related: T-118, T-25, T-37, T-35.

Dry-run print. Cut power at the wall during LIFT and during DROP (descent) -> power on -> Resume: the platform peels + lands at the target or ABOVE, never lower (into the FEP). Switch Advanced->Resin "Resume mode" to Precise -> repeat the drop cut -> more precise recovery; the toggle survives a reboot (NVS). Heap healthy.

Origin: 1-38/1-38b granular mid-motion checkpoints (PR #80). the live= field (pos=drift-free base, live=real position for relabeling); lift=actual, drop=down-biased. firmware-auditor HIGH finding (mid-drop cancel stales live) fixed before merge. Verified: 0.17-dev 958ca5f (08-06, on hardware: lift L6, drop L11 with no drop, Precise drop L14 more precise, toggle survived)

verified: 0.17.0 (2026-09-01) - Claude + V, dry run, Test4min, plug pulled at the wall. Precise was checked earlier the same evening (see T-22 phase M), Balanced - now: cut while the platform was rising BETWEEN layers, homing after resume, then layer 2 and a normal cycle; 12 s passed from resume to the next exposure (13 s with Precise), the print finished 9/9, heap healthy, checkpoint cleared. The switch survives a reboot (NVS): after the power loss resumePrecise was still false, and after switching it back manually - true.
What was DELIBERATELY not done and why: a separate dry cut during the DESCENT. It would test the same mechanism we just saw during the lift, and the only remaining question - whether the platform descended to the RIGHT height - cannot be answered dry in principle: there is neither resin nor a seam there. V on 09-01: "this also needs to be watched during a real test with resin... but it looks like it descended ok otherwise". The height side goes into T-118 (block 3A).

On the 'Power restored' screen choose 'Lift plate only' -> the platform rises (you can inspect/remove the part), the print is discarded, without resume.

Origin: 0-2 (exp-5), 0.16.0-beta.

verified: 0.17.0 (2026-09-01) - Claude + V, dry run, Test4min, plug pulled at the wall. The cut hit the exposure of the first layer, so the printer offered to resume from 0 of 9 (the number means FULLY cured layers - here there were none). On the dashboard "Lift plate only" was pressed, the confirmation dialog warned that the print would be discarded. V confirmed that the platform rose. Afterwards resumePending became None - the print was really discarded, not postponed. During the lift, HTTP briefly stalls (not served during movement) - normal.

Power-loss prompt -> UP (Lift plate): the platform rises, then power-cycle -> NO re-prompt (checkpoint cleared BEFORE the lift). A brownout during the lift no longer leaves a false resume with a platform that has already moved.

Origin: UP clear-first fix (0.16.2, found 08-03 in V's tests). Verified: 0.16.2 (08-03, on hardware)

verified: 0.17.0 (2026-09-01) - Claude + V, dry run, Test4min, plug pulled at the wall. Right after "Lift plate only" V switched the power: the printer came up clean, resumePending: None - no repeated offer to resume. That is the whole point: the record is cleared BEFORE the lift, so if power was lost during the lift itself, the printer would no longer offer to resume a print whose platform has already been moved.

Cut power while printing -> power on -> if a notification channel is enabled (Telegram/WA/Discord), a message arrives on the phone: "Power restored - print interrupted at layer X/Y (model)" (one message per boot). The resume screen prompt + dashboard resumePending as before.

Origin: PR-notify (V 08-05, PR #81) - the 4th notify (after finished/low-resin/canceled); on boot after WiFi, next to crashPingMaybe. Verified: 0.17-dev 958ca5f (08-06, on hardware: Telegram message arrived "layer 6/154 Tooth")

verified: 0.17.0 (2026-09-01) - Claude, build Sep 1 21:42:17, dry run, Test4min, V pulled the plug at the wall. The notification went out 12 s after power-on, `notifyLastOk true`; V confirmed that the message arrived on the phone.

What to do. Start a print, press Pause, and when the platform is rising, pull the power. Wait ~5 s, plug it back in, do not touch the printer's buttons.

What to expect. The printer powers on normally: the screen has NO "Power restored" with Discard/Resume, and the dashboard has no "Power was restored" bar. Status Idle.

Origin: V's principle from 2026-09-12 ("if an operation could damage the printer or the part - we delete the record"). During the pause lift, the descent after Resume and the final lift, the height written in the record does not match the real one, so resuming could press the part into the screen or drive the platform to the top. Since 0.17.1 (e421b9b) the record is deleted before those moves and written again once the platform stops. While stationary in a pause and while printing layers, resume works as before (T-22, T-36).

Verified: 0.17.1 (2026-09-12) - V pulled the power, `resumePending` empty, `bootReason=power-on`.

What to do. Pull the power while printing a layer (not during a long move), power on, on the dashboard press Resume print → OK and let the print finish. Watch the printer screen at the end.

What to expect. The platform does not rise to the top, and the screen shows "Raise the plate". The status bar briefly flashes "Raising...", but the platform stays in place (the height does not change). You raise the platform yourself with a manual lift. A normal print, which returned to zero before starting, lifts as usual at the end.

Origin: incident 2026-09-12 - after a resumed print, Stop's final lift slammed into the top and the motor buzzed. Cause: the recovery does not know the height exactly and deliberately keeps it lower, but the lift went up to an absolute 68 mm, when there is physically only 3 mm above that (measured). Since 0.17.1 (2d28f6e) a resumed print does not lift at the end.

Verified: 0.17.1 (2026-09-12) - `zMm` 4.31 instead of ~24 mm, duration 4 s instead of ~24 s; V saw "Raise the plate".

What to do. After a power loss while printing (like T-123), on the start-up prompt choose UP = "Lift plate only" (or the same button on the dashboard). While the platform is rising, press the printer's BACK.

What to expect. The status bar shows "Raising plate." and "Watch it - BACK stops"; both lines fit on screen. After pressing BACK the movement stops and "Raise the plate" appears. Without touching BACK, the platform rises no higher than 62 mm, not 68.

Origin: audit 2026-09-12 after the T-123 incident. That lift also went up to 68 mm based on the guessed height, so with a tall print (platform above ~48 mm) it could overshoot by more than those 3 mm. Since 0.17.1 (9fa6b03, e64da93): the ceiling is 6 mm lower, both movements are stopped by BACK, the screen says you need to watch it. Short test prints do not reach the 62 mm ceiling, so that part remains unverified by eye.

Verified: 0.17.1 (2026-09-12) - V pressed BACK, the platform stopped at 3.27 mm (only the peel-off), "Raise the plate" appeared.

What to do. Watch the first few percent in both views (the upright one and "as printed").

What to expect. The first layer is visible as a thin film, thickening as progress continues.

Why. 36 cross-sections are shown across the whole height, so one shown cross-section ≈ model height/35 (for a 15 mm model - 0.44 mm ≈ 4 real layers). Now the front cross-section is drawn at a proportional thickness. Verified: 0.17-dev 9f400e2 (08-14, on the test bench at 1 %, 2 %, 12 %)

What to do. Open the model preview, start a print (or dry run) and watch the same window; separately - open the dashboard on the phone in the middle of the print.

What to expect. The unprinted part is visible for the whole print, as dots. On the phone too: at the start of the print the printer fills its own silhouette buffer with model cross-sections from the SD card, so even a fresh device sees the ghost, not just the printed part.

Why. Previously, once the print started, the dashboard used to switch to the printer's live stream, which by definition only contains layers already printed - there was nothing left to draw the ghost from. Verified: 0.17-dev 9f400e2 / cf11c1d (08-14, on hardware)

While printing (not idle!), trigger a notify (e.g. low-resin warn) and check that the message REACHES the phone. Hidden failure mode: the preview RAM snapshot (~70 KB) fragments the heap (maxAlloc 110->48 KB), TLS "connection refused", the message disappears SILENTLY - idle "Send test" works, so the config looks fine. After the fix, telegramNotify() first frees the snapshot.

Origin: 08-08 - V noticed that the #40 warn did not arrive; a diagnostic build showed that even the OLD pause-notify never happened mid-print. Verified: 0.17-dev 5644714 (08-08, on hardware: both messages mid-print)

What to do. Turn off Dry run (no UV) and start a print. After a few layers press Stop. Note how many seconds it promises, and how long the platform actually takes to rise.

What to expect. The lift takes 60-80 s (not ~24 s like dry run), and the promised number differs from the real one by no more than a few seconds.

Why. Dry run only lifts to the inspection height, a real print - all the way to the top; these are different numbers and they are calculated separately.

Dry print with the vat near the warn zone: at the "Warn (ml)" threshold one "Low resin soon" message arrives in the format "~X.X ml left (layer x/y[, ~Z min to stop])" - minutes ONLY once the pace is known (from layer 5; before that it showed a false "~0 min") - and printing CONTINUES; at the "Stop (ml)" threshold (if the checkbox is ON) - pause + "printer paused" message. A refill re-arms both latches. Warn does not depend on the stop checkbox.

Origin: #40 (FB pain) - the time trigger never fired on a small vat (found by V); redone as a two-level ml system (V's design). Verified: 0.17-dev b5020f9 (08-08, on hardware: warn+continue+stop+cancel messages on the phone, layer x/y format)

What to do. Print a REAL print with resin. When the platform is moving (rising or descending), pull the plug at the wall. Power on, on the dashboard (or the printer screen) choose Resume. Let the print finish and inspect the spot where it was interrupted.

What to expect. The part is not peeled off the platform, and at the interruption spot there is no dent, no skipped layer, and no double thickness. The seam must be as clean as the T-4 coupon's (ideally not visible at all).

Why a separate row. The mechanical side (whether the printer remembers the layer, continues from the same one, whether the checkpoint clears) was checked dry on 2026-09-01 - see T-22, all three phases verified. But in a dry run there is no seam, so the one question that matters to a person remained unanswered: whether the platform descended to the RIGHT height after resuming. V on 09-01: "by the platform holder it was 2 mm from the base... I guess it descended fine, but I cannot measure it" - and that is accurate, because you cannot see a tenth of a millimeter by eye, and the printer does not expose its Z position via the API. If it descends incorrectly, the print will either not stick, or a visible defect will remain there - so the answer only comes with resin. Placed in 3A so it can be done during the same print, rather than pouring resin just for this one thing. Mode: do it with whichever "Resume mode" is enabled at the time (default - Precise); if the seam is bad, repeat with the other one - dry, both modes recover identically (T-36), so any difference, if there is one, will only show up here.

What to do. On a fresh (or NVS-cleared) printer, print three prints that run all the way through. After each one, check the printsOk field on the dashboard's /api/status. After the third, leave the dashboard open. Then print a fourth.

What to expect. printsOk goes 1 → 2 → 3. After the third, the thank-you dialog pops up once on the dashboard with three sums; pressing No thanks closes it. After the fourth print the dialog no longer pops up, and thanksSeen stays true. A canceled or failed print does not move the counter.

Origin: plan item K8 (V 2026-08-26), done in PR #163, released in 0.17.5.

Verified: 0.17.4 + 2f828b2 (2026-09-16) - V tested three prints without a vat: "all good".

What to do. Print the coupon prepared by the slicer side (52 layers, ~16 min, base 743 mm² = 60 % of the plate). Watch the first 6 layers.

What to expect. The base stays on the plate, not on the film. The floor edge is smooth, with no gray "shadows" from smoothing.

Why. 743 mm² is the largest area we have stuck down so far; if it peels off - the coupon is regenerated narrower (the slicer session does this the same day). Origin: slicer side, AA-floor work 2026-08-19.

What to do. Print C:/PIO-build/raftai.zip (~11 min, four pads on one plate, 34 % of the area). A notch on the edge of each pad says which is which: 1 notch = 0.15 mm, 2 = 0.30, 3 = 0.60, 4 = 1.00. ⚠ None of these is what the slicer sends today: our raft is one layer (measured 2026-09-02), so the plate shows where the threshold is from the thicker side, not our real case. Each pad has a 6×6 mm part to grab. After the print, try removing each one separately with a scraper.

What to expect. The most important question for this test - whether the one-layer raft (the one people actually get) holds while printing and comes off with a scraper on this machine. The plate gives a second answer: from which thickness removal starts to need force. If 1.00 needs a knife, the threshold is too high.

Clarified 2026-09-02. This used to say that our default 0.15 mm is "half as thin as the reference 0.30". That is not true: the slicer session compared our .sl1 with the PrusaSlicer reference (same model, same profile) and counted 36 107 versus 37 428 exposed pixels in the pad layer - in both, the pad occupies one layer, because the first cross-section covers the whole band up to 0.3 mm. This printer has no thicker first layer at all - the firmware does not read that field from config.ini.

Why. A two-sided limit from V's experience: too thin a raft loosens while printing, too thick damages the part when removed. All four on one plate is deliberate - separate prints would differ more in resin temperature and film condition than the measured quantity. This test checks thickness, not pad shape (the rim, taper and wrap-around question comes after this). Origin: slicer side, 2026-08-23.

What to do. Print C:/PIO-build/atramu-testas.zip (a cup tilted 9°, 12 mm, 22 support points, 235 layers, ~57 min). Remove the supports with your fingers, no pliers.

What to expect. The supports come off cleanly, leaving a small dot on the surface, not a crater. No support breaks while printing.

Why. The tip thickness is now chosen by the PrusaSlicer engine (0.5 mm), not us; our screen's pixel is 0,1275 mm, so a support thinner than ~0.4 mm would not even appear in the mask (see closed issue 102). Origin: slicer side, WASM port.

Weigh the vat BEFORE and AFTER the print, enter the difference in grams into the "Sample 1" field; repeat with a model of clearly different size into "Sample 2". Check: (a) after the second measurement, the calibrated badge and the formula "x k + f ml per print" (calibrated: x1.092 + 0.39 ml); (b) the vat's remainder matches the scale within ~1 % accuracy (was 0.8 ml error, now 0.11); (c) entering a larger print into the first field, the fit still comes out (order independence) and the rows do NOT swap; (d) deleting one row goes back to "1 of 2", deleting both - x1.000 + 0.00; (e) an absurd weight (99 g for 5 ml) is rejected with an explanation.

Density is measured, not guessed: "X g from Y ml" (vat up to a marker, or a syringe). After changing the density BOTH measurements refit (GRAMS are stored, ml are derived on read).

Backup scenarios (all four checked live on 08-11): an old 0.16.x file without calibration fields - calibration is NOT damaged; a transitional ml file without calUnit - converts exactly; a "prettified" JSON with spaces after the colon - switches do NOT turn into false (WiFi had been turned off); a round trip backup->restore - all 62 fields identical.

Origin: 0.17 R-cal (PR #92). Bugs this test caught: an old backup multiplied the calibration by the density; pretty JSON read booleans as false; the resume checkpoint was zeroed before it was read. Verified: 0.17-dev 5ef206e (08-11, on hardware: x1.092 + 0.39, vat error 0.11 ml, all 4 backup scenarios)