The repo is new and empty, so this is a proposal for how to lay it out before files start landing. Opening as an issue rather than a PR because the design conversation in #enclosure is still live and this should be agreed before anyone commits to a tree.
Happy to be overruled on any of it, and happy to do the work either way.
What the v1 files already tell us
The IARC v3 case is the obvious v1. Looking at what it actually contains, two things are already true in it:
- Screens are already swappable. Step 12 of the build says print
monitor_shell.stl, or print Touch_Display2_shell.stl + Touch_Display2_backplate.stl if you have the Pi Touch Display 2 instead of the 7" HMTECH. So the case already has two display variants living side by side in one flat folder.
- Sensor mounts already went stale. The KLD7 mounts are for the deprecated angle radar and carry a "skip these steps" warning. The OPS mount is current. They sit in the same folder with nothing distinguishing them.
Both of those are structural problems, not file-naming problems. The discussion in #enclosure has been circling the same thing: that we should support as many screens as there are, that the Pi Touch Display 2 hole spacing does not match Display 1, and whether the Pi mounts to the screen or to the case. A flat folder makes every one of those a fork of the whole case.
Proposed layout
cases/
v1-iarc/ # the existing IARC v3 case
source/ # STEP
export/ # STL / 3MF
README.md # build steps, BOM, images
images/
v2/ # when it starts
modules/
displays/
hmtech-7/ # shell + backplate + standoffs
pi-touch-display-1/
pi-touch-display-2/
README.md # the interface every display module must satisfy
compute/
pi5/
pi5-x1202/ # Pi 5 + UPS HAT stack
sensors/
ops243/
kld7-deprecated/
docs/
display-compatibility.md
design-decisions.md
printing.md
contributing-a-module.md
The idea is that a display is an adapter module against a documented mounting interface, not a case variant. Adding a screen becomes a new folder plus a row in the compatibility table, rather than a second copy of the case. That is what makes "support as many screens as there are" tractable instead of combinatorial.
Same for compute: if the Pi mounts to the case rather than to the screen, then Pi 5 vs Pi 5 + X1202 is a module swap, and the point about inserting the screen last for cable management stays true regardless of which display is fitted.
What we would want the docs to carry
display-compatibility.md - a table of screen, outer dimensions, mounting hole spacing, DSI or HDMI, which module fits, tested or untested. This is the page that answers "will my screen work" without reading Discord history. The Display 2 hole-spacing mismatch and the Display 2 product brief are exactly the kind of thing that belongs here rather than scrolling back through a channel.design-decisions.md - short entries with the reasoning. The Pi mounting debate is a good first one: the case gains flexibility in positioning and space use when the Pi is separate, and the screen can go in last. Worth writing down so it does not get relitigated every few months.printing.md - material, layer height, orientation, supports, and the tolerance that actually matters for the dovetails.
Open questions for the people who own the CAD
- Source format. The v1 parts we have are STEP, which diffs badly but at least is neutral and version-controllable. Is there a native format (Fusion, FreeCAD, OpenSCAD) that should be the real source of truth, with STEP as an export? That changes whether
source/ is meaningfully reviewable.
- Do we keep the KLD7 mounts at all? Options: delete, or keep under a clearly deprecated path for anyone with old hardware. We lean toward keeping them parked and clearly marked, but it is not our call.
- Is v1 frozen? If the IARC case is done and v2 is where the work goes, that is worth stating in the README so nobody sends fixes to a dead branch.
- How much STL do we commit? STLs are generated artifacts and bloat history. Options: commit them for convenience, or generate on release and attach to a GitHub Release. Given people printing this will not want to run CAD, we lean toward committing them, but with the source as the thing we actually review.
If this is roughly right
We can open a PR that lays out the tree, moves the v1 IARC files into cases/v1-iarc/ with the build instructions and images intact, splits the display parts into modules/displays/, and writes the first pass of the compatibility table and the docs. Would be one coherent PR, no design changes to any part.
If you would rather a maintainer set the structure and have us fill in pieces, that works too. Mostly we want to avoid three people independently inventing three layouts.
AI disclosure: we used Claude to draft this proposal. The v1 file inventory and the observations about the Display 2 variant and KLD7 deprecation come from the actual files and build README. The structure and the open questions are ours.
The repo is new and empty, so this is a proposal for how to lay it out before files start landing. Opening as an issue rather than a PR because the design conversation in
#enclosureis still live and this should be agreed before anyone commits to a tree.Happy to be overruled on any of it, and happy to do the work either way.
What the v1 files already tell us
The IARC v3 case is the obvious v1. Looking at what it actually contains, two things are already true in it:
monitor_shell.stl, or printTouch_Display2_shell.stl+Touch_Display2_backplate.stlif you have the Pi Touch Display 2 instead of the 7" HMTECH. So the case already has two display variants living side by side in one flat folder.Both of those are structural problems, not file-naming problems. The discussion in
#enclosurehas been circling the same thing: that we should support as many screens as there are, that the Pi Touch Display 2 hole spacing does not match Display 1, and whether the Pi mounts to the screen or to the case. A flat folder makes every one of those a fork of the whole case.Proposed layout
The idea is that a display is an adapter module against a documented mounting interface, not a case variant. Adding a screen becomes a new folder plus a row in the compatibility table, rather than a second copy of the case. That is what makes "support as many screens as there are" tractable instead of combinatorial.
Same for compute: if the Pi mounts to the case rather than to the screen, then Pi 5 vs Pi 5 + X1202 is a module swap, and the point about inserting the screen last for cable management stays true regardless of which display is fitted.
What we would want the docs to carry
display-compatibility.md- a table of screen, outer dimensions, mounting hole spacing, DSI or HDMI, which module fits, tested or untested. This is the page that answers "will my screen work" without reading Discord history. The Display 2 hole-spacing mismatch and the Display 2 product brief are exactly the kind of thing that belongs here rather than scrolling back through a channel.design-decisions.md- short entries with the reasoning. The Pi mounting debate is a good first one: the case gains flexibility in positioning and space use when the Pi is separate, and the screen can go in last. Worth writing down so it does not get relitigated every few months.printing.md- material, layer height, orientation, supports, and the tolerance that actually matters for the dovetails.Open questions for the people who own the CAD
source/is meaningfully reviewable.If this is roughly right
We can open a PR that lays out the tree, moves the v1 IARC files into
cases/v1-iarc/with the build instructions and images intact, splits the display parts intomodules/displays/, and writes the first pass of the compatibility table and the docs. Would be one coherent PR, no design changes to any part.If you would rather a maintainer set the structure and have us fill in pieces, that works too. Mostly we want to avoid three people independently inventing three layouts.
AI disclosure: we used Claude to draft this proposal. The v1 file inventory and the observations about the Display 2 variant and KLD7 deprecation come from the actual files and build README. The structure and the open questions are ours.