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.
browser to DNS to Lets Encrypt TLS on wg-pk to the WireGuard tunnel to a DNAT on srv-b to CT 100. Proven 200 over v4 and v6, 301 from http, and real build JSON through the full chain.
No WireGuard change and no route were made. The hub peer entry for srv-b is still a slash 32, as all twenty peers are. An earlier plan widened it to carry the service network; that was abandoned once the hub convention was read. Every vhost there proxies to a 10.110.0.x tunnel address directly, so following the convention removed the only step that could have locked the operator out of srv-b.
The srv-b side is one DNAT rule in nat PREROUTING, scoped to the hub as source so the other nineteen peers cannot reach the service network through it. Added live, proven from the hub, then persisted. Rollback copy kept. POSTROUTING order verified unchanged after iptables-save rewrote the file, and mail from srv-b was confirmed delivered afterwards because it traverses the same interface.
WORK-ORDER-004 is rewritten as executed rather than as planned. Its section 0 states that the original proposed a route and a WireGuard change, that neither was done, and why. The original text stays in history at a8081e1.
Three things recorded as not settled: renewal has never been observed to succeed for this name and is first due before 2026-12-10; no acceptance criteria exist for the composer itself, only for the path to it; and the service has no authentication. Also filed an estate finding: shell.infra.civicus.us and corpusdb.infra.civicus.us publish an AAAA one hex digit off the address wg-pk holds, so both are broken for v6 preferring clients.
PROCESS.md section 8 requires host changes to reach STAGING-STATE.md before a session ends. mechcomp-placeholder.service was disabled and stopped on 2026-09-11 and mechcomp.service took 10.20.0.10:8770 in its place. nginx on CT 101 needed no change because the real service took the address the placeholder occupied. The placeholder unit stays on disk, disabled, as the rollback.
Section 5 items closed: mechcomp.service, and replacing the placeholder. Application runtime acceptance is marked partial rather than done, because no acceptance criteria have been written for the composer and it is not reachable from outside.
WORK-ORDER-004 publishes the composer at dev.mechcomp.kane-il.us. The srv-b half needs no change, verified: forwarding on, FORWARD policy ACCEPT, a direct route on vmbr1, and none of the three FORWARD rules matches hub initiated inbound traffic. The single gate is AllowedIPs on the hub peer entry for srv-b, because WireGuard drops by cryptokey routing before consulting any routing table.
Design decision recorded: the public name terminates on the hub and proxies to CT 100 directly rather than through CT 101. Routing it through CT 101 would make the public path depend on a locally signed leaf that expires 2028-11-18 with nothing renewing it. The tunnel already provides the encryption that hop would add. CT 101 keeps serving the internal name.
Section 4 not now decision on the hub route is reopened. It was correct while there was no application to reach. The consequence of leaving it closed is that the operator cannot see the application at all.
TheRON