Build Order

What comes after what, and what must be true first. Sequence, not permission — the scope rule in ../CLAUDE.md still holds, and nothing below is licence to start something early.

This page exists so the trajectory survives between sessions instead of being re-derived or quietly redirected.

The gate model

Two tracks run in parallel, and only one of them is gated.

  THE BOX                                    NAVCOM.APP
  ───────                                    ──────────
  Session 1: watch state machine             Static site
  + CLI client, 7 checks                     directory · docs · status
         │                                          │
         │ gate: all 7 pass                         │ ungated — no protocol,
         ▼                                          │ no keys, no relay,
  Shared core extracted                             │ no daemon
         │                                          │
         ▼                                          │
  Field Terminal  ◄─────────── served from ─────────┘
         │
         ▼
  Console (served from the box, not the web)
         │
         ▼
  Escalation ladder — 7 failure tests written first

Now

On the box. Session 1 is done — all seven definition-of-done checks pass (confirmed 2026-08-18). The gate below is open.

Here. The navcom.app static site. It has no dependency on the loop — no protocol, no keys, no relay, no daemon — which is what makes it the correct parallel work rather than a distraction from the build order.

npm run verify in web/ runs type-check, data check, build, tests and budget together. npm run check:data alone answers "is my CSV edit valid" in about a second.

Measured: 37 pages, worst page 8.0 kB gzipped, zero JavaScript delivered — every page works with scripting disabled. Budget is enforced by web/scripts/budget.mjs, which measures what a browser downloads for a page rather than what sits in build/; those differ sharply here, because the client build still emits chunks no page ever loads.

Verified, not assumed. npm run verify runs type-check, build, 45 tests and the budget. The display rules have regression tests asserted against the built HTML, not only against the logic — a component edited to "simplify" the stale case would otherwise pass every unit test while shipping the failure the schema exists to prevent. Contrast is measured against WCAG AA in both themes rather than claimed. The pages have been rendered and looked at, at desktop and at a true 390px viewport.

Known and deliberate: display rule 4 (one-tap flagging) is not met on a static site and the page says so. The status page's component list is hand-maintained and will drift from this file. The markdown pipeline is unsanitised, which is safe only because the input is this repository.

Live at navcom.app. Vercel, static output, no serverless functions — the deploy runs npm run verify, so a build that breaks a display rule or the bundle budget cannot ship. Web Analytics and Speed Insights stay off: both inject a script, which would break the zero-JavaScript property and H8.

Root console added, 2026-08-27 — the "zero JavaScript delivered" line above no longer covers the whole site. navcom.app/ itself is now a real, interactive page: a search over the directory plus the network's own derived state, working with no setup and no account. It carries its own small budget (60 kB JS / 120 kB page, measured, see delivery.md) rather than the site's zero-byte one. directory/, docs/, status/ and about/ are untouched and still measure exactly as above — the split is enforced by web/scripts/budget.mjs, not just claimed here.

Tracked here rather than left invisible to this file, since it started as reactive work in response to a live complaint, not planned work:

Data is partitioned by region — data/regions/<slug>/ with a manifest carrying country, IANA timezone, languages and whether anyone has checked it. Done while there was one region, because it is cheap now and painful once several people are editing one file.

What is left before this is a real directory: data. Everything else works.

One repository

packages/core · packages/watchtower · web. One install, one wire format, one CI run.

The daemon lived in its own repository and built against the self-contained session-one brief rather than the spec — a summary of a spec is a fork of it. Six divergences resulted: the state enum, on-call, last_drill, provenance, distress position, and a missing callsign the board needed. Every one of them became a type error the moment they shared a package.

The daemon also found things this side had wrong: a replaceable 10910 outliving its publisher and reading as a live watch, and the callsign gap. Its runtime validation was promoted into core, because a client parsing a response needs the same guarantees the daemon needed.

One transport, not two. The CLI had its own send-and-wait and the terminal was about to grow a second. Two implementations of one wire behaviour agree right up until one of them is fixed — and the fix that mattered was Distress retrying indefinitely, which only one had. packages/watchtower/src/client/signal.ts is now a re-export, and the review findings that shaped it moved into core with their tests: publish-failure reporting, response signature verification, and not leaving a timer armed when subscribeMany throws synchronously. The CLI's distress retries until a human answers and stops only on Ctrl-C.

