CYBER-HOBO
concepts
in practice
how it is built

The gate that reads what you write

A rule that lives in a document binds only whoever remembers it. The document conventions here bind differently: they are executable. A gate reads every note at four moments between a keystroke and the canonical record, refuses what does not conform, and prints the fix back to whoever is writing. Nobody needs to have read the spec, because the spec answers. What follows is the machinery in buildable detail: what it checks, where it fires, what it refuses, and the two couplings that keep it honest.

The spec it runs

One file owns the rules. It says what kinds of document exist, which fields each kind must carry at birth, which values a status may take per kind, and how documents point at each other. The gate is that file made executable, and it restates nothing: every refusal names the section of the spec it enforces, so the spec stays the single author of the rules and the gate stays their enforcement. When the rules change, the spec's version moves, and the gate moves with it or refuses to work, which the closing section returns to.

What the checks cover is deliberately narrow. A document declares its kind, and the kind fixes what must be present: a status from that kind's allowed set, a date in one format, a title that opens with the same words the filename opens with, a one-line description where a search or an agent will read it before opening the file. Pointers to other documents are links that must resolve, and a change that would leave a pointer dangling somewhere else is refused too, so a rename heals its inbound references in the same change or does not land.

None of this is bureaucracy by accumulation, because of one rule: a field is required only while a named consumer reads it. Every requirement in the spec traces to a named consumer that actually reads the field, and a field nothing reads is dropped from the requirement, not policed. That is what keeps the schema small enough to be followed.

The schema also knows its own limits in two directions. A subtree may declare fields of its own in a small file at its root, for documents that live under someone else's rules: a client's document control, an event's sheets. The gate reads those declarations on the way down and treats the declared fields as known. A field known nowhere is reported, never refused: the writer either declares it or drops it, and the decision stays a human one.

And the gate judges form only. It cannot tell whether the kind chosen is the right kind, whether the title is good, or whether the content is worth keeping. Those stay with the person, which is where they belong. The gate's whole ambition is that the mechanical part of conformance costs no attention at all.

The four firing points

The gate fires at four moments, and the order matters less than the split: the first two run inside the working session and exist to help, the last two stand on the record's path and exist to guarantee.

At write time, before a file lands through the editing tools, the would-be content is checked. A finding blocks the write and prints the fix back to the writer, the corrected header block included, ready to paste. A malformed note never lands through the file tools at all.

After any tool runs, the working tree is re-checked for changed documents. This is the net under the first check: content can reach the tree through a shell command rather than the editing tools, and this pass catches it there. It feeds findings back rather than blocking, and it says each finding once, so a session is corrected without being nagged.

IN THE SESSION · THE COMFORT ON THE RECORD'S PATH · THE GUARANTEE the write the file tools, before landing a finding blocks the write and prints the fix back after any tool the tree re-checked, shell writes included findings fed back, once the commit staged documents checked refused on the clone, fast the push the record's own installed copy reads the pushed objects refused and logged
One note, four checkpoints. The two inside the session help whoever is writing: they block early and print the fix. The two on the record's path cannot be gone around: the commit is refused on the clone, and the push is judged by the record's own copy of the gate, reading the pushed objects themselves. The arrow leaving the frame is the note landing in the record. A session that never loaded the session hooks still meets both of them.

At commit, the staged documents are checked and a nonconforming commit is refused on the spot. And at push, the record's own installed copy of the gate checks every document added or changed in the pushed range, reading from the repository's objects rather than anyone's working tree. A refused push prints its findings to whoever pushed and logs the refusal. This last point is the guarantee: it does not care which seat pushed, which tools were loaded, or whether the session that produced the content had ever heard of the spec. The local bypasses that exist for the first three points do not exist for it.

The running cost of all four is small: tens of milliseconds per checked call, under a second on a push. A gate that costs attention gets turned off, so the cheapness is load-bearing.

Old notes are never hostages

A gate over a living collection has to decide what happens to everything written before it existed. The rule here is forward-only. A file added in the change at hand is held to the full spec. A file that already existed gets drift checks only: a retired field coming back, and, on its added lines alone, the pointer and link rules. No gate, at any of the four points, ever demands that an old document be fixed before it can be edited. An edit to an old note costs what the edit costs, nothing more.

The backlog still gets measured, just not at the gate. A separate corpus mode reads the whole collection against the full spec and reports the count for a person to read at a review. The distinction is load-bearing: a gate refuses changes, an audit informs decisions. The backlog number falls opportunistically, worst first, when someone is in a file anyway, and nothing blocks on it.

What the prose rule measured

The spec existed before the gate did, as a well-written document with a place in the system's records. Nothing loaded it at the moment a note was written. Following it depended on remembering it, and what that bought is on record: when the count was finally taken, most of the files added under that arrangement were off spec. The failure was not the absence of rules. The rules existed and were not applied, which is the same result the rules chapter states in general, measured here on the system's own conventions.

The gate landed in one evening, and two things from that evening are worth more than the design. The backlog was swept to the current spec and the whole-collection audit reported clean. And the gate's first refusal was its own author's next commit: a pointer written the wrong way on an added line of the spec itself. The finding was fed back, fixed, and the retried commit passed.

The day-one self-catch is the property to notice, more than the clean report. The instance that wrote the gate, with the spec fresher in its context than it would ever be again, still wrote a nonconforming line at the first opportunity. Knowing the rules did not prevent the drift, and the refusal is what does.

The couplings, and who the gate refuses

Two couplings keep the gate from quietly becoming decoration.

The record runs its own installed copy of the check, never the copy that arrives in a push. The order matters: a push that could bring its own gate along would be judged by whatever it brought. Installing the check on the record's side, updated only deliberately, means the judged cannot supply the judge. The pattern transfers to any self-hosted check worth having.

The spec and the gate are version-locked. The gate carries the version of the spec it encodes, and a pushed spec whose version differs from the installed gate's is refused outright. The two move together in one act or not at all. The rule earned its place the ordinary way: before it existed, the spec drifted out of agreement with itself, carrying disagreeing version stamps for weeks. A lint even reported it, and the report changed nothing until the coupling made agreement mandatory. Before the coupling, the spec and its enforcement could drift apart, and they did.

The two halves also fail in opposite directions, on purpose. The session checks fail open: if the machinery they need is unreachable they warn and stand aside, because a writing session halted by its own tooling is a cost the design refuses. The record's check fails closed: if its gate file is missing, the push is refused, because an unguarded record is exactly what the construction exists to prevent. Deciding where to fail open and where to fail closed is most of the design.

The property underneath all of it is the one this page has been circling: the gate has no idea who is writing. It reads documents and has no notion of an author. It refused the instance that built it, it refuses the seat that owns the system, and it would refuse a session that had never heard of any of this, all identically. That indifference is what the page rests on.

The test any rule must keep passing to stay in the set is on keeping rules honest. The kinds of rules and where each one lives are on the rules chapter.