From 2e08edcaab8aed867a518e9dc5e2f20ee058c2c5 Mon Sep 17 00:00:00 2001
From: Vuong Hoang <vh@phasefinal.com>
Date: Mon, 21 Sep 2026 11:33:27 -0700
Subject: [PATCH] fix(draupnir-slicer): warn that every invocation writes
 result.json to CWD
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

brokkr-smithy-dev exercised the slicer on real geometry and found OrcaSlicer
writes result.json into the working directory on --info. I verified it here and
it is worse: --help does it too, which is as read-only as an invocation gets.
An empty directory gained a result.json from --help alone.

Encoded in the wrapper and the Dockerfile rather than left to be rediscovered,
and the wrapper is now committed beside the image that backs it instead of
living only in a home directory on one host.

⚠ The reason they found it and I did not is worth keeping in the header: I
verified --help and called the slicer done. Usage text proves the binary
starts, not that it ingests our geometry or that it behaves while doing so.
They ran both controls through to STL and got manifold=yes, 520 facets,
return_code 0 on each -- which is the verification I should have run before
reporting the provisioning complete.
---
 services/draupnir-slicer/Dockerfile |  5 +++++
 services/draupnir-slicer/orca-slice | 21 +++++++++++++++++++++
 2 files changed, 26 insertions(+)
 create mode 100755 services/draupnir-slicer/orca-slice

diff --git a/services/draupnir-slicer/Dockerfile b/services/draupnir-slicer/Dockerfile
index e1e0196..2ae7e36 100644
--- a/services/draupnir-slicer/Dockerfile
+++ b/services/draupnir-slicer/Dockerfile
@@ -11,6 +11,11 @@
 # mean pinning permanently to a stale build — the exact trap brokkr-smithy-dev
 # rejected when choosing Orca over an old PrusaSlicer tag. A container keeps
 # the slicer current AND leaves the host untouched.
+# ⚠ RUNTIME TRAP, verified not inferred: OrcaSlicer writes result.json into the
+# WORKING DIRECTORY on every invocation — including --help, which is as
+# read-only as a call gets. An empty dir gained a result.json from --help alone.
+# Always invoke from inside the run's own artifact directory. The orca-slice
+# wrapper beside this file carries the same warning.
 FROM ubuntu:24.04
 ARG ORCA_VERSION=2.4.2
 ARG ORCA_URL=https://github.com/OrcaSlicer/OrcaSlicer/releases/download/v2.4.2/OrcaSlicer_Linux_AppImage_Ubuntu2404_V2.4.2.AppImage
diff --git a/services/draupnir-slicer/orca-slice b/services/draupnir-slicer/orca-slice
new file mode 100755
index 0000000..a0e76d3
--- /dev/null
+++ b/services/draupnir-slicer/orca-slice
@@ -0,0 +1,21 @@
+#!/bin/sh
+# Draupnir sliceability check — OrcaSlicer 2.4.2, containerised.
+#
+# Containerised because irv-ml1 (Debian 12, glibc 2.36) CANNOT run the only
+# AppImage OrcaSlicer ships (Ubuntu 24.04, needs GLIBC_2.38 / GLIBCXX_3.4.32).
+# Verified by ldd, not assumed. See services/draupnir-slicer/Dockerfile.
+#
+# ⚠ ORCASLICER WRITES result.json INTO THE WORKING DIRECTORY on EVERY
+# invocation — including --help, which is as read-only as a call gets. Verified
+# here, not inferred: an empty dir gained result.json from --help alone. Call
+# this from inside the run's own artifact dir or it litters wherever you were.
+# Found by brokkr-smithy-dev on --info; I had verified only --help and called
+# it done. Usage text proves the binary starts, not that it behaves.
+#
+# $PWD is mounted at the same path inside the container, so relative paths and
+# the result.json land where you expect. /mnt/smithy/draupnir is mounted too so
+# artifact paths work unchanged.
+exec docker run --rm \
+  -v /mnt/smithy/draupnir:/mnt/smithy/draupnir \
+  -v "$PWD:$PWD" -w "$PWD" \
+  draupnir/orca-slicer:2.4.2 "$@"