A stale packages/core/dist produced three phantom type errors in consumers before it was made structural rather than remembered: web and packages/watchtower now rebuild core in a pre-hook before check, build and test. A build step you have to remember is a build step that gets skipped at the worst time.

Unblocked — session 1 passed

Extract the shared core — done. packages/core holds the attestation model, keys, NIP-44 sealing, the four event kinds, the board and the directory library. 88 tests. web/ is its first consumer via file:../packages/core; the node is the second.

Two rules are now enforced in code rather than only written down: a watch state demotes automated-oncall to automated when nobody is pageable or no drill has passed, and hard expiry can never drop a distress entry.

Field Terminal — connected. Identity is generated on the device and never leaves it, the Watchtower pubkey and relays are entered by hand from a person, and Status subscribes to 10910 and renders what is actually true.

Verified against real relays rather than argued about. With the daemon running, a terminal reads automated. With the daemon killed and the relay still faithfully serving its last message, the same terminal renders Dark — the replaceable-event corpse, caught live. A relay answering "nothing here" is read through oneose, so absence is a signal rather than a timeout guess.

Device storage is tiered — accruing and wipeable, two keys rather than one, so panic wipe cannot take the wrong half by accident. Its limits are written where an operator can read them: a browser has no keystore, and removeItem unlinks rather than scrubs.

Field Terminal — Status screen: done. Lives at /terminal/, same domain and one build, but in its own route group so it inherits none of the site's chrome, stylesheet or assumptions. It renders Dark before anything is configured, which is the correct answer rather than a placeholder, and states the consequence rather than the label.

Authorship is explicit in the wire format. oncall is a list of authored declarations rather than a count the node picks; last_drill carries an author and an acknowledgements array; a 20912 names its responder as an author; accountability entries are hash-chained. None of it requires counter-signing to ship, and all of it makes counter-signing additive rather than a payload break across three clients and a node.

Two budgets, and the split is enforced. The public site delivers zero JavaScript against a budget of zero — it fails on the first byte, because a document must stay readable with scripting off. The terminal is an application and gets 140 kB; the loop screens bring its worst page to 84.7 kB.

Field Terminal — the loop runs through the phone. Sign on, check in, Query, Assist, Stand down and Distress are wired to the transport in packages/core, so the CLI and the terminal send the same bytes through the same code rather than two implementations that agree until they don't.

Three things came out of building the screens rather than reading the spec:

• Distress now ends only on a human. The retry loop stopped on any acknowledgement, including an agent's — which satisfied neither invariant 2 nor invariant 5 while looking, on screen, exactly like help arriving. An agent answering is reported as still looking for a human and the loop continues. A response with no responder.kind is treated as not-human, because guessing is the one wrong guess this loop must never make
• assist carries a required urgency. "I need someone" and "I need someone now" ask for different responses, and a watch cannot tell them apart from an absent field. text stays optional — requiring a reason delays the send at the moment sending matters
• Every attempt is on screen, including ones that never left the phone. An operator who knows nothing is getting through can act on that; one who believes help is coming when it isn't has been misled at the worst possible moment

Sign-on records what the watch said it could do at the moment of signing on. It is the operator's own note, not the node's, and the screen says so — the node-signed version is the capability receipt, and it lands when the daemon issues one.

Invariant 7 is reachable. panicWipe() and burn() had been written and tested since the storage tiers landed, and no screen could call either — the one operator action that has to work in five seconds under duress had no button. /terminal/wipe/ gives them opposite shapes on purpose: panic wipe is a hold, because it costs an evening and speed wins; burn asks the operator to type their callsign, because it costs everything they have built. The typed gate lives in storage.ts, not the template, so a second screen cannot forget it.

The screen says where a wipe stops, which is the part worth saying: the watch still holds your board entry, the accountability log is on the node and is not yours to delete, and a browser has neither a keystore nor a secure erase. After a wipe it shows nothing at all — a terminal reporting "4 items destroyed" tells whoever is holding the phone that there was something to destroy.

Cached directory — done, and the Field Terminal's screens are complete. /terminal/directory/ is the Dark fallback: something to browse when there is nobody to ask.

