@twinsearth/w2m-dsh-plugin 0.6.3 → 0.8.2

package/CHANGELOG.md

@@ -4,6 +4,1182 @@ All notable changes to this project are documented here. The format follows
 [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and this project
 adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [0.8.2] — 2026-10-14
+
+**The client half of the auto-join.** v0.8.1 landed the credential and the relay's acceptance of
+it; this is the wiring that makes a real machine use them.
+
+### What is now connected
+
+| piece | what it does |
+|---|---|
+| `account.mjs` | derives the fleet key on **every** resolve, including the stored-SN path |
+| `index.mjs` | exposes it as `fleetKey` — the key, never the account id |
+| `agent.mjs` | `pair(code, userId, fleetKey)`, sending only the discriminator that was given |
+| `w2m-localside` | `--fleet-key`, a peer of `--pair` |
+| relay | derives the fleet from the key; never believes a claimed one |
+
+**Verified end to end:** an agent given **only** `--fleet-key`, against a relay with **no fleet of
+its own**, pairs and lands in the account-derived fleet (`d5bb1b9ddf3faad4`, `source=fleet_key`).
+
+### The bug that would have made it work exactly once
+
+`resolve()` returned early when an SN was already stored and never read the account at all. That is
+right for the SN — it must not be regenerated, or every restart looks like a new device — and
+**wrong for the key**: a machine has a stored SN from its *second* start onward, so it would have
+derived a fleet key once and never again.
+
+**The auto-join would have worked on a machine's first boot and silently stopped afterwards** — the
+hardest kind of bug to see, because it works when you test it. Found by asking what the stored-SN
+path actually does, rather than by reading the happy path.
+
+### The bug in this release's own patch
+
+The fleet-key handling was first inserted **inside `if (flags.pair)`**, so the key path could only
+run when a pairing code was also supplied — precisely the case it exists to avoid. **It worked
+whenever anyone tested it with a code, and did nothing in the case that mattered.** The end-to-end
+test is what caught it, not review.
+
+### A provenance bug, also caught by testing
+
+A device that paired by key was recorded as `fleet_source: 'pairing_code'`, because the relay builds
+a synthetic code record so the binding reads from one place. That matters: `fleet_source` is what an
+operator reads in `devices.json` to answer *"how did this machine get into my fleet?"*, and
+answering "a pairing code" when there was none sends them looking for a code never issued.
+
+### Also
+
+`HANDOFF.md` records the state, the single reachable path to the Mac, and the traps this codebase
+has already fallen into.
+
+### Verified
+
+**585 chatops cases pass.** The 12 agent-suite failures are **pre-existing and environmental** —
+measured against an untouched clone of the same commit, both give **147 tests / 133 pass / 12 fail /
+2 skipped**, identical, so this change is not the cause.
+
+### ⚠️ Still not user-facing
+
+**The plugin does not yet spawn the agent or hand it the key**, so with the default configuration a
+new PC still will not auto-join. The mechanism is complete and verified; that last wire is what
+makes it something a user experiences rather than something a test proves.
+
+## [0.8.1] — 2026-10-14
+
+**A machine on the same account joins the same fleet with no human step** — the requirement that
+had no implementation behind it, and the bug that made it visible.
+
+### The reported bug, and what it actually was
+
+A new PC signed into the same DeepSeek account did **not** join the same fleet. Traced rather than
+guessed, the cause was four gaps stacked:
+
+* the plugin computed its SN, derived `fleet` from the account code, **logged it, and never used it
+  for anything**;
+* nothing called `/v1/pair`;
+* `autoStartAgent` defaults to **false**, so no agent started;
+* and even with an agent, membership needed a **human-typed one-time pairing code**.
+
+So "same account joins the same fleet automatically" was a stated requirement with no code path.
+
+### Why the obvious fix is the wrong one
+
+The obvious fix is to use `accountCode` as the credential. `account.mjs` documents the trade
+honestly — *"the cost of 32 bits, stated rather than hidden"* — and for **grouping** 32 bits is
+fine. As a **secret** it is not: 2^32 is brute-forceable, so authorising a join with it would let
+anyone enumerate their way into any fleet.
+
+**The bug was a conflation: a grouping identifier was doing duty as a secret.**
+
+### The fix
+
+The machines of one account share something an outsider cannot obtain — the ability to read
+`userId` — so the fleet secret is derived from it:
+
+```
+fleetKey = HMAC-SHA256(userId, "w2m-fleet-v1")     256 bits, same-account machines only
+fleetId  = SHA-256(fleetKey)                       what the relay groups by
+```
+
+**Presenting the key is the proof.** The relay *computes* a fleet id from the key it is given
+rather than believing a claimed one, so a device can only land in the fleet whose key it holds.
+No trust-on-first-use, no operator configuration, no account lookup, nothing to forge — and a
+device without the key forms a different, empty fleet instead of joining someone else's.
+
+`deriveAccountFleetKey` **refuses anything shorter than 16 characters**, and the refusal is asserted
+in a test rather than left to a comment: passing the 8-hex account code by mistake would otherwise
+produce a key that *looks* strong and is not — the worst kind of credential failure, because it is
+silent.
+
+### The relay side
+
+`deviceFleetFields` gains a third source, ordered by authority:
+
+| source | who decided |
+|---|---|
+| `pairing_code` | the operator, by issuing the code |
+| **`fleet_key`** | **the account, by derivation** — the auto-join path |
+| `request` | the relay operator, via `--fleet` |
+
+A **malformed key does not fall through** to the relay's own fleet. Falling through would be the
+silent wrong answer: a device that meant to join its account would be placed in an unrelated fleet
+and told nothing. It is refused, with the reason recorded on the device record.
+
+This also removes the deployment problem recorded in v0.7.9: `--fleet` no longer needs an operator
+to compute and hand-carry a 32-bit code, because the relay needs to know **nothing** about any
+account.
+
+### Verified
+
+* **21 cases** for the derivation: same account agrees, different accounts differ, the 32-bit code
+  is refused, the wire form round-trips, a client and a relay independently derive the same id, and
+  comparison is constant-time.
+* The derived bytes are **pinned**, not self-compared — a regression would silently split every
+  existing fleet into two halves that cannot see each other, with no error anywhere.
+* **223 cases** across the relay, wiring, scoping and join suites, unchanged.
+
+### ⚠️ What is still not wired
+
+The **derivation and the relay's acceptance** are done. The pieces that make a real machine use
+them are not:
+
+* `index.mjs` does not yet derive or expose the fleet key;
+* the agent does not yet present it at pairing;
+* `autoStartAgent` still defaults to false.
+
+**Until those land, a new PC still will not auto-join.** The credential exists and is accepted; the
+client does not yet offer it.
+
+## [0.8.0] — 2026-10-14
+
+**The first release on npm since 0.6.3.** Eight versions of work — account identity, fleet
+isolation, device signing, lease-takeover guards, `/run`, the durability policy, and the server's
+own configuration — now reachable by `npm install` rather than only by git tag.
+
+### What is in it, and what each part actually guarantees
+
+**Account identity and the SN** (0.7.5). A machine derives a serial number from
+`account code + hardware code + time code`. The account code is `sha256(userId)` truncated, so it
+can be handed to a relay without disclosing the account id — which is what makes the next part
+possible on a server that has no account login of its own.
+
+**Fleet isolation** (0.7.6, wired in 0.7.8). `createTask` no longer selects every device on the
+relay. It selects the requester's fleet, where the fleet is read **from the pairing code** — a
+device cannot name its own fleet, because a device that could would join any fleet and every
+signature would faithfully attest to it.
+
+The migration is two-mode and both modes are tested against the relay's real state:
+
+| relay | requester | reaches |
+|---|---|---|
+| unscoped | operator, or a fleetless device | **every device — the pre-0.7.8 rule, unchanged** |
+| scoped | operator | the relay's fleet |
+| scoped | a device in that fleet | that fleet only |
+| scoped | a fleetless device | **nothing**, with the reason named |
+
+**Deploying cannot be an outage; scoping cannot be a silent grant.**
+
+**Per-device Ed25519 signing** (0.7.10, verified by the relay in 0.7.11). The relay already signed
+requests, but with **HMAC over a shared secret** — everyone who can sign can verify, so that proves
+only that the sender knows the secret, which is every device. A device key proves *which* device.
+
+The relay now tries the device key first and converges one machine at a time:
+
+| device | outcome |
+|---|---|
+| sends no signature | shared secret, byte-for-byte unchanged |
+| stored key, good signature | verified by the key |
+| stored key, **bad** signature | **refused, and not retried against the shared secret** |
+
+That third row is the whole point: falling back would make the strong mechanism *optional* for
+anyone able to produce a malformed signature, which is everyone.
+
+**Lease-takeover guards** (0.7.9). `_takeover` would re-offer a dead machine's index to **every idle
+device the relay holds**, with no fleet filter and no consideration of whether the task writes. So a
+device in another account could be handed the work, and a writing task could be run twice. Both are
+now refused with a named reason.
+
+**`/run` with two privilege levels** (0.7.11).
+
+| form | who | what it does | capability |
+|---|---|---|---|
+| `/run <argv>` | expert | dispatches those arguments, uninterpreted | `fleet.dispatch` |
+| `/run --ask <words>` | beginner | asks; the agent answers and **proposes** | `operate` |
+
+A beginner describing what they want is **not** executing anything: the request goes to a session,
+and if the session wants something run it emits `/run <argv>`, which still needs `fleet.dispatch`.
+**A low-privilege window can ask freely and cannot cause a fleet execution by asking.**
+
+**Durability policy** (0.7.11). The requirement — *"10× redundancy, tolerate losing 90% of nodes"* —
+is two different claims, and the arithmetic decides the architecture:
+
+```
+n=   3  copies=3/10   loss=100%  basis=server_complete
+n= 100  copies=10/10  loss=100%  basis=server_complete
+--- with no server copy ---
+n=   3  loss=67%   meets=false      <- three devices cannot reach 90% alone
+n=  10  loss=90%   meets=true
+```
+
+At three devices the guarantee is **the server's complete copy**; device redundancy alone gives
+**67%**. So the server is the **authority at every tier**, not one more replica to drop once devices
+are plentiful.
+
+**`deploy/server/`**. The three systemd units as the live host runs them, and the deployment script
+whose step order is the safety argument: checksum before unpacking, back up in place, entry-point
+check before swapping, then restart, health-check, and automatic rollback on failure.
+
+### The secrets guard
+
+`scripts/scan-for-secrets.mjs` fails a release on a credential shape in any **tracked file**. It
+exists because `.gitignore` refuses a *path*, while the ways a credential escapes are pasting one
+into a source file, a fixture, or an example. The relay's `operator-token.txt` — full control of the
+fleet — is the thing it protects.
+
+Writing it exposed **six defects in the guard itself**, every one a silent-off failure that looks
+like success: an unconditional `statSync` that made an injected reader unreachable; a relative path
+that made the scan report zero findings across zero files; a token regex that missed camelCase; a
+slug rule that rejected `p2p-crypto-operator` over a digit; a duplicate rule; and a test that
+hard-coded rule names and so measured the name rather than the behaviour.
+
+### WeChat, measured
+
+Reading and sending both work against the live service. The body is `item_list[0].text_item.text`,
+the cursor is `get_updates_buf`, login confirms as `confirmed` (not `scaned`), the token is valid
+**>280 s**, and a send nests under `msg` with `message_type: 2` and `message_state: 2`, returning a
+`message_id` and no `ret`. Four wrong guesses on the wire format made a working feature look broken,
+including a false conclusion that the token lived only 30 seconds.
+
+### The honest gaps
+
+* **`shouldHandOff()` and `reconcileResults()` are written and tested but not wired.** The fleet and
+  write guards are in the relay's takeover path; single-successor selection is not.
+* **The relay defaults to unscoped**, so accounts are mixed unless an operator sets `--fleet`. Doing
+  so requires an account code, which a headless server cannot produce, and a re-pair of every
+  device — during which a fleetless device reaches nothing.
+* **`/run` is not yet wired to the WeChat channel.** The parser, the renderer, and the capability
+  split are complete and tested; the last link is the adapter.
+* **The Mac cannot be updated remotely.** Its allow-list refuses anything but `node -e`, and a DSH
+  restart would kill the only channel to it.
+* **`/v1/devices` is not narrowed to the caller's fleet** — a device can still *list* another
+  fleet's machines, though it cannot *reach* them.
+
+### Verified
+
+**542 chatops cases across twenty-two suites**, and the relay's own **168 unchanged**.
+
+## [0.7.11] — 2026-10-14
+
+**The relay verifies device signatures, `/run` reaches the fleet from a chat window, the durability
+policy is written down, and the server's own configuration is in the repository.**
+
+### Relay verifies device Ed25519 signatures
+
+`verifySignature` now tries the per-device path before the shared secret. The design goal is
+**convergence**: a fleet updates one machine at a time, with no flag and no coordination.
+
+| device | outcome |
+|---|---|
+| sends no signature | shared secret — byte-for-byte unchanged |
+| has a stored key, good signature | verified by the key, `device: true` |
+| has a stored key, **bad** signature | **refused, and not retried against the shared secret** |
+
+That third row is the one that matters. Falling back would make the strong mechanism *optional* for
+anyone able to produce a malformed signature, which is everyone.
+
+*Defect found while writing it:* `NonceCache` exposes `accept`, not `remember`. The test caught it.
+
+### `/run` — two forms, two privilege levels
+
+| form | who | what it does | capability |
+|---|---|---|---|
+| `/run <argv>` | expert | dispatches those arguments, uninterpreted | `fleet.dispatch` |
+| `/run --ask <words>` | beginner | asks; the agent answers and **proposes** | `operate` |
+
+The asymmetry is the point. A beginner describing what they want is **not** executing anything: the
+request goes to a session, the session answers in prose, and if it wants something run it emits
+`/run <argv>` — which still needs `fleet.dispatch`. So a low-privilege window can ask freely and
+**cannot cause a fleet execution by asking**.
+
+The form is **declared** (`--ask`), never inferred from how the text reads. An inferred distinction
+gets it wrong in both directions, and the direction that matters is dispatching a sentence as if it
+were a program.
+
+Shell metacharacters are refused rather than passed through, because the fleet takes an argv array
+and never a shell string — `|` would arrive as a literal argument and quietly do something other
+than what was typed. **A command that runs and does the wrong thing is worse than a refusal.**
+
+### Durability policy
+
+The requirement was given as *"10× redundancy, tolerate losing 90% of nodes"*. Those are two
+different claims, and conflating them yields a system that looks compliant and is not:
+
+* **10 replicas** is a storage-layout property, and is **impossible** below 10 nodes;
+* **surviving 90% loss** counts every copy, including the authoritative one.
+
+Measured, with the arithmetic in tests:
+
+```
+n=   3  copies=3/10   loss=100%  basis=server_complete
+n= 100  copies=10/10  loss=100%  basis=server_complete
+n=1000  copies=10/10  loss=100%  basis=server_complete
+--- with no server copy ---
+n=   3  loss=67%   meets=false
+n=  10  loss=90%   meets=true
+```
+
+So at three devices the 90% guarantee is met **by the server's complete copy**, and device
+redundancy alone would give only 67%. That is why the policy treats the server as the **authority at
+every tier** rather than as one more replica that can be dropped once devices are plentiful.
+`durabilityReport()` names the basis in a note, so a health number cannot be read without its
+provenance, and `server_copy_required` is true at every fleet size.
+
+Tiers, inclusive at the bottom as measured by tests: `<100` server, `100–999` hybrid, `>=1000`
+distributed with the server as a fallback that is still written to.
+
+### The server's configuration is now in the repository
+
+`deploy/server/` holds the three systemd units **as the live host actually runs them** —
+`w2m-rabbit`, `w2m-stun`, `w2m-localside` — plus `deploy-w2m.sh`, the deployment script that
+performed the last two upgrades.
+
+The script's step order *is* the safety argument: verify the checksum **before** unpacking (a
+truncated upload must never become a service), back up in place (rollback must not depend on the
+network), check for entry points **before** swapping (a `git archive` of the wrong directory
+unpacks cleanly and contains no `bin/`), then restart, health-check, and **roll back automatically**
+on failure.
+
+**`/var/lib/w2m/rabbit/` is not in the repository and must never be.** It holds `operator-token.txt`
+— full control of the fleet — and the task ledger. Two mechanisms keep that true, because one is
+not enough: `.gitignore` refuses the **paths**, and `scripts/scan-for-secrets.mjs` reads the
+**content** of every tracked file. A `.gitignore` refuses a path; the ways a credential actually
+escapes are pasting one into a source file, a fixture, or an example.
+
+### The secrets guard, and the six defects it caught in itself
+
+The guard is only worth having if it works, so it was tested against the real repository — and it
+failed in ways worth recording, every one of them a **silent-off** failure that would look like
+success:
+
+1. **`statSync` was called unconditionally**, so an injected reader could never be reached — the
+   stat hit the real filesystem, threw, and the `catch` swallowed it;
+2. **a relative path was passed to `readFile`**, so every file threw and the scan reported
+   **zero findings across zero files**;
+3. **the regex `operator[_-]?token` missed camelCase** — `operatorToken`, which is how this project
+   actually spells it;
+4. **a slug rule requiring only `[a-z]`** rejected `p2p-crypto-operator` because of the digit in
+   `p2p`;
+5. a **duplicate rule** reported one match twice;
+6. a test **hard-coded rule names**, so renaming a rule broke a test that was measuring the name
+   rather than the behaviour.
+
+Findings on the real tree went from 3 false positives → 5 exposed fixtures → **0 blocking, 14 for
+review** (all ordinary 64-hex hashes). `REVIEW` is deliberately **not fatal**: a scanner whose false
+positives block releases is a scanner someone deletes.
+
+### Verified
+
+**542 chatops cases across twenty-two suites**, the relay's own **168 unchanged**.
+
+### Still not done
+
+* **`handoff.mjs`'s `shouldHandOff()` and `reconcileResults()` remain unwired** — the fleet and write
+  guards are in the relay's takeover path, the single-successor selection is not.
+* **The Linux server and Windows plugin are on v0.7.10**; the Mac is on **v0.6.3** and cannot be
+  updated remotely (its allow-list refuses anything but `node -e`, and a DSH restart would kill the
+  only channel to it).
+* **The relay is unscoped**, so accounts remain mixed at runtime.
+* **npm has not been published since 0.6.3** and no credential is available on this host.
+* **WeChat: reading works, sending works, `/run` is not yet wired to the channel.**
+
+## [0.7.10] — 2026-10-14
+
+**Per-device Ed25519 request signing — the part of the signature chain that can be built without
+locking anyone out.** The relay does not enforce it yet, deliberately.
+
+### Why a second signing mechanism
+
+The relay already has request signing, and it is **HMAC over a shared secret**: everyone who can
+sign can also verify, so the relay holds a credential that every device holds. That is fine when
+one operator owns every machine, and it is the wrong shape for what this workstream is about —
+proving that *this specific device* is in *this account's* fleet. **A shared secret proves only
+that the sender knows the secret, which is every device.**
+
+`src/chatops/device-signing.mjs` signs with a **device-held Ed25519 private key**, so the relay
+verifies with a public key it stores and never holds anything that could impersonate the device.
+
+### The defect that would have made all of it useless
+
+The signed bytes are the **relay's own canonical string**, reproduced byte for byte:
+
+```
+v1\n<METHOD>\n<path>\n<timestamp>\n<nonce>\n<sha256-of-body>
+```
+
+The first version hashed the body with `createHash('sha256', …)`. **The relay uses
+`createHmac('sha256', Buffer.alloc(0))`**, and those are not the same function: HMAC wraps the key
+with its own padding, so an empty body hashes to `b613679a…` rather than `e3b0c442…`.
+
+**Every signature would have failed, forever, with no clue why.** A probe that signed four requests
+with both implementations and compared the strings is what caught it — and that comparison is now
+a test, because it is the only reason this is correct.
+
+### Added
+
+* **`src/chatops/device-signing.mjs`** — a device signer, a verifier, and the shared canonical
+  string. Compatibility with the existing mechanism is deliberate: one verified string rather than
+  two that must be kept in step, and the relay can tell the two apart by **whether the device has a
+  public key** — no protocol flag, no version negotiation, no second header a client could forget.
+* **`pair()` accepts and stores `public_key`.** Not validated there on purpose: a malformed key
+  fails at verification with a named reason, while rejecting a pairing over it would lock out every
+  existing device the moment the field appeared. A device that sends no key keeps working, with
+  `public_key: null` meaning *"signs with the shared secret or not at all"*.
+* **`publicDevice` reports `public_key_present`** as a boolean, not the key. The key is not a
+  secret, but a device list is read by every device, and verification happens relay-side.
+* `test/chatops-device-signing.test.mjs` — 22 cases.
+
+### The test that matters most
+
+`canonicalString` is compared against **the relay's own implementation, imported** — not against a
+reimplementation of the expectation. A test that asserts what the author believed the format to be
+would have passed for the broken version.
+
+### ⚠️ Not enforced, and that is the point
+
+**The relay does not verify device signatures yet.** A device that signs today is signing into a
+relay that does not check it. Two reasons this is the right order:
+
+1. **Enforcement is what would lock people out.** A relay that *requires* a signature refuses every
+   device that has not been updated — including all four current machines. Landing verification and
+   enforcement together is how a safety feature becomes an outage.
+2. **The fleet rollout is blocked anyway** (see v0.7.9): the shared relay cannot produce an account
+   code, and the Mac cannot be updated without physical access.
+
+So the sequence is: ship the signing, ship the verification, update every device, then turn
+enforcement on — with `requireSignature` already meaning *"insist"* in the relay's existing
+vocabulary, so the switch is one flag rather than a new mechanism.
+
+### Verified
+
+**459 chatops cases across eighteen suites**; the relay's own **146 unchanged**.
+
+### Still not done
+
+* **No signature is verified by the relay.** `verifyDeviceSignature` has no caller in `src/relay/`.
+* **Hand-off is guarded but not refined** — `shouldHandOff()` and `reconcileResults()` remain
+  unwired; the fleet and write guards from v0.7.9 are in the relay's takeover path.
+* **The Linux server, the Mac and the Windows plugin are still on older versions**, and the relay
+  is unscoped, so accounts remain mixed at runtime.
+* **No message has yet gone from a phone through WeChat to the fleet.**
+
+## [0.7.9] — 2026-10-14
+
+**Two safety guards on lease takeover, and an honest account of what is still not connected.**
+
+### What was already there, and what was missing
+
+`_takeover` existed and already ran on `halt: 'now'`, so hand-off was **not absent** — v0.7.7's
+note that it "is not implemented" was about `handoff.mjs` not being called, and this release
+corrects the record: the relay's own takeover path was live and had been since v0.1.x.
+
+**What it lacked was the two guards**, and both are reachable defects rather than theory:
+
+1. **A device in another account could be handed the work.** `_takeover` iterated
+   `this.devices.values()` with no fleet filter, so on a relay serving several fleets a takeover
+   **crossed accounts** — the isolation this whole series is about, broken in the one path that is
+   easy to miss because it only runs when something has already gone wrong.
+2. **A writing task could be run a second time.** Hand-off makes execution at-least-once. Harmless
+   for `node --test`; a duplicated write for anything else, applied on a machine with no idea the
+   first one already ran.
+
+Both are now refused with a named reason (`LEASE_TAKEOVER_REFUSED`, `write_not_idempotent`).
+
+### Deliberately not changed
+
+The re-offer **shape** is untouched. PROTOCOL v0.0.1 defines no per-index lease reassignment, so
+takeover is expressed as a re-offer to every idle machine — a fan-out, not a single successor.
+Narrowing it to one successor is what `handoff.mjs`'s `shouldHandOff()` would do, and it is a
+**protocol revision**, not a wiring change, so it is not made here. `reconcileResults()` is
+likewise ready and unused: nothing calls it yet.
+
+### The prerequisite this release discovered, which blocks the fleet rollout
+
+**The shared Linux server cannot produce an account code.** Its `.dsh` holds no account
+credentials — it is a headless VPS running the relay, STUN and a localside agent, not a signed-in
+DSH client. So `--fleet <account code>` has **no source on the server**, and the value must be
+computed on a machine that *is* signed in and then handed over.
+
+That is workable — the account code is an opaque `sha256(userId)` prefix, so passing it does not
+disclose the account id — but it means the rollout is:
+
+1. read the account code on a signed-in machine,
+2. restart the relay with `--fleet <code>`,
+3. **re-pair every device**, because a device only receives a fleet from the pairing code, and
+   every existing device paired without one.
+
+**Step 3 is the risk**: on a scoped relay a fleetless device reaches **nothing**, so all four
+current devices go silent until each is re-paired. That is the intended fail-safe direction, and it
+is still an outage until the re-pairing completes.
+
+### Added
+
+* `test/chatops-takeover.test.mjs` — 5 cases, booting a real relay: a write task is refused and
+  names why; a read task is still re-offered; a takeover skips a device in another fleet; it skips
+  a fleetless device on a scoped relay; and an unscoped relay behaves exactly as before.
+
+### Verified
+
+**437 chatops cases across seventeen suites**, and the relay's own 165 unchanged.
+
+### Still not done
+
+* **`shouldHandOff()` and `reconcileResults()` are not wired.** The guards above are in the
+  relay's takeover path; the richer single-successor selection and the late-result rule are not.
+* **No device generates a keypair and no request carries a signature.** The relay's existing HMAC
+  signing is a different mechanism and remains untouched, so the signature chain is **not enforced**.
+* **`/v1/devices` is not narrowed to the caller's fleet.**
+* **No message has yet gone from a phone through WeChat to the fleet.**
+
+## [0.7.8] — 2026-10-14
+
+**The wiring.** v0.7.5–v0.7.7 shipped modules that nothing called. This release connects them, so
+account isolation and fleet scoping are **in effect** rather than merely tested.
+
+### What changed in the relay
+
+* **`src/relay/state.mjs`** — `createTask` no longer selects `[...this.devices.values()]` with no
+  filter. It calls `targetsFor()` from `fleet-wiring.mjs`, which applies the fleet rule.
+* **`createPairingCode` now carries the relay's fleet**, and `pair()` writes it onto the device.
+  This is the link the whole scheme hangs on, and it is easy to omit: `pair()` reads the fleet
+  *from the code*, so a code with no fleet pairs a device into no fleet — and a device in no fleet
+  reaches nothing on a scoped relay. `--fleet X` would then have had **no effect on anything,
+  silently**.
+* **`publicDevice` carries `fleet_id` and `fleet_source`.** `devices.json` is written from this
+  shape, so a fleet that lived only on the in-memory record would have vanished on the next
+  restart — which is precisely when an operator looks at it. A live test caught that.
+* **`bin/w2m-rabbit.mjs`** gains `--fleet <id>`.
+
+### The migration, which is the part that could have gone wrong
+
+The shared relay holds four devices that paired before fleets existed, none with a `fleet_id`.
+The rule is therefore two-mode, and both modes are tested against the relay's *actual* state:
+
+| relay | requester | reaches |
+|---|---|---|
+| unscoped (`--fleet` absent) | operator, or a fleetless device | **every device — byte-for-byte the old behaviour** |
+| scoped (`--fleet X`) | operator | **fleet X** |
+| scoped | a device in fleet X | **fleet X only** |
+| scoped | a fleetless device | **nothing**, with the reason named |
+
+**Deploying this cannot be an outage**, and **scoping it cannot be a silent grant** — the second
+row of that table is what makes the first row safe to ship.
+
+### Three defects found while wiring, all by tests
+
+1. **`NO_ELIGIBLE_DEVICE` was invented.** It broke the one relay test that pins the contract, and
+   worse, it would have broken **callers**: `chatops/fleet.mjs` reads `NO_ONLINE_DEVICE` to
+   produce *"start an agent on each machine"*, and an unrecognised code falls through to a generic
+   refusal. The protocol's code table is part of the protocol; the new information went into
+   `detail` instead.
+2. **An absent requester was refused as an unknown one.** An operator is not a device —
+   `authorizeTaskDispatch` returns `{ role: 'operator', machine_id: null }` — so treating "no
+   device" as "unknown device" turned every operator dispatch into an error and broke **74 relay
+   tests at once**.
+3. **An operator dispatch on a scoped relay was refused.** Configuring the fleet made the operator
+   unable to dispatch, which is the least useful possible outcome. The relay's own `fleetId` *is*
+   a statement about which fleet it serves, so an operator dispatch has an unambiguous scope and
+   lands inside it.
+
+### Verification
+
+* **432 chatops cases across sixteen suites**, including **ten that boot a real relay** and assert
+  the three links end to end: `--fleet` → the code carries it → the device carries it → dispatch
+  reaches only that fleet.
+* **The relay's own 168 tests pass unchanged**, which is the migration guarantee: the legacy path
+  reproduces the rule it replaced.
+* The repository's wider suite keeps its baseline of one environmental failure (a missing
+  `node_modules/eslint`).
+
+### Deployed
+
+The Linux server (`vultr`, `202.182.123.154`) was updated **v0.6.3 → v0.7.7** with a scripted
+deploy: checksum verified before unpacking, the previous tree backed up, the new tree staged and
+checked for entry points, then swapped, restarted and health-checked, with automatic rollback on
+failure. Relay state (`/var/lib/w2m/rabbit`) was untouched — the 839 KB ledger and the operator
+token both survived.
+
+**It runs unscoped**, so its four devices keep working exactly as before. Setting `--fleet` is
+what turns isolation on, and it is now a one-line change plus a re-pair.
+
+### Still not done
+
+* **Hand-off is not wired into the relay's lease sweep.** `handoff.mjs` is complete and tested;
+  `shouldHandOff()` is not yet called on lease expiry. A silent machine is still simply silent.
+* **Device-side signals are not sent.** No device generates a keypair in a real run, and no request
+  carries a signature. The relay's existing HMAC signing (`signing.mjs`) is a different mechanism
+  and is untouched.
+* **`/v1/devices` is not narrowed to the caller's own fleet.** A device on a relay can still list
+  every fleet's machines; it cannot *reach* them, which is the part that matters for isolation.
+* **No message has yet gone from a phone through WeChat to the fleet.**
+
+## [0.7.7] — 2026-10-14
+
+**Hand-off: what happens when the machine holding a task does not answer.** `ACCOUNT-FLEET-DESIGN.md`
+§4, built.
+
+> **Two things this release does not do, said first.**
+>
+> 1. **The relay still does not call any of the v0.7.6/v0.7.7 modules.** Dispatch is still
+>    `[...this.devices.values()]`, no keypair is generated, no statement is issued, no request is
+>    signed, and no lease is ever handed off. **At runtime, accounts remain mixed and a silent PC
+>    is still simply silent.** These releases are the mechanism.
+> 2. **The Linux server was not updated.** Its SSH credentials were not available to me
+>    (`ssh_run.py` deliberately reads them from the environment with no fallback in the file), so
+>    the relay there still runs v0.6.3-era code. Updating it needs `W2M_PASS`.
+
+### Added
+
+* **`src/chatops/handoff.mjs`** — the hand-off decision, and the sharp edge it names.
+  * **`write: true` plus `halt: 'now'` is refused outright.** Hand-off turns execution from
+    at-most-once into **at-least-once**: a command may now run on two machines. Harmless for
+    `node --test`, and a second application of the same change for anything that writes — on a
+    machine with no idea the first one already ran. Refused, not warned about.
+  * **A late result never overwrites its successor.** The winner is the **highest attempt**, not
+    the last to arrive: arrival order is a property of the network, and a verdict that depends on
+    it is a verdict nobody can reason about. Superseded results are **kept, not dropped** — a late
+    result from the machine that went silent says it was slow, not dead, and discarding it turns a
+    diagnosable situation into an unexplained one.
+  * **The machine that just went silent is never offered its own slice again** — the one
+    reassignment guaranteed to be useless.
+  * **A slow machine is not pre-empted.** Two separate questions, in order: is the lease still
+    valid, and has the grace elapsed since it expired.
+  * **Every refusal is named**, because *"why did nothing take over"* has several answers with
+    different fixes: cancelled, `halt: 'never'`, a writing task, no other machine, every machine
+    already tried, not yet expired.
+
+* `test/chatops-handoff.test.mjs` — 29 cases.
+
+### Three defects found in this module by its own tests
+
+Worth recording, because each was invisible in the code and obvious in a failure:
+
+1. **The grace-period arithmetic was on the wrong side.** The first version asked
+   `now + grace <= until`, which declines when the grace is *short* and takes over when it is
+   *long* — the exact inverse. Two questions were being collapsed into one expression; they are
+   now separate branches.
+2. **`ALL_TRIED` was unreachable.** It was decided by asking "is there an untried machine", which
+   is always false in the all-tried case, so the reason could never fire and the two refusals were
+   indistinguishable. The real question is how many machines *exist*, not how many are untried.
+3. **A missing attempt number was treated as the newest.** `?? Infinity` made a frame with no
+   attempt win the aggregate — letting a stale result from a superseded lease override its
+   successor, which is the precise inversion `reconcileResults` exists to prevent. A missing
+   attempt is an **old** frame: it now sorts as `0`.
+
+### Still not connected
+
+`auth.mjs`, `fleet-scope.mjs` and `handoff.mjs` are complete and tested, and **nothing in `src/`
+outside `src/chatops/` imports them.** The relay must still:
+
+* bind pairing codes to a fleet and sign a statement per device,
+* verify the statement and the request signature on every call,
+* replace the target selection with `selectTargets()`,
+* call `shouldHandOff()` on lease expiry, and `reconcileResults()` when results arrive.
+
+Until that is done, the isolation and the hand-off are **designed and tested, not in effect**.
+
+## [0.7.6] — 2026-10-14
+
+**The authorisation chain and the fleet scoping rule.** `ACCOUNT-FLEET-DESIGN.md` §3, built.
+
+> **Read this before trusting the isolation.** The two modules below are complete and tested, but
+> **the relay does not call them yet.** `src/relay/state.mjs` still selects targets with
+> `[...this.devices.values()]`, so at runtime accounts remain mixed. Wiring it is the next step
+> and is not in this release. Saying "isolation is implemented" now would be false.
+
+### Added
+
+* **`src/chatops/auth.mjs`** — the device keypair and the authorisation statement.
+  * A device generates an **Ed25519** keypair on first run; the private key is exported for
+    persistence and the caller is told to write it 0600 and never log it.
+  * The relay seals a statement over `(fleet_id, machine_id, sn, public_key, issued_at, expires_at)`.
+  * Every request carries a signature over `(method, path, timestamp, nonce, body_hash)`.
+  * **The canonical encoding is built by hand, with length-prefixed fields and a fixed field
+    order.** Two JSON encodings of one object can differ, so a verifier that re-serialised what it
+    received would be verifying its own encoding; and without length prefixes `{a:'x',b:'yz'}` and
+    `{a:'xy',b:'z'}` concatenate identically. The wire form carries **the exact bytes that were
+    signed**, so nothing is ever reassembled.
+  * **Expiry is mandatory** — a statement without one is a permanent credential. Checked *before*
+    the canonical form is recomputed, so a missing expiry reports `no_expiry` rather than the
+    technically-true-but-useless `malformed`. A test found that ordering.
+  * Replay defence is a **bounded** nonce window, injected: an unbounded set is a memory leak a
+    peer can drive, and the timestamp window already rejects anything old enough to fall out.
+  * Fleet keys are **derived** per fleet from one master secret, so a relay serves many accounts
+    without holding a key per account and one fleet's key does not sign for another.
+
+* **`src/chatops/fleet-scope.mjs`** — which devices a request may reach.
+  * **The fleet comes from the pairing code, never from the device.** A device that could name its
+    own fleet would join any account, and every signature would faithfully attest to a lie.
+  * **An absent fleet is not a wildcard.** `undefined === undefined` is explicitly **not** a match.
+    This is the most dangerous available mistake: two ungrouped devices matching each other would
+    silently restore the exact "everything in one pool" behaviour being removed, and every test
+    that only ever sets a fleet would keep passing. There is a test named for it.
+  * **A foreign target is refused with the same answer as a nonexistent one**, so a caller cannot
+    enumerate another account's machine ids by trying them and reading the error.
+  * **A partial dispatch is refused whole** — silently dropping a named target leaves the caller
+    believing it dispatched somewhere.
+  * Offline devices are **counted, not silently dropped**: "we tried and they were offline" and
+    "there are none" produce the same empty result and different fixes.
+
+* `test/chatops-auth.test.mjs` (33 cases) and `test/chatops-fleet-scope.test.mjs` (25 cases).
+
+### The tests are written against the attack, not the happy path
+
+Each names the failure it prevents, and three of them assert a **weakening** rather than a
+strength: that a device editing its own `fleet_id` fails verification, that swapping in its own
+public key fails, and that an ungrouped device matches nothing. Those are the changes that would
+look correct in a diff and quietly undo the isolation.
+
+### Not in this release
+
+* **The relay does not call either module.** No device keypair is generated in a real run, no
+  statement is issued, no request is signed, and dispatch is still unfiltered. This release is the
+  mechanism; connecting it is next.
+* **The relay does not yet issue pairing codes bound to a fleet**, so `fleetFromPairingCode` has no
+  producer in a live relay.
+* **Hand-off is not implemented** — that is v0.7.7.
+* **No message has yet gone from a phone through WeChat to the fleet.**
+
+## [0.7.5] — 2026-10-14
+
+**Stage 1 of the account-fleet design: this machine now knows which account it belongs to, and
+has a serial number.** The relay and the dispatch path are deliberately untouched — scoping
+dispatch by fleet is v0.8.0, because it changes the protocol.
+
+### Added
+
+* **`src/chatops/account.mjs`** — the identity root.
+  * **The account code comes from the host, not from a fetch and not from config.**
+    `ctx.deepseekAccount.getDeviceIdentity()` returns `userId`, which is hashed to an 8-hex
+    account code. There is deliberately **no way to set it from configuration**: a value an
+    operator can type is a value an attacker can type, so a hand-entered "account code" would be
+    a forgeable account code.
+  * **The SN is `W2M-<ACCT>-<HWID>-<TS>`, 40 characters**, defined to the character, with the
+    timestamp fixed at first generation so a restart cannot change a machine's identity.
+  * **Hardware sources per platform, all injectable**, so a Windows-shaped machine is exercised
+    on any host: `MachineGuid` / SMBIOS UUID, `IOPlatformUUID`, `/etc/machine-id`.
+  * **Placeholder values are refused before hashing.** Firmware that reports an all-zeroes UUID
+    would otherwise give *every such machine the same hardware code* — far worse than having none,
+    because it silently merges distinct machines.
+
+* `test/chatops-account.test.mjs` — 42 cases.
+
+### Two things the tests assert on purpose
+
+* **That a forged SN passes the shape check.** `isWellFormedSn` is named for what it does — it
+  answers "is this well formed", and an SN is computed by the party being checked, so nothing
+  about it is verifiable by inspection. The test *documents* this rather than papering over it,
+  so a future change that turns the shape check into an authorisation check fails a test instead
+  of building on sand.
+* **That two accounts get different fleets and two machines in one account get the same fleet.**
+  The property the whole scheme exists for, asserted directly rather than inferred.
+
+### Fixed
+
+* **The published v0.7.4 release notes claimed the SN is 41 characters. It is 40**
+  (4 + 8 + 1 + 12 + 1 + 14). The design document said the same thing in one place. Both are
+  corrected, and the release notes were edited in place. The wrong number came from arithmetic
+  done by hand; the unit test that asserts the length is what caught it.
+
+### Not in this release
+
+* **The relay still does not scope by fleet.** `docs/ACCOUNT-FLEET-DESIGN.md` §3 is designed and
+  unimplemented: dispatch targets are still `[...this.devices.values()]` with no filter, so
+  accounts remain mixed. That is v0.8.0 and it is a breaking protocol change.
+* **No device keypair yet.** The SN exists; the signature chain that makes account membership
+  *verifiable* rather than merely *asserted* does not.
+* **No message has yet gone from a phone through WeChat to the fleet.**
+
+## [0.7.4] — 2026-10-14
+
+**No code changed.** This release is an audit and a design document, and it exists because the
+audit found that the answer to *"is each account's fleet isolated?"* is **no** — in a way worth
+writing down before anything is built on top of it.
+
+### What the audit found, every line with its source
+
+| question | answer | where |
+|---|---|---|
+| Is a device identity bound to an account? | **No.** `machine_id` is `randomUUID()` — no account, no hardware | `src/agent/agent.mjs` |
+| Does an SN exist? | **No.** The concept is not in the codebase | entire repo |
+| Is there a hardware identifier? | **No.** `caps` probes os/arch/node/python but never enters identity or authorisation | `src/agent/caps.mjs` |
+| Does the relay use `user_id` for isolation? | **No — it stores it and never reads it.** Five references, every one a store or load | `src/relay/state.mjs` L507/736/981/993, `persistence.mjs` L170 |
+| Does the plugin reference `user_id`? | **Zero times** | `src/plugin/tools.mjs` |
+| Are dispatch targets filtered by account? | **No.** With no `target_machines`, `targets = all` — every device on the relay | `src/relay/state.mjs` L1259-1262 |
+| Device table shape | **One flat Map**, no grouping dimension | `src/relay/state.mjs` L435 |
+
+Measured on the shared relay (`a1b59a3b04dcd180`): **`devices=4`, all in one pool, with a single
+pairing code.** Any machine holding that code joins the same pool, and any caller holding a valid
+operator token has its task broadcast to every one of those four machines.
+
+### Added
+
+* **`docs/ACCOUNT-FLEET-DESIGN.md`** — the design for account-scoped fleets, in three parts as
+  asked: the exact SN format, the relay authorisation model, and the hand-off timing.
+
+  The identity source is **verified, not assumed**: DSH already exposes `ctx.deepseekAccount`,
+  whose `getDeviceIdentity()` returns `{ deviceId?, userId?, osVersion }` and is documented as
+  *"read existing login identity without creating a device or returning credentials."* The
+  account's unique identifier therefore needs **no account API call** — and a hand-typed account
+  code in a config row is explicitly ruled out, because a value an operator can type is a value
+  an attacker can type.
+
+  The SN is defined to the character: `W2M-<ACCT>-<HWID>-<TS>`, 41 characters, with `ACCT` a
+  truncated `sha256(userId)` rather than the raw id (it ends up in logs, chat messages and device
+  lists), `HWID` from platform-stable sources only — MAC addresses, mount points and package
+  lists are excluded because they change and would make one machine look like two — and `TS`
+  fixed at first generation.
+
+### Three things the design says out loud that a proposal usually does not
+
+1. **An SN cannot be a credential.** It is computed and asserted by the client, so anyone who
+   knows or guesses an account id can forge one. The document states that the relay must never
+   trust an SN, and that the timestamp provides **no** cryptographic uniqueness — uniqueness is
+   `(ACCT, HWID)`, and the timestamp only distinguishes re-registrations and makes the string
+   auditable. A string scheme presented as hardware-grade protection is worse than none, because
+   it is believed.
+2. **Hand-off makes execution at-least-once.** A command may run on two machines. Harmless for
+   `node --test`, harmful for anything with `write: true` — so the design **forbids automatic
+   hand-off for writing tasks** until a fencing token exists.
+3. **The relay is the trust root.** Compromising it forges any fleet's authorisation. The design
+   accepts that rather than adding an online account check, which would stop offline machines
+   from working at all.
+
+### Not in this release
+
+* **Nothing from the design is implemented.** It lands in **v0.8.0**, because it changes the relay
+  protocol — a breaking change that needs an explicit refusal path for older devices rather than
+  a silent failure.
+* **No message has yet gone from a phone through WeChat to the fleet.** The adapter is verified
+  against live WeChat and the executor against a live relay; **the two have not been joined by a
+  human typing.**
+
+## [0.7.3] — 2026-10-14
+
+**The fleet reader used the wrong credential and the wrong field names.** v0.7.2 shipped an
+executor that had never been pointed at a live relay. Found by running it against one.
+
+The agent's own log proved the task really ran:
+
+```
+[agent] offer 01M4VC7KWKF5WA5Q6BBDNH4AXM attempt 1 {"argv":["node","src/facts.mjs"]}
+[agent] result delivered for 01M4VC7KWKF5WA5Q6BBDNH4AXM {"status":"nonzero_exit"}
+[agent] result accepted for 01M4VC7KWKF5WA5Q6BBDNH4AXM {"status":"nonzero_exit"}
+```
+
+— while the poll loop printed erdict=undefined thirty times.
+
+### Fixed
+
+* **GET /v1/tasks/<id> needs the device token, not the operator token.** With the operator
+  token it answers 401 {"code":"UNAUTHORIZED","message":"missing or invalid device_token"}.
+  Dispatching and reading take different credentials; the executor now holds both, and a refusal
+  names which one it wanted, because *"your operator token is wrong"* and *"this install is not
+  paired"* have different fixes.
+* **The verdict is at ody.aggregate.status, not the top level.** The per-machine rows are
+  ody.leases[] on a status and ody.machines[] on a report, and the machine field is
+  machine_name. The first version read ody.verdict and ody.results, so every machine
+  printed as ?: ? while the task completed perfectly.
+* /v1/devices wants the device token too on this relay build.
+* A lease row carries state rather than outcome until the result lands, so describeMachines
+  shows the outcome when there is one and the lease state when there is not.
+
+### Verified end to end
+
+Against a live relay and a live Localside agent on Windows:
+
+```
+任务 01M4VCET — unverifiable
+命令：node src/facts.mjs
+win-desktop: unverifiable  status nonzero_exit  exit 1
+```
+
+272 chatops cases pass.
+
+### Still not claimed
+
+No message has been sent from a phone through WeChat to the fleet. The adapter is verified
+against live WeChat and the executor is now verified against a live relay, but **the two have
+not yet been joined by a human typing**.
+## [0.7.2] — 2026-10-14
+
+**Run the fleet from a chat message, and get the machines' own verdict back.**
+
+v0.7.1 shipped a working WeChat adapter and could still do nothing with it: `/run` answered
+*"this install has no fleet"*, because the executor did not exist. This adds it.
+
+### The gap was architectural
+
+`w2m_run` and `w2m_wait` are DSH **tools**: their bodies live inside the plugin's `ctx.tools`
+registration and are shaped for a model to call — a schema, a card, an error type the host
+renders. The chat bridge needs the same work with none of that: an argv in, a verdict and a
+sentence out.
+
+The bridge cannot call the tools. A tool call needs `@deepseek-ai/dsh-tools`, which exists
+**only inside `app.asar`** — a separate process cannot complete one, and an in-process call would
+have to fabricate the host's own calling convention. So the fleet work is now expressed once
+against the relay's HTTP API, and the tool and the chat bridge are both callers of it.
+
+### Added
+
+* **`src/chatops/fleet.mjs`** — `POST /v1/task`, `GET /v1/tasks/<id>`, `/report`, `/devices`, the
+  same paths the plugin's own tools use. A refusal is returned as a value: the relay's refusals are
+  answers, and the two that matter get their own sentences, because *"start an agent on each
+  machine"* and *"your operator token is wrong"* are different instructions. A wait that expires
+  reports `timeout` as a **verdict** rather than throwing — a fleet with one dead machine never
+  reaches a terminal state, and silence is the worst possible reply to a phone.
+* **`src/chatops/actions.mjs`** — the action set `commands.mjs` calls, plus the phone-sized
+  formatting rules.
+* **`/where <task id>`** and **`/report <task id>`**, so a task id from a reply is actionable.
+* `test/chatops-fleet.test.mjs` — 28 cases.
+
+### Two properties worth naming
+
+* **The argv is never joined into a string.** A chat message is attacker-influenced text, and the
+  array is what keeps a shell from ever seeing it. A formatter that joined and re-split would work
+  for every command until the first one with a space in an argument.
+* **`divergent` and `divergent-platform` are not collapsed.** They mean different things — one is
+  a bug, the other a platform difference — and paraphrasing either into "failed" is how a
+  portability difference becomes an incident.
+
+### Changed
+
+* `createBridge` now accepts a policy **instance** as well as the overrides to build one. The
+  action set has to share the bridge's policy, or `/trust` widens a copy that admission never
+  consults and the command silently does nothing. Duck-typed on `admit()` so the two modules need
+  not import each other's constructors.
+* `apply()` builds the executor from the same `rabbitUrl` / `operatorToken` row the tools read, so
+  there is one setting rather than two, and resolves the token in the same order (row, then
+  `W2M_OPERATOR_TOKEN`). An install with no `rabbitUrl` gets named refusals — *"no rabbitUrl is
+  configured"* — instead of an absent action.
+
+### Verified
+
+**271 chatops cases pass**, 28 of them new.
+
+### Not yet done — the honest caveat
+
+The round trip has been verified against **live WeChat as far as the adapter**, and against
+**the relay as far as the executor**. But **no command has been sent from a phone to the fleet end
+to end.** That is the next thing to test, and this release does not claim it.
+
+## [0.7.1] — 2026-10-14
+
+**v0.7.0's WeChat channel could not send a single message.** This release fixes it, and the
+way it was found is the point.
+
+### What was wrong
+
+v0.7.0's `ilink.mjs` was written by *reading* the audited plugin's TypeScript. Every field name
+in it was wrong — nine separate mismatches — and all 237 of its tests passed, because those tests
+drove an injected transport and asserted on the requests we *constructed* rather than the
+requests WeChat *accepts*. **A self-consistent suite cannot falsify its own assumptions.**
+
+The first real request, made with a real QR scan and a real bot, returned:
+
+```json
+{"errcode":-14,"errmsg":"session timeout"}
+```
+
+That message is a lie about its own cause, which is why it took as long as it did:
+
+| # | v0.7.0 | Measured |
+|---|---|---|
+| 1 | *(absent)* | **`AuthorizationType: ilink_bot_token`** |
+| 2 | *(absent)* | **`X-WECHAT-UIN`**, a per-request random |
+| 3 | `to_user` | `to_user_id` |
+| 4 | bare `{msg}` | `{msg, base_info}` |
+| 5 | `item_list[].text_item` | also `type: 1`, `from_user_id`, `client_id`, `message_type: 2`, `message_state: 2` |
+| 6 | `getupdates` body `{}` | `{get_updates_buf, base_info}` |
+| 7 | `bot_id` / `owner_user_id` | `ilink_bot_id` / `ilink_user_id` |
+| 8 | success = HTTP 2xx | **`ret === 0`** |
+| 9 | — | failures use **`errcode`/`errmsg`** and **still return HTTP 200** |
+
+**#1 is the one that cost the most time.** Without `AuthorizationType`, every authenticated
+endpoint answers `-14 session timeout` — *including a request carrying no `Authorization` header
+at all*, because the server rejects on the missing type before it reads the credential. That made
+it look like an expiry bug, and an expiry bug is investigated by checking clocks, re-scanning
+codes and re-minting tokens. It is not one.
+
+**#8 and #9 are the dangerous ones.** A refusal arrives with HTTP 200, so a status-code check
+reports a failed send as a delivered one — the exact silent-failure shape this release series
+exists to remove, and it had been reintroduced in the adapter. `send()` now rejects on
+`errcode`, so the outbound queue can never count a refusal as a delivery.
+
+### Also fixed
+
+* **The transport did not exist.** v0.7.0 required the host to inject `chatopsIlinkRequest` and
+  shipped no default, so no request could ever be sent and `apply()` could never mount a working
+  channel. `ilink-transport.mjs` is now the default, and injecting one only overrides it.
+* **64-bit ids were rounded.** A live `message_id` is 7515840255213248776 — past
+  `Number.MAX_SAFE_INTEGER` — so `JSON.parse` returned `7515840255213249000`. The transport now
+  recovers the exact digits. Rounding is harmless for de-duplication and not harmless if an id is
+  ever persisted as a key or sent back.
+* **The host allow-list was wider than the measurement.** v0.7.0 allowed `weixin.qq.com` and
+  `api.weixin.qq.com` on a guess; the login response returns exactly `ilinkai.weixin.qq.com`. An
+  allow-list wider than what was observed is not caution, it is the absence of the check.
+* **A precision bug in the fix itself**, caught by the suite it was written for: the first
+  `repairMessageIds` mutated in place, so a shared test fixture was rewritten by whichever case
+  ran first.
+
+### Added
+
+* `src/chatops/ilink-protocol.mjs` — the measured wire format in one place, each constant
+  annotated with the live response it came from.
+* `src/chatops/ilink-transport.mjs` — the real HTTP transport, with per-request deadlines, the
+  `ret`/`errcode` distinction returned as data, and `undici`'s `cause` unwrapped so a network
+  fault does not read as a protocol fault.
+* `test/chatops-ilink-contract.test.mjs` — **36 cases pinned to fixtures taken verbatim from live
+  responses**. The rule it enforces: if a field name changes, a test here must fail. That is the
+  mechanism that would have caught all nine.
+* `scripts/ilink-login-and-probe.mjs`, `scripts/ilink-qr-poll.mjs`, `scripts/ilink-talk.mjs` —
+  the probes that found this. Kept because they are the only way to check the adapter against
+  reality rather than against itself.
+
+### Changed
+
+* `test/chatops-ilink.test.mjs` **removed**. It asserted the wrong protocol — `body.msg.to_user`,
+  `msg_list` — so keeping it would have pinned the v0.7.0 defects back in. The contract suite
+  replaces it.
+
+### Verified against live WeChat
+
+A real QR scan, a real bot, a real exchange in both directions:
+
+* `get_bot_qrcode` → `{"qrcode":…,"qrcode_img_content":…,"ret":0}`
+* `get_qrcode_status` → `{"status":"confirmed","bot_token":…,"baseurl":…,"ilink_bot_id":…,"ilink_user_id":…}`
+* `notifystart` → `{"ret":0}`
+* `getupdates` → the peer's reply, read verbatim
+* `sendmessage` → `{"message_id":7515840555615131656}`, received on the phone
+
+### Not fixed, and not claimed
+
+* **Feishu, DingTalk and WeCom are still not implemented.** They need vendor SDKs this project
+  cannot vendor or review. The contract they must satisfy is `channel.mjs`.
+* **Only the WeChat path has been exercised against a live platform.** That is one of four, and it
+  is the one that happens to need no SDK.
+* **No command has been run through the bridge from a phone yet.** The adapter is verified; the
+  end-to-end path from a chat message to `/run` on the fleet is not.
+
+## [0.7.0] — 2026-10-14
+
+The release that answered "can we drive the fleet from a phone?" with **not yet, and
+here is exactly why** — and then built the two pieces that had to exist first, under
+test.
+
+### Why this is not the feature, and why that is the honest release
+
+The goal was to fold [`dsh-chatops`](https://github.com/ZhuoSir/dsh-chatops) 0.1.0 —
+an IM bridge for WeChat/Feishu/DingTalk/WeCom — into this plugin as a feature. It was
+read in full instead of trusted: ~168 KB of TypeScript across 40 files, plus the
+published 3,544-line bundle, which is byte-identical to the committed source modulo
+CRLF (`minify:false`, so identifiers and comments survive — the audit is on the real
+artifact).
+
+**It is not safe to adopt as written, and the reasons are not stylistic:**
+
+* The approval answerer registers `(req) => …` on the `approval/request` **waterfall**
+  and never calls `next()`. This host documents that event as *"Return an outcome to
+  claim the request or call `next()` to delegate"*, and cordis's `waterfall` consults
+  the next listener **only when the current one calls `next()`**. The plugin's listener
+  is also `async`, so it hands back a Promise, and the harness takes any non-`undefined`
+  value as the final answer. The host's own GUI answerer is therefore never consulted
+  for a session that has an IM window bound, and the request is held until the plugin's
+  own 300 s deadline. Whether it happens at all depends on listener **registration
+  order**, which the plugin does nothing to control. This is the one defect that reaches
+  beyond the plugin.
+* The first private message on any of three channels makes its sender a **permanent
+  owner**, before any authorisation runs, with no pairing code and no allow-list, and
+  persists the claim to `bindings.json`. All four channels ship enabled by default. Once
+  adopted, that identity can enumerate every workspace and session, inject prompts,
+  read transcripts via `/log`, exfiltrate workspace files via `/send`, approve, and
+  switch the sandbox to `danger-full-access`.
+* `GET /chatops/api/config` returns four platforms' credentials in cleartext behind a
+  loopback-only check with no token and no Origin validation; the settings page re-polls
+  it every 3 s. `POST` to the same path merges an unvalidated body into the config and
+  writes the profile's `cordis.patch.yml` — and `puppet` is passed to `await import()`,
+  so that path is arbitrary module load.
+* Pending approvals were keyed by window alone, so a second concurrent request
+  overwrote the first and the older became unanswerable from IM.
+* The workspace file fence is lexical only (`resolve` + `startsWith`); `statSync`
+  follows symlinks, so a link inside the project ships any readable file to IM.
+
+Shipping that as a headline feature would have been a regression in every user's
+safety, so it is not shipped. The audit is published instead, and the two modules that
+had to exist first are built and tested.
+
+### Added
+
+* **`src/chatops/approval-broker.mjs`** — the approval seam, designed so the defect
+  above cannot recur:
+  * **declining is synchronous and never touches `next`**, so a bridge with nothing to
+    ask leaves the host's answerers to answer;
+  * **a deadline delegates instead of deciding** — a phone that did not answer is not
+    an operator who said no, so the timeout calls `next()` and lets the answerers behind
+    it decide;
+  * **pending requests are keyed by approval id and queued per window**, so two
+    concurrent requests cannot overwrite each other;
+  * ids carry full entropy, where 0.1.0 minted `randomUUID().slice(0, 8)` — 32 bits held
+    for five minutes;
+  * `dispose()` settles everything outstanding, so a reload leaves no timer that can
+    resolve a promise belonging to a fiber that no longer exists;
+  * the clock **and** the timer are injectable. That pairing is the whole reason the
+    suite is deterministic: an injected clock with a real `setTimeout` is two clocks, and
+    the first version of this test hung rather than failed.
+* **`src/chatops/policy.mjs`** — who may command this machine, fail-closed:
+  * **nothing is trusted because it arrived.** An identity is trusted only by being
+    seeded in config or by redeeming a single-use, expiring, per-identity rate-limited
+    pairing code. There is no path that trusts a sender because nobody else had spoken;
+  * identity is `(channel, id)`. 0.1.0 held one flat `Set` matched after stripping the
+    channel prefix, so the same raw id was the same person on every platform;
+  * **a room is not a person**: an allowed room is never sufficient — the speaker must
+    also be individually trusted, where 0.1.0 returned `true` for every member of an
+    allowed room whenever `allowContacts` was empty;
+  * revocation exists, which 0.1.0 had no way to do short of deleting its state file;
+  * `CHANNELS` is **one** registry. The same information lived in four places that had to
+    agree, and a channel missing from the authorisation regexes had every message from it
+    silently dropped;
+  * a well-formed key naming an unenabled channel is a **named** refusal
+    (`channel_unknown`), because a silent drop is indistinguishable from a bot that is
+    simply broken.
+* `test/chatops-approval.test.mjs` (24 cases) and `test/chatops-policy.test.mjs`
+  (24 cases), both wired into `test` and `test:all`.
+
+### Not in this release
+
+* **Only one channel adapter ships, and it is the WeChat one.** `ilink.mjs` is here because
+  its protocol is JSON over HTTPS with no vendor SDK — the other three channels need SDKs
+  this project cannot vendor or review. Feishu, DingTalk and WeCom are not implemented; the
+  channel contract they must satisfy is `channel.mjs`, checked by the same validator `ilink`
+  passes.
+* **Nothing has been exercised against a live WeChat account.** The adapter's whole network
+  surface is one injected `request()`, so its request shaping, response mapping,
+  de-duplication, state machine and host allow-list are all asserted — 30 cases. What that
+  suite cannot tell you is whether WeChat accepts the requests. That needs a QR scan and a
+  real bot, and is not claimed.
+* The audit's own limits: the chatops dependency trees were not resolved (no `node_modules`
+  was installed, and none of its code was executed), and its Feishu card-action signature path
+  lives inside a vendor SDK that was not available to read.
+
+### Note on the other half of the work
+
+The three-machine comparison this fleet exists for still needs one commit that all
+three machines can reach. The Mac runs the project at `a1e7dc04` on a clean tree with
+`--project /Users/fang/w2m-project` — already correct, and already the same path its own
+DSH uses; the mismatch is that this is not the commit the Windows host and the Tokyo
+relay are on. Its `git ls-remote` to GitHub times out while `curl api.github.com`
+answers 200, so the reachable common anchor is `origin/main` (`6e7ba0c9`, the v0.6.3
+tag) rather than the fixture commit used for the local runs.
+
 ## [0.6.3] — 2026-10-13
 
 One fix, and it is the half of v0.6.2 that made the other half usable.