TheRON c72036cbbb docs: the ACL leaves the roadmap, and the development-name excuse is withdrawn
Four documents brought into line with what landed at 54f0296 and ee3fedf.

HANDOFF section 4 item 5 said the ACL was deliberately last. It is deleted, not
deferred. Authorisation lives upstream at the last proxy hop, decided against a
membership system this repository knows nothing about, so the compiler will
never have a user table, a login form, a session, or a group name in any form --
including as a configuration value, which is how that leak arrives by the side
door. An item left the roadmap rather than moving down it.

Item 4 claimed persistence was the prerequisite for a library of saved designs
and for access control. The second half has been false since the identity
contract landed and was found by reading the anchor rather than recalling it.
Corrected, and item 4 now states the position that follows: the filesystem is
the first store, not a database. Design records are already plain text, already
content-addressed by input_id, and already readable by someone with none of this
software. A directory of them is a store with perfect provenance and no schema
to migrate. SQL earns its way in when there is a query walking files cannot
answer -- "every design by this author since March" is that query, and it
arrives with membership, not before.

"Acceptable for a development name" is withdrawn from HANDOFF section 4 and
WORK-ORDER-004 section 3. The name is production, dev abbreviates Mechanical
Compiler Developers, and it appears on printed material. The posture is
unchanged -- world-reachable, unauthenticated, /m/ not yet gated, STL export
will ship open -- but it is carried openly as open question 10 instead of
excused. The phrase survived three documents and two earlier corrections
because it was plausible and nobody challenged it, which is the same mechanism
that produced the stale ingress paragraph.

Section 0 gains the two new documents, with CONSUMER_INTERFACE_GATES.md marked
read-before-proposing-an-integration: several tempting cross-project moves are
recorded there specifically as things not to build yet, and a successor who
finds them independently will be tempted to solve them. Also a note that
deploy/ now holds the unit and the vhost as they actually run, and that the
repository is the single source of truth -- read a container when you suspect
drift, then fix the drift here rather than on the host.

HANDOFF section 1 and PROCESS section 9 gain the same rule: pct exec runs no
shell. A glob, redirect, pipe or && is expanded by the host shell against the
host's filesystem and the container receives whatever literal survives, so an
unwrapped glob reports "No such file or directory" and reads as a broken
container. Third instance of this class after F-035 and F-036 -- each time the
tool was invoked wrongly and the error named the wrong subject. Not filed as a
new failure: it is the same finding as those two, and a third entry would
record the instance rather than the pattern.

STAGING-STATE records the deployment configuration as committed. The unit had
been marked delivered at deploy/mechcomp.service on 11 SEP while existing only
on the host.
2026-09-12 09:48:22 -05:00
2026-08-14 09:21:31 -04:00

Mechanical Compiler

Build the capacity to construct real structures from reclaimed and commodity materials, using whatever fabrication is actually to hand — 3D printing, tabletop CNC, welding, cement casting, COTS stock.

The reference case is a faceted timber shell: planar panels meeting along straight fold lines, converging on nodes, sitting on a platform. Buildable without a factory, provided someone has worked out what the pieces are and how they meet. That last clause is the project. The Mechanical Compiler exists to make the pieces computable, qualifiable, and reproducible by someone who was not present when they were designed.

Scope

In scope: geometry, qualification, and reproducibility of structural members and their interfaces.

Not in scope: building codes, permitting, jurisdictional approval. Qualification and compliance are different things. A qualification says this member is what it claims to be, made this way, from this stock. Compliance is a jurisdiction-specific argument someone else may build on top.

The project records physical claims, never verdicts — section modulus, moment of inertia, material provenance, process parameters. Those are what any future argument would need. A pass/fail verdict would bake in a jurisdiction we do not want to be bound to. Measure and attest; never adjudicate.

Repository layout

docs/                     specification, state, failure log, roadmap
legacy/openscad/          rev 8.0.0 generators — reference, not a live target
fixtures/                 frozen acceptance oracles
tools/reference-toolchain/  pinned OpenSCAD + BOSL2, build-time only
src/mechcomp/             the application
tests/                    acceptance against the oracle

Read docs/ROADMAP.md first for what this is, then docs/ENVIRONMENT.md for how an instance is built. If you are writing provisioning automation, read docs/FAILURES.md before the specification — every entry is something a script written from the specification alone would have got wrong.

Getting started

make deps            # virtualenv, base + CAD requirements
make verify-oracle   # confirm the frozen oracle is intact
make test            # pytest -n auto

make verify-oracle needs nothing but Python. It should pass on any machine at any time; if it does not, stop.

The oracle

fixtures/strap-beam-8.0.0/ holds 123 frozen cases — 113 accepted, 10 rejected — produced by OpenSCAD 2021.01 with BOSL2 at 92d697c2. It is the acceptance criterion for any reimplementation of the generators.

The ten rejected cases are part of the contract. A port that accepts them is wrong, however good its numbers look elsewhere. It is easy to reproduce the geometry and quietly lose the constraint that made it trustworthy.

The generators under legacy/openscad/ are the reference implementation, kept so the oracle can be regenerated. They are not a live target and the running application has no OpenSCAD dependency.

Provenance

This project's documents, code and roadmap are LLM-generated under human direction. That is stated plainly here and in any downstream submission. We do not obscure it.

The maintainer reviews and owns every line. Anything that could not be defended in a review thread does not ship.

Licence

AGPL-3.0-or-later. See LICENSE.

Section 13 obliges us to offer source to users interacting over a network, so any deployed web tier carries a visible link back to this repository. That is a licence obligation, not a courtesy.

S
Description
No description provided
Readme AGPL-3.0
1.1 MiB
Languages
Python 81%
OpenSCAD 18%
Shell 0.5%
Makefile 0.3%
Dockerfile 0.2%