No search box, and a test asserts there is none. Query goes to the watch — someone with both hands free does the lookup, can ask a follow-up, and can be wrong out loud. Searching a list one-handed in the cold is the problem the watch exists to solve, so search here would quietly undo the design.

Three decisions worth recording:

• Prerendered into the page, not fetched as data. Caching the page caches the records, so there is no second request to fail exactly when it matters — and the records land in the built artifact, where the six display-rule tests already scan every [data-record]
• The groups start open, which is fewer taps in the field and, less obviously, the reason the rules are checked at all: a collapsed-by-default accordion would have shipped this screen with the records absent from the built HTML and the rules unverified
• The record rendering is the site's own components, unchanged. They are the only tested implementation of the display rules; a second one styled for the terminal would be an untested copy guarding the field where a wrong answer does the most harm. The site's tokens are aliased inside .terminal instead

Staleness recomputes on hydration. A prerendered page freezes confidence into HTML — that is what the daily rebuild and the staleness margin are for — but the terminal is a running application and does better: a page cached three weeks ago does not still claim three-week-old confidence. It also states how old the copy itself is, which is the second age nothing on a record would ever mention.

Two things this turned up. Rule 2's regression test compared a suppressed value against every rendered value on the page, which broke the moment many records shared one: a record with a suppressed hours of unknown also renders sex_offender_ok as the value unknown, a legitimate enum member of a different field. Scoped to the record and field it concerns. And burn() claimed "everything on this device" while leaving the service worker cache — which now holds the directory. It clears the caches, and the screen awaits it. UI built against an unproven payload gets rewritten when the payload changes, which is the whole reason for the gate.

The accountability log — sprint A done, B/C/D planned

A — the log is real on the node. packages/watchtower/src/daemon/accountability.ts: append-only JSONL, fsynced per entry, chain verified at boot, 90-day retention. Actions are written at one site derived from the response actually sent, rather than a call per dispatch branch — one branch away from silence is not a property this file can have.

Two entries record what the watch did not do. contact-not-attempted on every overdue, because the spec says the node MUST attempt contact and nothing does; escalation-not- attempted on every Distress, because the ladder is unbuilt. Neither is *-reached-nobody, which would claim an attempt. They should read badly until they stop being true.

Found while planning it: entriesAbout() and verifyChain() could not compose. Every chain link points at the entry before it in the full log, which is usually about somebody else — so a per-operator view can never verify, and an operator is exactly the party who cannot be handed the whole log. Both functions existed, read as though they worked together, and returned intact: false every time. CompleteLog is now a distinct type and the composition is a type error.

That moves the honest claim: chaining closes tampering for a whole-log reader only. The spec's two-row table is now three rows, and the middle one — selective disclosure — is the load-bearing one.

Also found: neither package type-checked its own tests. fakeConfig was returning a DaemonConfig missing a required field and nothing complained, which is how a suite drifts away from the types it exists to exercise. Both now check src and test.

B — selective disclosure — done. RFC 6962 Merkle tree in packages/core/src/merkle.ts, root published as log_root on 10910 rather than as a new kind. An operator verifies their own entries against a root they saw published, holding log₂(n) sibling hashes and nothing about anybody else.

Two properties the obvious implementation lacks, both tested: domain separation, without which an internal node can be passed off as a leaf and membership forged for data never in the log; and no duplicated odd leaf, without which different logs collide on one root. The suite is weighted towards forgeries — swapped content under a valid proof, a proof from another tree, a truncated path — because "a valid proof verifies" proves nothing about whether an invalid one is rejected.

The client keeps the roots it has seen, in the accruing tier, surviving a panic wipe. A replaceable 10910 means a relay serves only the newest root, so without this the watch is the sole custodian of the evidence against itself. diverged — two roots at the same tree size — is the finding it exists to produce, and it renders above the watch state, because it changes what everything below it means.

C — retrieval — done. log-review as a sixth 20910 signal type, answered with review: { root, entries[{entry, proof}], more }. 20912 is ephemeral, so the log never becomes relay-queryable and C27 holds. The request carries no subject field, which is the access control rather than a check that could be forgotten: the node answers about whoever signed it. Capped at 50, newest first — a response too large for a relay is silence, and silence is never an answer.

