diff --git a/.claude/skills/hq-diagnose/SKILL.md b/.claude/skills/hq-diagnose/SKILL.md
index 46a195d7..d30b3d90 100644
--- a/.claude/skills/hq-diagnose/SKILL.md
+++ b/.claude/skills/hq-diagnose/SKILL.md
@@ -25,7 +25,7 @@ result is not "nothing to learn" — it is the reason the next person repeats th
 
 1. Read the issue: `mesh_call issue-tracker.get` with its number, and `00-report.md` when it has a
    folder. Before you start, move it to `diagnosing` with `issue-tracker.move` and `by`, your name and node as
-   who@node (such as `fix-399@g14`). The tracker refuses it while another worker is current, naming them.
+   who@node (such as `fix-399@laptop`). The tracker refuses it while another worker is current, naming them.
 2. Investigate. The trail goes in `issue-tracker.note`, **dated** in its text, including what was
    ruled out and how; for an issue with a folder, in `01-diagnosis.md` there as well. Archaeology —
    which commit, which pull request, which date a behaviour changed — is the most valuable content.
diff --git a/00-META/process/03-issues.md b/00-META/process/03-issues.md
index 677e36a9..f86f40ff 100644
--- a/00-META/process/03-issues.md
+++ b/00-META/process/03-issues.md
@@ -72,7 +72,7 @@ import read, which every imported issue names (`imported.commit` in `issue-track
 
    **An issue wholly in the tracker** is done at this step.
 2. Investigate. **Before you start, move the issue to `diagnosing` with `by`**: who works on it and its node, as
-   who@node (`fix-399@g14`, `jochen@shanks`). The tracker keeps you as the issue's **worker**, and `get` and `list`
+   who@node (`fix-399@laptop`, `operator@workstation`). The tracker keeps you as the issue's **worker**, and `get` and `list`
    show it with since when. The trail goes in `issue-tracker.note`, and, for a folder-backed issue, in
    `01-diagnosis.md` in the same folder as well — dated, including what was ruled out. A note keeps you the worker; a
    worker with nothing done on the issue for a day is stale. Then move it to `located` with `located-in`, which the
diff --git a/02-DECISIONS/0283-an-agent-moves-an-issue-to-fixing-under-its-own-name-and-an-issue-is-resolved-only-from-fixing.md b/02-DECISIONS/0283-an-agent-moves-an-issue-to-fixing-under-its-own-name-and-an-issue-is-resolved-only-from-fixing.md
index 9e80cc2d..3aef27a0 100644
--- a/02-DECISIONS/0283-an-agent-moves-an-issue-to-fixing-under-its-own-name-and-an-issue-is-resolved-only-from-fixing.md
+++ b/02-DECISIONS/0283-an-agent-moves-an-issue-to-fixing-under-its-own-name-and-an-issue-is-resolved-only-from-fixing.md
@@ -75,7 +75,7 @@ fix. `wontfix` is unchanged: it is reached from any status, with a reason.
 ### 2. A move to diagnosing or fixing names its worker
 
 A move to `diagnosing` or `fixing` needs `by`: the issue's **worker**, the agent or person who works on it and the
-node it works on, written as who@node (`fix-399@g14`, `jochen@shanks`). These are the limits:
+node it works on, written as who@node (`fix-399@laptop`, `operator@workstation`). These are the limits:
 
 - `who` is letters, digits and `.`, `_`, `/`, `-`;
 - `node` is lower-case letters, digits and `-`;
@@ -145,7 +145,7 @@ warrant ([ADR 0274](0274-an-agent-proposes-a-shared-instruction-section-and-ever
 - A worker that stops without moving the issue on keeps others out for up to 24 hours, unless they give a reason.
   The reason is on the issue for the operator to read.
 - The next step is that an alert names the issue tracking its condition and that issue's state in plain words, such
-  as "an agent on g14 is fixing it since 21:10". That needs a link from an issue to a condition key or kind, and is
+  as "an agent on the laptop is fixing it since 21:10". That needs a link from an issue to a condition key or kind, and is
   tracked by issue 400. This record makes the worker readable for it, from `get` and from the `moved` event.
 
 ## How it is checked