Roadmap item 1986 proposes rebuilding the NAOMS core as one Rust program, in a new, small repository. The odd part is the order of work. Before anyone writes the new code, a spec team writes down what the system must do. A test team then writes tests from that spec. Only after that does a build team, which never sees the old code, implement it. The stated aim, in the item's own words, is that "no past mistake could be carried into the rewrite."

The spec says what, not how

The spec records what must be true, and it names old commits only as evidence that a behaviour exists. Each crate (a Rust library unit) gets a spec file. Its rules are numbered invariants, each paired with an acceptance test. A small script, spec-lint.py, rejects any rule that leaks old code into the text, or that has no test. The script only does bookkeeping. The README is explicit that agents make the judgement calls, and a second set of adversarial agents checks them.

One keep-or-drop test decides what crosses over. A user-visible behaviour, a security property or a failure class stays. A fallback, a compatibility shim or a magic constant with no recorded reason does not. NAOMS is pre-release with no user data, so the rewrite is a clean break.

The old code keeps moving

We did not freeze the old repository. So the spec has a sync step: each commit since the last baseline is triaged as behaviour, fix, test-only, refactor, process or out of scope. When unsure, the rule is to choose "behaviour", because a false "refactor" silently drops something. The first real run covered 14 commits and queued eight spec changes.

Writing the spec found bugs in the code we have

This is the part we did not plan for. Reading the old code closely enough to specify it exposed defects, and they were fixed in the old repo. On 2026-10-22 two such branches landed. One tightened who may park a pending chat message (only proven members, with quotas). The other evicts a member revoked from a call from its encrypted group. Later, spec commits such as 14a5a515e42 fold fixes like these back in as new invariants.

Pathways, written straight in

A pathway is NAOMS's name for a reusable, rule-bound recipe: an ordered set of steps with rules and a gate, that a channel can publish and others can adopt. We introduced them in an earlier post. Here they matter in a particular way.

The spec is not written by running a pathway. Its method is the README rules, the lint script and the adversarial review above. What pathways are, in this rewrite, is part of what the spec must capture, and they were written in live. On 2026-10-15, under an owner directive to fold live design sessions straight into the spec rather than let them drift, the pathways work (roadmap item 1947, "the pathways ask") landed as new rules:

• A plan now states who registered it, and the Decisions view shows the plan's title bound to that person, never to a name carried in a message payload (the agents and roadmap modules, invariant INV-mod-roadmap-110 and its pair in the agents module).
• The spec reserves, for after the first version, an attested exchange of policy and procedure templates with outside Pathways peers: an imported template is verified against the sender's attestation and adopted only by your consent (the integrations module, marked deferred).

So pathways reach the rewrite as a specified feature, written in from live sessions, not as the machine that produced the spec. That distinction is the honest one.

What it does not do yet

There is no new repository or Rust daemon to run. The spec is not finished or signed off. Several answers wait on owner decisions, and the TSP (Trust Spanning Protocol) spec, at its fourth revision, still refuses one key type pending a crypto item. The Pathways-peer template exchange above is explicitly not in the first version. Cutover from the old daemon is a future event.

Written by AI agents from real project logs; owned and edited by Mujo.