D — the review screen — done. /terminal/log/.

The hard part was not rendering entries. A response carries entries, proofs and the root they are against, all three from the watch — so verifying them against each other always succeeds. checkReview accepts only a root the device saw published itself, and the screen says "marking its own homework" for the other case rather than showing a tick.

The limit is stated before the record is fetched, not after. An operator who has just read a screen of green ticks is the least likely person to go looking for what the ticks do not cover — and what they do not cover is omission, which no proof closes.

Gated on opening past people you personally vetted

Counter-signed capability. On-call operators declare their own reachability, drills carry acknowledgement signatures from whoever woke up, and log entries are counter-signed by their subjects. The slots exist and are empty; this fills them.

The gate is honest rather than arbitrary. While the circle is people you trust directly, the node's own account of itself is adequate. The moment the pubkey goes wider, a Watchtower that vouches for itself is exactly the claim a compromised one has most reason to make.

Redundant escalation executors. More than one box able to run the ladder, made idempotent by distress event id. Duplicate pages are a nuisance; a single executor dying mid-Distress is not. Paging is already specified as parallel rather than serial for the same reason — in an emergency you want everyone.

This is ranked above decentralising the board on purpose: a watch going Dark is survivable and specified. An escalation that never fires is not.

Gated on the Field Terminal

Console. Served from the box over LAN or localhost — see delivery.md for why it cannot be served from navcom.app.

The escalation ladder — built, unproven, and running with nobody on-call

Invariant 2 had nothing behind it until now: every Distress the daemon received wrote escalation-not-attempted to the accountability log. It no longer does.

The seven failure modes are tests, and they are the interface. Six are in packages/core/test/escalation.test.ts, numbered to match the spec so a later reader can check the list is still complete rather than taking anyone's word. The seventh — node down at time of distress — is the one failure the node structurally cannot report on, so it is tested on the client instead, and its absence from that file is noted there as a decision.

The executor gets its trigger from the relays, not from the daemon. A design where the daemon receives the 20911 and hands it over satisfies "separate process" on paper while leaving a hung daemon able to take escalation down with it — the requirement failing in exactly the way it was written to prevent. The cost is two processes holding the Watchtower key, and it is the right trade against an escalation path that depends on the component most likely to hang.

No provider is embedded. A channel names what was registered; the node runs a configured command per on-call entry, argv rather than a shell string. Anything else puts a third party in the one path that must not depend on anybody's uptime but the node operator's own.

The responder field on a transition is load-bearing. A client stops retrying on a human responder, so a machine saying "paging" must not be authored as one — that would end a Distress with nobody on the other side while looking like it worked. Only the acknowledgement carries a human author, and it carries the actual human's callsign.

What is still missing, and it is most of the value:

• No drills. last_drill stays null, so automated-oncall still publishes as automated. Weekly randomised drills, published to the status page, are next
• No roster anywhere. A Distress today pages nobody, reaches the end of the ladder at once, and says so. That is the ladder working correctly; it is not the ladder helping, and the status page says exactly that
• No node-side emergency contact. The spec prefers device-initiated anyway, so CONTACT is currently always skipped — failure mode 5, which is tested

What is left, in the order it should be done

Four rules govern this, and they exist because a plan fails in ways a feature list does not.

1. Every item has a fate — do, defer, or decline. A list that only ranks is a list nothing ever leaves
2. Sequence comes from principles.md, not from whoever is writing
3. Every item names an owner — agent, human, or either. An item with no owner is an item nobody does
4. Every item names what not doing it costs. If that cost cannot be stated, the item should be declined rather than deferred

No dates. A volunteer network's capacity is not knowable in advance.

The thing this ordering is built around

Most of the remaining safety work is blocked on people, not code. On-call needs a person. Intake rules need somebody with local knowledge. Playbooks need a human, permanently.

So the code that comes first is the code that makes the human work possible or worth doing — not more machinery around a knowledge layer that is still empty. Twelve invented directory records means the one part of NavCom that works with no watch, no signal and no peers is the one part that is useless.

Milestones rather than a ranked list, because each has a state you can be in or not.

