@north-light/cli 0.0.0-stage → 0.3.413

package/dist/builtin-memory/internal/marketplaces.md

@@ -0,0 +1,160 @@
+---
+kind: knowledge
+when-and-why-to-read: When creating a crtr marketplace or contributing plugins to one, this knowledge should be read so indexed plugins install and update coherently without release automation desynchronizing their versions.
+short-form: How to author a crtr marketplace — marketplace.json index, plugin entries, symlink-based install, auto-bump CI, dual-publishing. Use when creating a marketplace or contributing plugins to one.
+surfaces:
+  - on: boot
+    at: name
+---
+
+# Authoring crtr marketplaces
+
+A **marketplace** is a git repo that indexes multiple plugins. Users register it once, then `crtr pkg plugin install <mkt>/<plugin>` symlinks any plugin from it. `crtr pkg market update --name <mkt>` pulls updates for every installed plugin at once.
+
+Audience: LLM agents creating a marketplace or adding plugins to an existing one.
+
+## When you need a marketplace (vs a single-plugin repo)
+
+A solo plugin ships from any git URL via `crtr pkg plugin install <url> --scope user` — no marketplace needed.
+
+Reach for a marketplace when:
+- You want to publish ≥3 plugins under one brand or theme.
+- Users should install selectively without cloning each plugin's repo.
+- You want centralized version-bump automation across many plugins.
+
+If you have one plugin, ship it standalone. Promote to a marketplace later.
+
+## Directory layout
+
+```
+<marketplace-repo>/
+├── .crouter-marketplace/
+│   └── marketplace.json              # marketplace manifest — required
+└── plugins/
+    ├── plugin-a/
+    │   ├── .crouter-plugin/plugin.json
+    │   └── memory/...
+    └── plugin-b/
+        └── ...
+```
+
+A marketplace can keep a plugin under `plugins/` or index a plugin from another Git repository. Local entries are complete plugins (see [[internal/plugins]]); the marketplace adds an index over either source.
+
+## The manifest
+
+`.crouter-marketplace/marketplace.json`:
+
+```json
+{
+  "name": "my-marketplace",
+  "version": "0.3.0",
+  "owner": { "name": "Your Name", "email": "you@example.com" },
+  "plugins": [
+    {
+      "name": "plugin-a",
+      "version": "0.2.1",
+      "source": "https://github.com/<owner>/<repo>",
+      "description": "One sentence."
+    },
+    { "name": "plugin-b", "version": "0.1.0", "source": "…", "description": "…" }
+  ]
+}
+```
+
+| Field | Required | Notes |
+|---|---|---|
+| `name` | yes | Lowercase kebab. |
+| `version` | yes | Semver. Bumps when any plugin bumps or when the marketplace manifest itself changes. |
+| `owner` | optional | |
+| `plugins` | yes | Array. Each entry: `name`, `version`, `source`, `description`. |
+
+The `plugins[]` array IS the index — what's installable. Each entry's `source` is either a marketplace-relative path to a plugin directory or a remote Git URL. A local plugin on disk but not in the index won't resolve; an indexed local path missing from the marketplace errors on install.
+
+## Install mechanics — local links and remote clones
+
+When a user runs `crtr pkg plugin install my-marketplace/plugin-a`, crouter looks up `plugin-a` in the marketplace manifest and records the install with `source_marketplace: my-marketplace`.
+
+- A marketplace-relative `source` is symlinked from the marketplace checkout into the target scope, so `crtr pkg market update --name my-marketplace` updates its content through that checkout.
+- A remote Git `source` is cloned into the target scope. Marketplace update refreshes the index; the installed plugin's own checkout is pulled during that update (or `crtr pkg plugin update`).
+
+No per-plugin re-install is needed for content updates while the indexed source remains unchanged. Changing a remote entry's `source` requires removing and reinstalling that marketplace plugin so its checkout uses the new remote.
+
+## Version-bump automation (recommended)
+
+Bumping N plugin manifests + the index by hand is error-prone. The canonical pattern is a GitHub Actions workflow that bumps versions from commit subjects (conventional commits):
+
+| Commit subject | Bump |
+|---|---|
+| `feat!: …` or `BREAKING CHANGE` in body | major |
+| `feat: …` | minor |
+| anything else (`fix:`, `chore:`, `docs:`, …) | patch |
+
+Per commit:
+- For each plugin folder touched, both `plugins/<name>/.crouter-plugin/plugin.json` and the matching entry in `marketplace.json` get bumped.
+- Top-level `marketplace.json` version bumps when any plugin bumps OR the manifest itself was edited directly.
+- Newly-added plugins are skipped — they keep the version you committed.
+- Commits whose subject starts with `chore: release` are skipped to avoid loops.
+
+If you adopt this: **never edit `version` fields by hand**. CI will overwrite. Document this in the marketplace's CLAUDE.md.
+
+The crouter-official-marketplace repo's `.github/workflows/auto-bump.yml` is the reference implementation. Copy it.
+
+## Adding a plugin to a marketplace
+
+```bash
+cd <marketplace-repo>
+
+# Create the plugin (see [[internal/plugins]] for plugin layout)
+mkdir -p plugins/my-new-plugin/.crouter-plugin plugins/my-new-plugin/memory
+$EDITOR plugins/my-new-plugin/.crouter-plugin/plugin.json
+
+# Add at least one doc (`crtr doc write -h` is the field + delivery-rule guide)
+$EDITOR plugins/my-new-plugin/memory/first-doc.md
+
+# Add the plugin to the marketplace index
+$EDITOR .crouter-marketplace/marketplace.json
+# (append to plugins[] with name, initial version, source, description)
+
+# Validate
+crtr sys doctor                                    # manifest + structure
+crtr doc lint                                      # document fields and links
+
+# Commit — CI bumps versions if you've wired up auto-bump
+git add -A
+git commit -m "feat: add my-new-plugin"
+git push
+```
+
+Existing users pick it up on their next `crtr pkg market update --name <marketplace-name>` (or on the next auto-update tick if they've set `auto_update.content: "apply"`).
+
+## Updating an existing plugin
+
+For a local plugin, edit `plugins/<name>/` and commit the plugin plus marketplace index together. For a remote Git source, update the plugin in its own repository, then update the marketplace entry's version as needed. If its `source` changes, users remove and reinstall the marketplace plugin to clone the replacement remote. Commit with a conventional-commit subject; CI can bump the marketplace index alongside local plugin changes.
+
+## Removing a plugin
+
+Delete the entry in `marketplace.json` → `plugins[]`; also delete its directory when it is a local source. Commit with `feat!: remove <plugin>` to signal a major bump (the marketplace's contract changed for anyone depending on that plugin).
+
+## Marketplace registration scopes
+
+A marketplace itself registers per-scope:
+
+| Scope | Path | Use case |
+|---|---|---|
+| user | `~/.crouter/marketplaces/<name>/` | Private to your machine — your personal subscriptions |
+| project | `<project>/.crouter/marketplaces/<name>/` | Checked into the repo — anyone cloning gets the same marketplace pinned |
+
+`crtr pkg market add <git-url> --scope user` is the default. Use `--scope project` when the marketplace is integral to how the repo expects to be developed.
+
+## Validation
+
+`crtr sys doctor` checks marketplaces:
+- `marketplace.json` is valid JSON.
+- Every marketplace-relative entry in `plugins[]` resolves to a real local plugin directory. Remote-source validation occurs when crouter installs that plugin.
+- Each installed plugin passes plugin-level validation.
+
+A local plugin on disk but missing from the manifest is a **warning** (probably forgotten); an indexed local path missing on disk is an **error** (install would break).
+
+## Cross-publishing with Claude Code
+
+Some marketplaces ship a parallel `.claude-plugin/` tree so plugins can load directly into Claude Code without crtr. Optional. Sync the two manifests if you adopt it.

package/dist/builtin-memory/internal/memory-loading.md

@@ -0,0 +1,68 @@
+---
+kind: knowledge
+when-and-why-to-read: When you need to know why a document did or didn't load — or are deciding how a new document should be delivered — this reference should be read because it names the event, delivery level, `if` condition, and ordering that produced the behavior, so you fix loading by turning the right dial instead of guessing at fields.
+short-form: How documents load into a node — the delivery events, `deliver` levels, `if` conditions, listings, the exposure ledger, boot-render ordering, and the reader's view.
+surfaces:
+  - on: boot
+    at: name
+---
+
+# How documents load
+
+A document is an object on the canvas ([[internal]] has the model): it has an owner, a privacy level and a name, and any node that may read it can `crtr canvas read` it. Whether it also *loads on its own* — into a node's boot context, when a file is read, when a command runs — is decided only by the document's **rules**; the runtime never guesses. A rule is one `on` event, one `deliver` level and one optional `if`, plus structural ordering. The writing contract (flags, preview craft) is `crtr doc write -h` and its focused `crtr doc write --rule -h`; which owner to write under is `internal/agent-shaping`; where state lives is `internal/storage-tiers`. This document is the mechanics between those: what actually fires, when, and in what order.
+
+(In a package file — a builtin or plugin `memory/*.md` — rules are authored in the package-file frontmatter (`surfaces`, `gate`, `slash`) and converted into these rules on import; see `internal/plugins`. Everything below describes the converted rules.)
+
+## Delivery rules
+
+A document with no rules does exactly one thing: appears in the listing of the names above it. Everything beyond that is an explicit rule — in `--rule` JSON, `{"on": <event>, "match"?, "match_frontmatter"?, "if"?, "deliver": <level>}` (package frontmatter spells the key `match-frontmatter`). A rule's event constraints and optional `if` over the receiving node must both match; matching rules OR across and fold to their highest delivery (`content` > `preview` > `name`), with no cross-rule deny precedence. Multiple rules per event are legal. The events:
+
+- **boot** — the frozen preference system snapshot and first-message knowledge catalog assembled when a context begins. No match; the rule's presence is the match.
+- **workspace-open** — first-message context when the node works in the repo that owns the document. Repo-owned documents only.
+- **file-read** — a `read` tool call returned a matching file: path globs vs the file's absolute path and basename, `./`-anchored globs vs its path relative to the owning repo's checkout, `match_frontmatter` predicates over the read file's own YAML frontmatter.
+- **document-read** — another document's full body entered context, including `crtr canvas read`: name globs vs its name, `./` anchored to this document's own name.
+- **command** — a matching shell command ran: globs vs the whole command string, `*` crossing `/`. Delivery is post-execution — right for "you are now in this territory"; when the point is "don't run this at all," use `pre-command` instead.
+- **pre-command** — a matching `bash` command is about to run. When the document has not been read yet, the command does not execute — the document comes back as the tool result instead, and the agent re-issues the command, which then runs. Use it to guarantee a document is seen before a sensitive action is taken. Same globs as `command`, matched at command position; `match` is required. A guardrail against the faithful-but-uninformed action, not an enforcement boundary.
+- **slash-command** — the document is offered as a slash command in the viewer; invoking it delivers its content.
+
+Nothing positional fires from where a document's name sits — only from its declared rules and its listing.
+
+## Delivery levels
+
+`deliver` sets how much delivers when a rule fires:
+
+- `name` — the bare title. The practical boot floor: an agent can't reach for a document it has never seen named.
+- `preview` — name + the `preview` line, rendered verbatim. The heart of progressive disclosure: one sentence that lets an agent decide whether to spend the read.
+- `content` — the full body inlined. Reserved for always-relevant documents that are either a bullet's worth of text or a wholly-important operating guide (the workspace front door below).
+
+Silence is the absence of a rule; there is no `none` level. `summary` is **not** a level and never enters agent context — it exists for listings and search results. Disclosure is name → preview → whole thing; there is deliberately no "just the summary" level, because agents satisfice on abbreviations and never read the rest.
+
+## Conditions
+
+A rule's `if` is the eligibility predicate over the receiving node — kind, mode, lifecycle, orchestration depth, cwd, the repo it works in, profile — using the standard matcher vocabulary (`crtr doc write --rule -h`). When it fails, that rule delivers nothing; there is no document-level condition, so one document can choose a different level by node kind with two rules. No `if` means always eligible. Persona prose is just boot-content documents with an `if` (`if: {kind: developer, mode: base}`); guidance that should scale with effort is one predicate (`orchestration.depth: {gte: 2}`), not a mechanism.
+
+## Listings and dedup
+
+A full-body delivery is a read: `crtr canvas read <name>` and every content delivery expose, once per loaded context, the listing of each prefix of the document's name — one preview per document, one bare name per prefix that has names under it — then fire matching `document-read` rules. A document named `x` and documents named `x/…` coexist; reading `x` prints its body alone to stdout and delivers one listing of the names under it and the documents its body links to after command output in the node's tool result — previews only, not reads, never recursing. Content-delivered companions are read in turn until nothing new is delivered. `unlisted: true` suppresses a document from every listing. An owner's top level is never auto-listed — `crtr canvas list --type document` is the deliberate browse. Every content delivery, like every read, records a watch, so later edits reach the reader as pushes.
+
+Every delivery registers the document or listing and its level in the loaded context's exposure ledger, kept in canvas.db. System and transcript ranks max-fold, so a higher level pierces a lower one while a content delivery silences later lower-level deliveries and duplicate read attachments. A strict resume preserves that ledger and the byte-stable preference snapshot; yield or another new-session boundary clears it and replaces them with exactly the new system and first-message snapshots.
+
+## The reader's view
+
+A rule applies to every node whose view includes the document's owner. A node's view is: its own node, the repos it works in (nearest first), its profile, its app, the user, and installed plugins (each an app that owns its shipped documents), with crtr's own documents (owned by the app `crtr`) last. A bare name resolves in that same order, which is what lets a repo's document shadow one of crtr's own. A node's own documents are in no other node's view, so their rules apply only to that node.
+
+Each owner the selected profile manages carries a delivery limit — `none`, `name`, `preview`, or `content` — and that value is the maximum level anything that owner holds delivers at `boot` and `workspace-open`, whatever directory the node is working in. It only lowers: a rule authored below the maximum delivers at its authored level. `none` contributes nothing to either automatic event, so a `none` owner cannot shadow a same-named document from a wider owner — that wider document becomes the winner. An owner with no limit set delivers exactly what it authored.
+
+A limit is keyed by owner handle. A bare key (`crouter`) matches an owner of any type holding that handle, and handles are unique per type, not across types — so a repo and a profile can both be `crouter`. `<type>:<handle>` (`repo:crouter`, `profile:work`, `app:terminal`, `person:user`; the typed form `resolveName` accepts) names one owner exactly and wins over a bare key. A node's own documents and its own profile's documents are never capped, whichever key matches.
+
+The limit reaches those two events and nothing else. `file-read`, `document-read`, `command`, and `pre-command` rules fire at their authored levels; listings, `crtr canvas read`, `crtr canvas search`, config resolution, and plugin discovery all see every document the reader may read. An explicit `crtr canvas read` is itself a content delivery, so reading a capped document returns its whole body and records content — the upgrade path for a document the automatic events disclosed only by name or preview. `if` conditions apply to companion documents delivered by the `document-read` event, not to the deliberate read or its listings.
+
+A workspace's front door is an ordinary repo-owned document carrying the rule pair `{on: workspace-open, deliver: content}` + `{on: file-read, match: "./**", deliver: content}` — the operating guide loads when a node works in that repo or reads its files, not in every boot catalog. `crtr doc lint` requires exactly one `workspace-open` content document per repo the profile manages. Several repos render broad-to-specific.
+
+A repo's documents about one package or subsystem are named under its folder (for example `packages/api/…`) and keep their `file-read` rules: reading any file beneath that folder delivers them, filtered against what the loaded context already contains.
+
+## Ordering
+
+The boot render is structural, never a per-document knob: documents group by boot level (content bodies as prose, then previews, then names), and within a group order general-to-specific — owner first (crtr → user → profile → outermost repo → nearest), then name depth (shorter names before deeper ones), then name. A numeric `NN-` prefix (stripped from the document's name) is the sparing escape hatch when an exact sequence must be pinned.
+
+`crtr doc lint` is the validator for the rest: body length for its delivery, the preview's shape when a rule delivers it at `preview`, links to nothing, and one `workspace-open` content document per repo the profile manages.

package/dist/builtin-memory/internal/nodes-and-canvas.md

@@ -0,0 +1,60 @@
+---
+kind: knowledge
+when-and-why-to-read: When you are operating the canvas — spawning or steering nodes, deciding how work reports up, recovering a dormant or crashed node, or reasoning about the daemon — this reference should be read so lifecycle and reporting operations preserve one live engine, deliver results reliably, and recover nodes without corrupting state.
+short-form: Operational model of the agent runtime — nodes as objects on the canvas graph, spawn/delegate, the push/feed spine and watches, lifecycle states, and revive (manual + daemon auto-revive).
+surfaces:
+  - on: boot
+    at: name
+---
+
+# How nodes and the canvas work (operational)
+
+Every agent is a **node**, one kind of **object** on the **canvas** — the single graph that also holds documents, bash jobs, owners (person, app, repo, profile) and custom objects (the model is in [[internal]]). A node is an object with an id, its status and a persona kind; it owns the documents it writes (named `<node-id>/<name>`, including its reports), has a context directory for scripts, data and logs, and runs as one detached headless broker engine; tmux panes are only viewer surfaces that attach to a broker. Nodes are read and found like any object (`crtr canvas read|list|search <node>`), and `crtr canvas edges` shows `acted-on`, `links-to` and `watches` edges.
+
+The node-to-node **spine** is the subscription edge: a subscriber receives its publisher's pushes (`node subscription add|remove`, stored as a watch the subscriber holds on the publisher), and that edge decides who-wakes-whom. It sits beside the general watch mechanism below, which lets any object's events reach any node.
+
+The **daemon** (`crtrd`) is the sole owner of canvas persistent state: it is the only process that opens `canvas.db`, launches brokers, and writes runtime/model-auth, all behind an HTTP+WS API on a unix socket (dockerd model). Every `crtr` command and viewer is a pure client of that `/v1` API — they never open the store. A local interactive viewer still streams a node's broker socket (`view.sock`) directly, because that is broker IPC, not canvas state.
+
+## Spawn & delegate
+
+`crtr node new "<task>" --kind <kind>` launches a managed child broker and returns its id immediately; you **auto-subscribe** to it, so its finish wakes you. A base node works hands-on and only spawns a child for a cleanly separable unit. An orchestrator delegates its decomposed work by default: a child's reading and tokens land in a fresh context window while the coordinator keeps only the conclusions needed to steer.
+
+- Match `--kind` to the work (`explore spec design plan developer review general`, plus any custom persona). See `node new -h`.
+- An orchestrator fans **independent** units out concurrently. Serialize only true dependencies; never let two live children edit the same files.
+- `--root` spawns an independent node you neither manage nor are woken by (e.g. one the user will drive).
+- Once you delegate a unit, don't also run it yourself — you'll be woken when it finishes.
+
+Navigate/steer: `surface node focus` (put an attach viewer for a node in your pane), `surface attach` (connect to a node's existing broker), `surface node cycle` (DFS-walk neighbors), `surface node id` (copy the current node id), `node message send` (direct-message any node at a wake tier, reviving a dormant target), `node subscription add`/`node subscription remove` (wire edges spawn didn't create). Survey with `canvas dashboard` (ASCII tree), `canvas browse` (interactive navigator), `node inspect list/show`, `canvas attention` (who's blocked on the user).
+
+## Watches — how events reach a node
+
+Every object emits events, each with a level (1–10), and a **watch** routes an object's events to a watcher. Reading an object, writing or editing a document, messaging a node, spawning a node or starting a job makes you a watcher of it, so a document you read can steer you when it is edited and a child you spawn wakes you when it finishes. The watcher's listening configuration decides how an event arrives — interrupt, steer, after the current turn, or at the next turn — by level (by default 10 interrupts, 7–9 steer, 5–6 wait for the turn to end, 3–4 wait for the next turn). `crtr canvas watch <name> [--pattern … --listen …]` adds a watch without reading; `crtr canvas unwatch <name>` removes one — do it when an object no longer bears on your work so its events stop arriving. `crtr canvas edges <your id> --type watches --direction out` lists everything you watch. Node events include `report.update`/`report.final` (from `push`), `messaged`, and `notice.crash`/`close`; a job emits `exited`/`killed`; a document emits `edited`/`deleted`.
+
+**Jobs** are backgrounded bash commands, objects of type `job` that you watch from the start; `crtr canvas read <job>` shows command, status, exit code and log path. **Custom objects** (`crtr custom-object register`) let an outside service or script publish declared events to watchers on the canvas, with a queue, URL or argv receiver for events it watches in turn; see `crtr custom-object -h`.
+
+## The push/feed spine
+
+Nothing is reported automatically — the feed contains only what a node **pushes**.
+
+- `push update` — routine progress; delivers to subscribers without forcing a wake.
+- `push update --tier urgent` — force-wakes every subscriber (you're blocked, scope changed, an error derails the plan).
+- `push final` — the ONLY way a terminal node finishes: writes the canonical result as a report, marks the node done, and tears down its broker. Stopping without it is not finishing. Resident/user-facing nodes stay dormant instead of finishing unless explicitly forced.
+
+A push writes a **report document** the node owns, named `<node-id>/reports/<timestamp>-<id>-<kind>`, and delivers a pointer to each subscriber; a body under 1,000 characters is inlined, a longer one is read with `crtr canvas read <name>`. When a subscriber push wakes you, **the wake message already IS the coalesced digest** — read the reports that matter rather than trying to re-read the digest. An empty feed while workers run is normal — a worker that hasn't pushed yet leaves no pointer; the wake it fires when it does push is automatic, so there's nothing to poll or check in the meantime.
+
+## Lifecycle
+
+Two orthogonal axes:
+
+- **mode**: base (a hands-on worker — finishes its own job, yielding mode-preservingly when a task needs another window) ↔ orchestrator (`node promote` — a long-lived, roadmap-holding coordinator that delegates independent work and survives context refresh via `node yield`). Promote only when worthwhile parallel work makes coordinating and integrating children the node's primary job; task duration, sequential phases, or one helper are not enough.
+- **lifecycle**: terminal (owes a final up the spine, reaps when done) ↔ resident (`node config --lifecycle <value>` / interactable — never forced to submit; stays wakeable while attached or awaiting something live, then completes after 15 unattended minutes with no live obligation). `node lifecycle demote` is the friendly flip-to-terminal-in-place.
+
+A dormant node wakes from an **inbox** message (a push, or `node message send`) or from a scheduled **cron** whose bash command performs the action (`node message send`, `node lifecycle revive`, or `node new`). A cron can gate its action on an external condition such as CI or a deploy; inspect or reap schedules with `cron list`/`cron cancel`. To monitor your own children you arm nothing — you auto-subscribe on spawn, so their finish/crash/close wakes you; a deadline to chase a delegate is a belt-and-suspenders the runtime makes redundant. A terminal node blocked on a one-off message from a parent or controller it holds no live subscription to declares that wait with `node wait controller` before going dormant, so the next inbox delivery from that sender clears the wait rather than the runtime treating the idle as finished. Use `node wait deadline` only for the atomic inbox-versus-deadline race.
+
+Tear-down: `node lifecycle close` cascade-cancels a node + its exclusive subtree WITHOUT finishing (revivable, nothing deleted); `node lifecycle recycle` finishes the agent in your pane and reboots a fresh root in place; `canvas prune` deletes terminal nodes past a TTL.
+
+## Revive & the daemon
+
+Use `node lifecycle revive <id>` to reopen one dormant or terminal node. It resumes an existing saved conversation by default; `--fresh` starts a new cycle on its existing session file, or a truly fresh session if no file exists. A finalized node requires `--reopen` before it can take a new mandate. Mass-reconnecting every eligible disconnected node after a reboot or outage is `canvas revive --all` instead. `reviveNode()` is the **only** sanctioned launcher of a node's broker engine — it builds the pi invocation, sets `CRTR_NODE_ID` + canvas extensions, runs `transition('revive')`, and starts the headless broker host, keeping the db row and broker process in lockstep. Never spawn `pi --session` raw, and never open a node by spawning pi directly — UIs go through `surface node focus` / `node lifecycle revive`.
+
+The daemon (`crtrd`, managed via `sys daemon start/stop/status`) supervises live broker exits. It releases an unattended broker after 15 minutes: residents with no live obligation become `done` and pruning-eligible, while terminal nodes and residents awaiting a live child, controller, human, deadline, or structured output become `idle` and remain wakeable. It applies a bounded respawn policy to interrupted nonterminal nodes: an interrupted saved turn resumes in the same conversation with a continuation, whether the broker persisted a clean abort or died abruptly. A pending refresh or pending cycle still starts a fresh cycle from the saved session. Repeated short-lived exits and boot failures terminalize the node as `dead`; no automatic recovery occurs after terminalization, so use an explicit lifecycle revive or an inbox wake. It does not host agents or open viewers. When activating source changes, build, run `npm run install-runtime`, then restart the daemon because new daemon/brokers select the atomically switched, immutable generation while live brokers retain their own. Restarting is safe: it never signals running nodes.