TheRON
bac6120605
STAGING-STATE recorded mechcomp.service as delivered at deploy/mechcomp.service on 11 SEP. The unit was real; the directory was not. It existed only on CT 100, so the repository claimed to hold something it did not, and the only way to answer a question about the service was to read the container. The nginx vhost had never been committed at all. Both imported verbatim as they ran on 12 SEP, with their host checksums proven equal at import. A first commit of a configuration file records reality, not intentions -- every later improvement is then a diff against a known-good starting point rather than a rewrite nobody can check. mechcomp.env is deliberately absent. It is the one file that is supposed to differ between instances, it is root:mechcomp 0640 because a deployment's bindings belong to the deployment, and a committed copy would create a second source of truth for exactly the wrong file. ENVIRONMENT.md documents the keys. Certificates and keys likewise. IDENTITY-CONTRACT.md is the boundary between this application and the membership system, and the only document here written to be read by someone who does not work on this repository. Two systems that must agree on an interface need it written once, somewhere both can point at. The compiler does not authenticate anyone; it is told. CT 101 decides, against the membership system, and sets X-Kane-Auth-Email and X-Kane-Auth-Method. They map onto Author.email and Author.method, which already exist and are tested. The parser's refusal to recover `verified` from text was built for this: a record read back is always self-declared, because a file cannot attest to its own verification. The decision belongs at CT 101 and never at wg-pk. The hub carries twenty peers and is estate infrastructure this project does not own, so authorisation there would make every future adjustment an escalation and would teach a shared transport about one project's membership roll. CT 101 already shares the service bridge with CT 100 and CT 102. One gated prefix, /m/. nginx gets one location block, written once. Gating a new endpoint afterwards is choosing a URL in Python -- no proxy change, no escalation. That cheapness makes the placement of the line reversible rather than structural. Today it sits at export: the catalogue and composer are open, and what requires membership is producing an artifact whose design record names an author. Section 6 is the part most likely to erode and is written hardest. The compiler must never learn what a building is, what a membership level is, or that group names exist -- including as a configuration value, which is how the leak arrives by the side door. The test is that the membership system can rename every level and replace its storage without a line of this repository being read. Section 9 deletes the ACL from the roadmap rather than deferring it. The compiler will not have a user table, a login form or a session. Recorded openly rather than assumed: the service is world-reachable and unauthenticated, /m/ is not yet gated, and STL export will therefore ship open. Same posture the whole service already has. The earlier justification -- "acceptable for a development name" -- was wrong and is corrected separately: dev.mechcomp.kane-il.us is production, dev abbreviates Mechanical Compiler Developers, and the name is on printed material. The inbound header strip depends on none of this and should land on its own. It costs one directive and removes a forgery that becomes possible the moment the headers mean anything.
deploy/
The configuration that makes this application a running service, under version control.
Why this directory exists
STAGING-STATE.md recorded mechcomp.service as delivered at
deploy/mechcomp.service on 2026-09-11. The unit was real; the directory was
not. The file existed only on CT 100, so the repository claimed to hold
something it did not, and the only way to answer a question about the service
was to read the container.
That is the failure mode this directory closes. The repository is the single source of truth. Where these files and the hosts disagree, the disagreement is a finding — and the direction of travel is from here outward, not from the host back.
What is here
| File | Lives on | Installed at |
|---|---|---|
mechcomp.service |
CT 100 | /etc/systemd/system/mechcomp.service |
nginx/mechanical-compiler.conf |
CT 101 | /etc/nginx/sites-available/mechanical-compiler, symlinked from sites-enabled/ |
Both are imported verbatim as they ran on 2026-09-12. The first commit of a configuration file records reality, not intentions; any improvement is a later diff that can be read against a known-good starting point.
What is deliberately not here
/etc/mechcomp/mechcomp.env. It is the deployment's own answers —
MECHCOMP_BIND, MECHCOMP_PORT, MECHCOMP_BASE_URL — and it is
root:mechcomp 0640 because a deployment's bindings belong to the deployment.
A committed copy would be a second source of truth for the one file that is
supposed to differ between instances. ENVIRONMENT.md documents the keys; the
values stay on the host.
Certificates and keys. /etc/ssl/mechcomp/ on CT 101 holds a leaf signed by
the local staging CA. Keys are never committed.
Two facts about the nginx vhost worth knowing before editing it
CT 101 does not know the public name. Its server_name is
mechanical-compiler.dev.infra, a hosts-file name resolvable on srv-b, CT 100
and CT 101 only, and its certificate is signed by the local staging CA. Public
TLS terminates at wg-pk, which proxies inward over the WireGuard tunnel to a
DNAT on srv-b. dev.mechcomp.kane-il.us appears nowhere in this file and does
not need to.
Both server blocks are default_server. CT 101 answers whatever Host
arrives, which is why the public name works without being named. That is
acceptable because 10.20.0.0/24 is a portless service bridge with LAN traffic
dropped, so the only thing that can reach port 443 is the tunnel — but it means
server_name is documentation here rather than a filter, and adding a second
site to CT 101 will require that to change.
Applying a change
Infrastructure mode (PROCESS.md §2). One command group, read-only first, a
rollback copy of the file before editing, nginx -t before reload, and the
change proven from outside the container rather than from within it.
A change to either file lands in the repository first and is copied outward. Editing on the host and back-porting reintroduces exactly the drift this directory was created to end.