Doing any of these? human-tasks.md has step-by-step instructions for all five, with the real commands, ordered by value per minute rather than by number.

Milestone 0 — Prove what is already built

Done when: every claim below has been true on real hardware at least once.

This one is new, and it comes first because of what a single afternoon of checking turned up. Two shipped features contradicted their own purpose — peer presence required a Watchtower despite existing for operators without one, and the patrol record was not cached offline despite saying it works with no signal. Neither failed a test. Both were found by reading.

Nothing here has ever been used. Not one patrol, not one night. Everything is built for people who do not exist yet, and the ratio of building to verifying has been wrong for a while.

Prefer a finding here to a feature anywhere below. A gap found on real hardware is worth more than a screen built against an imagined one.

Milestone 1 — One operator, alone, tonight

Done when: somebody patrolling alone in one metro can look up a real shelter with no signal, and has a record of their own night.

Everything here is built except the intake rules, which are human work and always were.

Nothing here needs a watch, a box, a peer or a network.

Milestone 2 — One watch, actually staffed

Done when: a Distress raises a real human, and last_drill is a pass rather than null.

2.1 is not code and nothing in this milestone is real without it. Drills run and fail weekly until somebody is on-call — which is the finding, published, rather than a gap.

Milestone 3 — Two people who met once

Done when: two operators who paired over coffee can see each other patrol, with no watch, no box and no leader.

All items built. Milestone 3 now also covers two operators who have never met: a card makes somebody findable in their metro, and an invite pairs them at a distance. What remains is 0.2 — two real devices on one relay — which is a human check, not code.

Milestone 4 — A squad with no box

Done when: four people take turns holding watch on their phones.

All items built. What is not built, and is now the top of Mk1: key rotation. Every member holds the watch key, so removing somebody stops them reading new signals and does not stop them publishing watch state — they can still claim, on the public record, to be the watch. bootstrap.spec.md already recorded this; 4.1 makes it reachable, so it is stated on the screen where somebody joins a squad-held watch.

Milestone 5 — The properties we have written down

Each is self-contained and none blocks an operator. None may be claimed publicly before it ships — the status page states what is built.

5.1 shipped, and the budget is now the thing to watch

Both stated blockers turned out to be wrong, and the real ones were solvable:

• Key distribution — solved by publishing the KEM key as a 10912 bundle instead of putting 1184 bytes into a pairing QR. The pairing code is byte-for-byte what it was
• The downgrade policy — decided, not discovered: a sender whose recipient has published no key still sends, and the operator is told. See signals.spec.md for the wording rules, which are as normative as the mechanism

JavaScript is now at 139.1 kB of a 140.0 kB budget — 99%. That is a real constraint doing its job rather than a problem to route around, and the next addition of any size breaks it. There is no cheap split available: the crypto sits in the shared chunk and nearly every terminal screen seals something, so splitting does not move the worst page, which is what the budget measures.

This needs a decision before the next feature, and the options are honest ones: re-derive the number from what a prepaid Android 8 on a slow network can actually afford, or keep 140 kB as a hard stop that forces something to come out before anything goes in.

5.2 — deferred, because an anchor nobody can verify is worse than none

The design in spec/watch-state.spec.md is right and unchanged. The blocker is that there is no implementation this project can honestly ship.

• The one npm package, opentimestamps, was last published in 2021 and depends on the deprecated request, on bitcore-lib, and on fs@0.0.1-security — a squatted placeholder. This project picked @paulmillr/qr specifically to avoid taking on a supply chain; this would be taking on a worse one, in the daemon that holds the accountability log
• Hand-rolling the OTS serialisation is the alternative, and it is the case the project already has a rule about: a proof we generate that does not verify is worse than no anchor, because the operator believes it. Building the format by hand, with no reference implementation to check against, is how that happens

What unblocks it, either one: a maintained OTS library, or a vendored minimal serialiser with round-trip tests against fixtures generated by the reference implementation. The second is a real afternoon's work and is the likely path — it is deferred, not declined.

Until then the log root is still published and clients still keep the roots they have seen, which is what closes rewriting since somebody looked. Backdating a window nobody watched stays open, and declined.md already says so.

5.6 — how the decision went

A request, not a tally.

