3 Commits

Include renames

Author	SHA1	Message	Date
TheRON	a76879f4a0	IDENTITY-CONTRACT: three statements a reader would take as fact, corrected ... G-1 records the standing lesson for this document: an interface document should contain no statement a reader will take as fact when it is not yet one. Three remained in it. Section 2 chain diagram read DECIDES against CT 101, which decides nothing and sets no header. Section 5 routing table listed /m/stl as members. Section 5 stated flatly that export is gated today. Section 8 said the opposite of all three, further down, where an outside implementer would reach it second. None of the three is now removed or softened. The scheme stays and each says which it is - where the line falls once enforced, not where it falls now. README: deploy/ added to the layout, absent since 12 SEP. The reading order no longer contradicts PROCESS section 8 and HANDOFF section 0, and points at DIVERGENCES.md. The AGPL section 13 obligation is marked not met, stated in the document that states the obligation. ACCEPTANCE section 7 records that its correction finally landed in HANDOFF section 7, and why parking a correction in a second document is a bad pattern: it sat here for three weeks while the wrong numbers stayed where people read first. Applied by anchored patcher. Suite 643 passed, oracle intact. Documentation only.	2026-09-14 04:37:01 -05:00
TheRON	54f0296e6f	identity contract: neutral headers, and the chain is not one hop ... External review of bac6120 by the Kane Fabric project found two defects, both mine, both cheap now and expensive once anything implements against them. The contract gave kane-fabric/oidc as an example authentication method. That named a capability in another project which has no OIDC service, no user database and no person-authentication role at all. An example in an interface document is read as an expectation by the next person to implement it -- the same failure as "acceptable for a development name", a plausible clause nobody challenged hardening into a constraint. Method is now specified by shape rather than by example, and the document names no system outside itself. The headers were X-Kane-Auth-Email and X-Kane-Auth-Method. Two things wrong: a jurisdiction in a header name is a deployment fact in an invariant place, in a document that spends a section insisting the compiler must never learn a deployment's membership concepts; and -Email named a format in a field the contract explicitly allows to hold something else. Now X-Mechcomp-Auth-Id and X-Mechcomp-Auth-Method. The receiver is the invariant, the jurisdiction is not. Section 3 now says plainly that the identifier need not be an email address. An opaque or epoch-scoped token fits Author.email without a schema change; the field is named for what this deployment holds, not for what the contract requires. Renaming it would be a format change to every stored record and is deliberately not done. Two new invariants, both from taking seriously that containers owned by other projects will insert themselves into this chain. I-1: exactly one hop decides, and it is the last before the application. Two intermediaries both setting the identity headers is a forgery vector wearing the costume of a deployment change -- the later wins, the earlier believes it decided, nothing reports the conflict. CT 101 is named in section 2 because it is what exists, not because it is the invariant. I-4: anything that is not an affirmative permission is a refusal. Unreachable, timed out, malformed and 5xx all deny. Fail-open and fail-closed are both defensible and are not the same system; finding out which one was built during an outage is the worst way to learn it. Section 6 gains parcels and delivery points explicitly, so the boundary holds whichever primitive the geography layer settles on. Section 7 no longer obliges any named project to provide anything -- the authorisation decision belongs to a membership system between geography and this application, and nothing here asks a geography layer to become an identity provider.	2026-09-12 09:34:57 -05:00
TheRON	bac6120605	deploy: the running configuration, and the identity contract ... 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.	2026-09-12 06:58:14 -05:00