The Quartermaster wants "to know what we handed out so I know what to restock", and archetypes.md asks for supply signals that tolerate several people editing offline at once and resolve without a merge UI.

The merge problem has a clean answer: a shared count is the wrong shape. Each operator records their own handouts, the total is a sum of independent records, and sums commute — so there is no conflict and therefore no merge UI to design. Making the conflict unrepresentable rather than resolving it is the move this project reaches for everywhere else.

What is not clean is where the numbers go, and there are two rules in the way:

• "Show a count of anything" is an anti-pattern here — a number invites gaming. Socks handed out is inventory rather than a leaderboard, but a per-operator total published to a squad is a leaderboard whatever it is called
• The patrol record is local by default and by design. Nothing in it reaches a watch, a relay or a peer. Aggregating across people means transmitting it, which is a change to that promise rather than a feature on top of it

Two versions, and they are genuinely different products:

Both were rejected, because the question was the wrong one. The Quartermaster did not ask what was handed out; they asked "so I know what to restock." That is answerable without a tally at all.

So resupply is a need, not a report: "I ran out of socks." No number, so nothing to game. Sparse, because you only say it when it is true. It travels because somebody chose to send it rather than because the system collected it. And there is nothing to merge, so the "several people editing offline" requirement dissolves rather than getting solved — which is usually the sign a reframe is right.

Two things fall out of it:

• The patrol record stays purely local, untouched. Nothing about what anybody carried or gave away is transmitted, now or ever
• The Quartermaster's other half — how fast the shelf empties — is answered by counting their own shelf, which needs no code, no protocol and no self-reports, and is more accurate than self-reports because people forget

It goes to the watch rather than to a named peer, which is a change from how it was first sketched. Routing it peer-to-peer meant a new stored kind for peer-directed notes, and that is a general messaging surface — a chat app with one feature so far. The watch is already whoever is holding things together tonight.

Its own section on the watch screen, below everything anybody is waiting on. Putting it in the same list as "I need someone" would make it compete for attention with things that matter more, which is the alarm-fatigue problem in a quieter dress.

5.9 was listed by mistake, and is deferred

languages.md sets the order of this work, and step 2 is "message catalogue and one-locale bundling, when there is a second language to hold". Step 3 is "a second language chosen because somebody is waiting for it, not to prove the mechanism works". Nobody is waiting for one. Building the catalogue now is the mechanism proving itself, which is the thing that entry exists to forbid.

It would also cost something real. The capability manifest checks that claims appear in the built HTML, in English. Behind a catalogue, every claim becomes a key, and the check either follows the copy into one locale — proving nothing about the others — or it goes. That trade is worth making for a language somebody actually reads, and not before.

What was genuinely due now was the half of it that belongs to 5.8: lang and dir on the document. Without those, logical properties resolve to the left-hand layout regardless of language, and the work is inert. That shipped.

5.10, because the condition it waited on has been met

10910 is unencrypted, so overdue_count announces that somebody is overdue to anybody subscribed. It never says who — but a watcher correlating timing learns something, and that is the Doxxer's method.

watch-state.ts has said since it was written that this should go once a Console exists, because a Console reads the board directly and needs no public field. 4.1 is that Console. Nothing consumes the field today: the daemon writes it, tests assert it, and no client displays or reacts to it.

Left for its own change rather than folded into 4.1, because dropping a published field is a wire-format decision — v3 to v4, the daemon, the spec and the tests — and it deserves to be visible as one rather than a line in a watch-mode commit.

Milestones 6–10 — what would make this a network rather than a tool

Drafted 2026-08-20. Rewritten the same day after critique, which found a load-bearing gap in each of the first two milestones and one indictment of the whole thing.

47 items became 42, and that is a smaller reduction than it should be. Seven were cut outright — listed at the end, under What the rewrite removed — and five were added that the critique showed were simply missing: the write-back path without which Milestone 6 reaches nobody, a genesis route so the watch gate does not brick a new squad, a decision about a wire that does not fit, a spec and a price for a thing being sold, and somebody other than one person able to deploy.

Where 0–5 got to: NavCom is a very good instrument for one operator's night. Going out, being watched, getting help, coming home and being counted are built to a standard worth defending. What it is not yet is an instrument for the thing the project says it is for.

6 → 7 → 8 is a chain, not three independent tracks. 9 and 10 are independent of it and of each other. If only one thing happens, it should be Milestone 6.

Milestone 6 — Knowledge gets in

Done when: an operator who was on that block last night can put what they learned into the directory from the phone in their hand, and the next operator to look sees it.

"And the next operator sees it" is the half the first draft missed entirely. It listed nine ways to capture a correction and no way for one to reach anybody. The directory is a CSV in git, prerendered into the site at build time; a correction from a phone is a nostr event. All nine could have shipped and changed nothing anybody reads.

6.0 — The decision that shapes the rest

Two directories, not one, and that is the answer rather than a compromise:

• Live corrections travel as attestations and are merged over the cached directory at read time, on the device. No build, no deploy, no maintainer, no server. An operator sees their squad's corrections immediately and offline. This is the one that needs no human
• The published directory stays a curated artifact — stable, prerendered, the thing a stranger gets on navcom.app. Corrections are promoted into it periodically by a person

That split is already how everything else here works: live data expires and is derived per device; durable data is an artifact somebody stands behind. Build the live half first — it delivers the whole milestone's value without waiting on anybody.

Never: a review queue with a decider. Corrections stack, they do not compete, and nobody adjudicates between two operators declined.md.

Milestone 7 — Standing without permission

Done when: an operator with no social history and no institution can become visibly credible through contribution alone — and holding somebody else's watch means something.

The genesis problem, and the fix

The first draft gated the watch on a can take watch endorsement. That bricks a new squad: nobody has standing, so nobody can take watch, so Milestone 4 stops working.

Founding is self-evident. Whoever created a watch can always hold it — no endorsement, no permission, nothing to bootstrap. Everybody else needs can take watch from somebody who already holds it. The gate is real, the first holder needs nobody, and a squad grows from one person outward.

Never: a score, a rank, or a comparison between two operators. Provenance by name.

Age rather than expiry. Nothing lapses on a timer. Somebody endorsed medic five years ago is a fact about five years ago, and this system already has one way of handling that — show the age and let the reader weigh it, exactly as the directory does. A second rule for the same problem would be a rule too many.

Declined, not deferred — resistance to forged endorsements. A gate creates an incentive to mint keys that did not exist while endorsements were decoration. We are not building against it, for the same reason counter-signing is gated: the circle is people vetted in person. When that stops being true this becomes urgent, and it is written here so that somebody notices the day it changes.

Milestone 8 — The directory serves whoever opens it

Done when: somebody looking for a bed tonight can use navcom.app themselves, in their own language, without being an operator or installing anything.

Gated on Milestone 6. A person-facing path over 479 scraped skeletons is worse than none: the operator who gets bad data is inconvenienced, and the person who gets it is turned away at 11pm with nowhere else to be. The first draft listed these as independent, which was the most dangerous mistake in it.

8.1 is the exception and can ship today.

Never: anything recorded about a reader. A document cannot watch you back, which is the whole reason the public surface ships zero JavaScript.

Milestone 9 — Nobody is a single point of failure

Done when: the network keeps working for a month with its most active person absent.

Today: one person on call, one box, one directory maintainer, one possible log reviewer, one deploy account. All the same person.

Mostly not code, which is the finding rather than an excuse.

Deferred — RelayNode. It was in the first draft as a way to remove strangers from the path. It also adds a single point of failure to the milestone about removing them: a relay only one person runs is worse than two public ones. Revisit when a public relay actually fails us, or when there is a second person to run it.

The panel — how the terminal gets its interface

Not a milestone. It cuts across all of them: every screen milestones 1–9 produced is a document with buttons in it, and this is how they become an instrument. It is also not new work — it is how build items 2 and 3 in ../CLAUDE.md get done.

Doctrine, phases, gates and the measured diagnosis: design/panel.md.

Measured in Chromium at 390×727 against the built artifact: the watch screen is 96% prose, status is 81% across 15 controls, and Distress — the screen somebody opens when they are in trouble — is 90% prose. The cause is structural rather than visual: screen.css is 66 lines of paragraph furniture, so every screen writes paragraphs, and there are two shared components against twenty routes.

The migration mechanism. 9 test files assert on prose this rewrites. Every red test names a fact that must survive into the readout or the WHY — made green by preserving the fact, never by editing the assertion to match new copy. A test edited to match new copy is the redesign losing information silently, and it is the one outcome here worse than shipping nothing.

Milestone 10 — Off-grid, and the hardware gets funded

Done when: a Distress reaches somebody with no cell network involved.

10.0 — The wire does not fit, and that is measured

The first draft said "the link is a relay you can carry, so nothing about the protocol changes." That is false and the numbers say so. With duty-cycle limits, a hybrid Distress does not fit an off-grid link in any comfortable sense.

So the first decision is not hardware:

10.1 — Compact frame, or classical off-grid? (decision, gates everything below) A compact wire format is a protocol change and real work. Classical-only off-grid is a security downgrade that must be reported the way the existing fallback is — a note, in the operator's language, saying what the link does and does not cover. Neither is free and one must be chosen before anything is built.

Funding the hardware — NavCom Communicators

Pre-orders are how hardware gets funded without an institution, and they are the sharpest version of the risk this project spends most of its effort avoiding: a claim about the future, backed by somebody else's money, with no chargeback.

Nothing below may be built until 10.7 and 10.8 exist. The first draft put the page above the safeguards in the table, which implied the opposite.

Say plainly, in the buyer's language: crypto payments cannot be reversed; a published address proves the money is unspent, not safe; nobody has one of these yet; and taking money creates obligations — tax, consumer protection, shipping across borders to allies in the UK and Australia — that no amount of cryptography addresses.

Never: a countdown, a scarcity claim, a tier system, or a photograph of something that does not exist. Every pattern that makes a crowdfunder convert is one this project already bans on the install prompt, for the same reason.

What the rewrite removed

CLAUDE.md: "an obligation list that only grows is how a volunteer network drowns", and "prefer deleting a rule to adding one." The first draft added 47 obligations to a network with one active person and deleted nothing. It failed the project's own test of a plan.

Cut, and why:

One standing rule for this section, going forward: nothing joins 6–10 without something leaving. The bundle budget has a ratchet; the obligation list should have one too.

Deferred, with reasons

The seven ways people actually work, and who is served

Awaiting a decision

Cannot be given a fate until somebody can describe it: nothing. presets turned out to be the Ghost / Team / Open visibility presets in product/visibility.md — not a missing feature, an unbuilt one. Deferred until Milestone 3 gives it something to configure.

Declined, not deferred

Some real problems are not on this page at all, on purpose — see declined.md. Everything below is deferred: designed, sequenced, and waiting. The difference matters, because a page where every gap becomes future work is a page that only grows.

The multi-holder Watchtower — no longer deferred

A multi-holder Watchtower — signals sealed to a set of keys rather than one, so several nodes hold the same board — is a real option rather than an impossibility, and the earlier claim that "the watch cannot be decentralised" was wrong. What cannot be distributed is who is accountable: one name, because diffused responsibility means nobody acts. The board, query answering and escalation can all be held by more than one party.

It was deferred on a cost rather than a principle. Sealing to M keys means M parties hold the operational picture, and the threat model here is doxxing — so it widens exposure while narrowing dependence. That trade needed a reason.

The reason arrived: a squad with no box. Four RLSH who patrol together have nobody willing to run a machine, and requiring one meant they could not have a watch at all. Inside a squad the exposure is not new — all four already know who is out. That is what being a squad means. Outside one it would be, which is why the box arrangement stays.

Everything deferred above is designed, and none of it is scope. A spec written before the loop is proven is a guess in a more confident format — spec/README.md says so about itself.

Open decisions

The seeding rule

Recorded here because it is the easiest way to do real harm quickly, and it governs A2–A3.

Seed structural facts. Never seed intake rules.

Name, address, type, phone and published hours are public and checkable, and product/propagation.md explicitly endorses seeding them from public sources at method: website, low confidence, visually distinct [C21].

sobriety, pets, id_required, referral_required, sex_offender_ok, curfew and belongings are the fields the directory exists for, and they are absent from public listings precisely because nobody maintains them. They start unknown and stay unknown until a human with local knowledge verifies them. A plausible guess in those fields is the Medic's kill trigger and the fastest way to end the project.