@execuro-sw-ecosystem/sw-ecosystem-agentic-harness 0.1.3 → 0.1.5

package/CHANGELOG.md

@@ -7,6 +7,32 @@ release.
 
 ## [Unreleased]
 
+## [0.1.5] - 2026-09-17
+
+### Fixed
+
+- **`install`/`apply` no longer write into every detected host when
+  `--host` is omitted.** They now resolve which host(s) to use in order:
+  `--host` if given; else the hosts a lock file already records; else an
+  interactive picker when a terminal is attached; else exit 2 naming the
+  four `install --host <h>` commands as `help`, instead of silently
+  defaulting to Claude Code, Codex, Copilot *and* Cursor. `status` and
+  `uninstall` keep covering every host by default, and `plan` previews all
+  four and says so when nothing was selected.
+
+## [0.1.4] - 2026-09-17
+
+### Added
+
+- **`sw-setup` gained a twelfth readiness row, "Package updates".** It checks
+  whether the harness, the Specs Editor and the Tender Discovery Tool are at
+  their target versions (the harness at npm's latest, each editor at its own
+  `extra_components[].version` pin, never npm's latest) via three
+  `npm view` lookups, each with a 10-second timeout — a failed or timed-out
+  lookup reports "could not check" rather than failing the row. Folds into
+  step 3's single question; never blocks readiness. The KB MCP keeps its
+  existing row (registered as `@latest`, nothing to update).
+
 ## [0.1.3] - 2026-09-17
 
 ### Changed

package/README.md

@@ -49,18 +49,26 @@ declines is fully set up without them, and `--editor` on `sw-design-requirements
 
 | Command | What it does |
 | --- | --- |
-| `install` | installs into every detected host; the same as `apply --yes` |
+| `install` | installs into the resolved host(s) (see Flags below); the same as `apply --yes` |
 | `status` | read-only; what is installed, what drifted, which optional extra components are present |
 | `plan` | the exact changes, written as a diff; writes nothing |
 | `apply --yes` | performs them |
 | `uninstall --yes` | removes what the lock file records |
 | `guide` | the install protocol, the single source of truth |
 
-Flags: `--host claude-code|codex|copilot|cursor` (repeatable; omitting it
-selects every host that is present), `--scope project|user` (default
-`project`), `--root <path>` (default the current directory), `--yes` (required
-by `apply` and `uninstall`, never prompts — `install` implies it), and
-`--no-extra-components` (skip detection of the optional editor packages).
+Flags: `--host claude-code|codex|copilot|cursor` (repeatable), `--scope
+project|user` (default `project`), `--root <path>` (default the current
+directory), `--yes` (required by `apply` and `uninstall` — `install` implies
+it), and `--no-extra-components` (skip detection of the optional editor
+packages).
+
+`install`/`apply` resolve which host(s) to write into, in order: `--host` if
+given; else the hosts a lock file already records (a re-run needs no
+question); else, with a terminal attached, an interactive picker; else exit 2
+with the four `install --host <h>` commands as `help` — it never guesses and
+never hangs. `status` and `uninstall` are unaffected by this and keep
+covering every host by default; `plan` writes nothing, so with no `--host` and
+no lock it previews all four and says so.
 
 ## Install
 
@@ -74,11 +82,14 @@ writes anything.
 Then restart your coding agent — every host reads its configuration at startup.
 The command's output tells you which ones and how.
 
-`apply` refuses without `--yes` and never prompts: Codex's question tool does
-not block outside Plan mode, and CI has no terminal. Add `--host claude-code`
-(repeatable) to install into one agent, and `--scope user` to install into your
-home directory instead of this repository. The default scope is the project —
-nothing is written under `~` unless you ask.
+`apply` refuses without `--yes`. Neither `apply` nor `install` prompts for
+consent — typing the verb, or passing `--yes`, is the consent — but with no
+`--host`, no existing lock and no terminal (Codex's question tool does not
+block outside Plan mode, and CI has no terminal either), it exits 2 rather
+than guess. Add `--host claude-code` (repeatable) to install into one agent,
+and `--scope user` to install into your home directory instead of this
+repository. The default scope is the project — nothing is written under `~`
+unless you ask.
 
 ### What it writes
 

package/bin/cli.mjs

@@ -36,10 +36,15 @@ const USAGE = `usage: sw-ecosystem-agentic-harness <command> [options]
   guide      print the install protocol
 
   install is apply --yes under a friendlier name: the whole install in one
-  command, no --yes needed — typing the verb is the consent.
+  command, no --yes needed — typing the verb is the consent for that write;
+  it can still ask which host(s), see below.
 
   <h> is one of: claude-code, codex, copilot, cursor. Repeat --host to select
-  several; omitting it selects every host that is present.
+  several. install/apply resolve which host(s) to use, in order: --host if
+  given; else the hosts already recorded in the lock file, if one exists;
+  else, with a terminal attached, an interactive picker; else exit 2 with
+  the four "... install --host <h>" commands as help. status and uninstall
+  keep covering every host by default.
 
   --scope defaults to project: nothing is written under your home directory
   unless you ask for it. --root defaults to the current directory.

package/content/AGENTS.md

@@ -16,7 +16,7 @@ procedure, and the detail lives in `reference/*.md` files beside its
 | `sw-discover-tender` | Analyse a client tender (RFP, RFI or RFQ) for a Shopware 6 project into one markdown sidecar, <source basename>-analysis.md. |
 | `sw-document-feature` | Document one Shopware project feature into the LLM-wiki under docs/project-wiki/ — one feature page per surface (administration/ and/or storefront/), the "why" row in the domain index, ADR pages only promoted from the WIP ADR files sw-design-solution extracted into specs/ once they are accepted and built (with an organised table of contents) or provided by the user (never invented). |
 | `sw-implement-feature` | Implement a feature from its technical spec (specs/NNNN-slug-spec.md, written by sw-design-solution) following TDD — tests first per acceptance criterion, then the implementation, fixing until every relevant test passes (including that AC's own acceptance/e2e test, run immediately, not deferred), running Shopware's own shopware-cli fixers/static-analysis per AC to conform to Shopware's coding standards as code is written rather than after the fact. |
-| `sw-setup` | Print one environment-readiness table for the project's development/test setup — vendor/, Node, the editor CLIs, shopware-cli, the KB MCP, the acceptance-test project, Playwright browsers, its .env, per-plugin test scaffolding, the project wiki and `.gitignore`, plus the installer CLI's own configuration/drift status. |
+| `sw-setup` | Print one environment-readiness table for the project's development/test setup — vendor/, Node, the editor CLIs, shopware-cli, the KB MCP, the acceptance-test project, Playwright browsers, its .env, per-plugin test scaffolding, the project wiki, `.gitignore` and whether the SW AH npm packages are current, plus the installer CLI's own configuration/drift status. |
 | `sw-verify-feature` | Verify a feature implementation against its technical spec (specs/NNNN-slug-spec.md) by running three independent verifiers in parallel — AC test coverage/health, architecture/guideline compliance, and code quality/static analysis — then cross-checking their verdicts into one final per-AC pass/not pass/partly report. |
 | `sw-verify-feature-ac-tests` | Verify that a feature's acceptance criteria are backed by tests that actually exist, actually pass, and actually test what their name/comment/PHPDoc claims. |
 | `sw-verify-feature-architecture` | Verify that a feature's implementation matches the architectural decisions its spec made, and complies with Shopware's own Core conventions plus any written Project guidelines this repo defines. |

package/lib/commands.mjs

@@ -15,6 +15,7 @@ import { HOSTS, buildPlan, detectAll, installedCounts } from './hosts.mjs';
 import * as lockfile from './lock.mjs';
 import { dedupe, execute, isWritableState, preview, pruneDirs, revert } from './actions.mjs';
 import { probeAll } from './extra-components.mjs';
+import { askHosts } from './prompt.mjs';
 
 const RUN = 'sw-ecosystem-agentic-harness';
 
@@ -65,13 +66,49 @@ export function buildContext(argv, command) {
 
   return {
     root, scope, yes, projectWiki, extraComponents,
-    hosts: hosts.length ? [...new Set(hosts)] : [...HOSTS],
+    // Empty means "nothing chosen yet" — resolveHosts() applies the
+    // per-command fallback once the lock (and, for apply/install, a TTY)
+    // is available to consult.
+    hosts: [...new Set(hosts)],
     platform: process.platform,
     version: PKG_VERSION,
     lock: null,
   };
 }
 
+/**
+ * The host-resolution chain every write command shares:
+ *   1. `--host` given → use exactly those. No question.
+ *   2. else a lock already records hosts → reuse them. This is an update;
+ *      the choice was already made. No question.
+ *   3. else a TTY is attached (apply/install only) → ask, via lib/prompt.mjs.
+ *   4. else → UsageError, exit 2, `help` lists the four runnable commands.
+ *
+ * `status` and `uninstall` keep their old, ungated default of every host —
+ * reporting and removal are not consent points. `plan` writes nothing, so it
+ * never reaches step 3: steps 1-2, then it previews all four and says so.
+ *
+ * Call after `loadLock(ctx)` so `ctx.lock` is populated for step 2.
+ */
+async function resolveHosts(ctx, command) {
+  if (ctx.hosts.length) return { hosts: [...new Set(ctx.hosts)], chosen: true };
+  if (command === 'status' || command === 'uninstall') return { hosts: [...HOSTS], chosen: true };
+
+  const lockHosts = ctx.lock?.hosts ? Object.keys(ctx.lock.hosts) : [];
+  if (lockHosts.length) return { hosts: lockHosts, chosen: true };
+
+  if (command === 'plan') return { hosts: [...HOSTS], chosen: false };
+
+  if (process.stdin.isTTY) {
+    const chosen = await askHosts(HOSTS);
+    if (chosen) return { hosts: chosen, chosen: true };
+  }
+  throw new UsageError(
+    'no --host given, this repository has no recorded install, and there is no terminal to ask which host(s) to use',
+    HOSTS.map((h) => `${RUN} ${command} --host ${h}`),
+  );
+}
+
 function head(ctx, extra = {}) {
   return {
     version: PKG_VERSION, content_version: CONTENT_VERSION,
@@ -138,6 +175,7 @@ export async function status(argv) {
     }
     throw e;
   }
+  ({ hosts: ctx.hosts } = await resolveHosts(ctx, 'status'));
 
   const detections = await detectAll(ctx);
   const { actions, errors } = previewAll(ctx);
@@ -213,11 +251,14 @@ export async function plan(argv) {
     }
     throw e;
   }
+  const { hosts, chosen } = await resolveHosts(ctx, 'plan');
+  ctx.hosts = hosts;
   const { actions, errors } = previewAll(ctx);
   const summary = summarise(actions);
   const changes = summary.create + summary.update;
 
-  let next = changes
+  let next = chosen ? '' : 'No --host given and no existing install found, so this previews all four hosts. ';
+  next += changes
     ? `Nothing was written. Run \`${RUN} apply --yes\` to perform the ${changes} change(s).`
       + (summary.conflict || summary.manual
         ? ` The ${summary.conflict} conflict(s) and ${summary.manual} manual step(s) will be reported again and left to you.`
@@ -262,6 +303,7 @@ export async function apply(argv, label = 'apply') {
     }
     throw e;
   }
+  ({ hosts: ctx.hosts } = await resolveHosts(ctx, label));
 
   // An apply we cannot record is an apply we cannot undo. Refuse up front
   // rather than leave the user with files and no way back.
@@ -370,6 +412,7 @@ export async function uninstall(argv) {
     }
     throw e;
   }
+  ({ hosts: ctx.hosts } = await resolveHosts(ctx, 'uninstall'));
 
   if (!lock) {
     // No record means no evidence of what we own. Guessing here would delete

package/lib/guide.mjs

@@ -20,9 +20,14 @@ registers the MCP servers and permission rules they depend on.
 ## The loop
 
 1. \`${RUN} install\`
-   The whole install in one command. It refuses to prompt — Codex's question
-   tool does not block outside Plan mode, and CI has no terminal — so the verb
-   itself is the consent. Same as \`apply --yes\`.
+   The whole install in one command. It never prompts for consent — typing
+   the verb is the consent — but it does still need to know **which** host(s)
+   to write into, resolved in order: \`--host\`, if given; else the hosts a
+   lock file already records, if this is a re-run; else, with a real
+   terminal attached, an interactive picker; else it exits 2 with the four
+   \`${RUN} install --host <h>\` commands as \`help\` rather than guess or
+   hang — Codex's question tool does not block outside Plan mode, and CI has
+   no terminal, so a skill invoking this must always pass \`--host\`.
 
 2. \`${RUN} status\`
    Read-only, optional. Reports which hosts are present, what is already
@@ -34,16 +39,19 @@ registers the MCP servers and permission rules they depend on.
 
 4. \`${RUN} apply --yes\`
    The scriptable name for the same write \`install\` performs — use it for
-   re-runs and repairs. It refuses without \`--yes\`; there is no prompt, because
-   Codex's question tool does not block outside Plan mode and CI has no
-   terminal.
+   re-runs and repairs. It refuses without \`--yes\`, and resolves which
+   host(s) to touch the same way \`install\` does (see step 1).
 
 5. \`${RUN} uninstall --yes\`
    Removes what the lock file records and reverts the managed config blocks.
 
 ## Flags
 
-  --host claude-code|codex|copilot|cursor   restrict to one host, repeatable
+  --host claude-code|codex|copilot|cursor   select one host, repeatable —
+                                             see the host-resolution order in
+                                             step 1 above; a skill invoking
+                                             \`install\`/\`apply\` must always
+                                             pass it, since it has no terminal
   --scope project|user                      default: project
   --root <path>                             default: the current directory
   --no-extra-components                     skip the optional extra-component skills
@@ -68,8 +76,9 @@ The exact command is also in a \`skipped\` action's \`remedy\`, and in
 - **stdout is exactly one JSON object.** Every successful result carries a
   \`next_step\` string: the literal command to run next. Errors carry a
   \`help\` array of runnable commands.
-- **Exit codes:** 0 success, 2 usage error (your invocation was wrong),
-  1 the work could not be done.
+- **Exit codes:** 0 success, 2 usage error (your invocation was wrong,
+  including \`install\`/\`apply\` run with no \`--host\`, no existing lock and
+  no terminal to ask on), 1 the work could not be done.
 - **Nothing is silently overwritten.** A file we did not install, or one you
   edited after we installed it, is reported as \`conflict\` or \`drift\` and
   left exactly as it is. Its \`remedy\` field tells the user what to do.

package/lib/hosts.mjs

@@ -2,9 +2,10 @@
 // so adding a host or following a schema change is one table to edit.
 //
 // Detection is marker-directory existence only — no network, no process scan,
-// no `which`. It is allowed to be wrong in the harmless direction: a host that
-// is installed but has no marker directory simply is not written to, and
-// `--host` forces it.
+// no `which`. It feeds `status` reporting only; it never selects which hosts
+// a write command touches. Which hosts get written to is decided by
+// commands.mjs's `resolveHosts()` chain (`--host`, then a recorded lock,
+// then a TTY prompt, then a usage error) — detection has no vote there.
 
 import { homedir } from 'node:os';
 import { join } from 'node:path';

package/lib/prompt.mjs

@@ -0,0 +1,72 @@
+// The interactive host picker. Used only when `apply`/`install` reach step 3
+// of the host-resolution chain: no `--host`, no lock to reuse, but a real
+// terminal to ask on.
+//
+// node:readline only — the package has zero dependencies and that must not
+// change. Every prompt and echo goes to STDERR, never stdout: stdout carries
+// exactly one JSON object per run and every skill parses it, so a menu on
+// stdout would corrupt that contract. This module never inspects
+// `process.stdin.isTTY` itself — the caller decides whether to invoke it.
+
+import { createInterface } from 'node:readline';
+
+const LABELS = {
+  'claude-code': 'Claude Code',
+  codex: 'Codex',
+  copilot: 'GitHub Copilot',
+  cursor: 'Cursor',
+};
+
+/**
+ * Pure parsing, no I/O — so it can be unit-tested without a TTY.
+ *
+ * Accepts comma-separated 1-based indexes into `hosts` (e.g. "1,3"), the
+ * word "all", or an empty string — both of the latter two mean every host,
+ * made explicit rather than left as a silent default. Throws a short,
+ * human-readable `Error` on anything else (out of range, not a number,
+ * nothing at all).
+ */
+export function parseSelection(input, hosts) {
+  const trimmed = (input ?? '').trim();
+  if (trimmed === '' || trimmed.toLowerCase() === 'all') return [...hosts];
+  const parts = trimmed.split(',').map((p) => p.trim()).filter(Boolean);
+  if (!parts.length) throw new Error('no selection given');
+  const chosen = [];
+  for (const part of parts) {
+    if (!/^\d+$/.test(part)) throw new Error(`not a number: "${part}"`);
+    const n = Number(part);
+    if (n < 1 || n > hosts.length) throw new Error(`out of range 1-${hosts.length}: ${part}`);
+    const id = hosts[n - 1];
+    if (!chosen.includes(id)) chosen.push(id);
+  }
+  return chosen;
+}
+
+function question(rl, text) {
+  return new Promise((resolve) => rl.question(text, resolve));
+}
+
+/**
+ * Ask which host(s) to install into. Re-asks once on unparseable input, then
+ * gives up and returns `null` — the caller turns that into the same exit-2
+ * usage error the no-TTY path uses, so the output contract stays one shape.
+ */
+export async function askHosts(hosts) {
+  const rl = createInterface({ input: process.stdin, output: process.stderr, terminal: true });
+  const menu = hosts.map((h, i) => `  ${i + 1}. ${LABELS[h] ?? h}`).join('\n');
+  const prompt = `Which coding agent(s) should this install into?\n${menu}\n`
+    + 'Enter comma-separated numbers (e.g. "1,3"), "all", or press Enter for all: ';
+  try {
+    for (let attempt = 0; attempt < 2; attempt += 1) {
+      const answer = await question(rl, attempt === 0 ? prompt : 'Not understood — try again: ');
+      try {
+        return parseSelection(answer, hosts);
+      } catch {
+        // Re-ask once; the loop's second pass falls through to null below.
+      }
+    }
+    return null;
+  } finally {
+    rl.close();
+  }
+}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@execuro-sw-ecosystem/sw-ecosystem-agentic-harness",
-  "version": "0.1.3",
+  "version": "0.1.5",
   "description": "Shopware 6 agentic harness: sw-* skills and sub-agents, plus an installer that writes them into Claude Code, Codex, GitHub Copilot and Cursor.",
   "license": "MIT",
   "author": "Execuro UG (haftungsbeschränkt)",

package/plugin.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
   "name": "sw-ecosystem-agentic-harness",
-  "version": "0.1.3",
+  "version": "0.1.5",
   "description": "Shopware 6 agentic harness: sw-* skills and sub-agents for requirements, specs, implementation, verification and documentation, with an installer CLI that writes them into Claude Code, Codex, GitHub Copilot and Cursor. The knowledge-base MCP and the editor tools are separate npm packages.",
   "author": {
     "name": "Execuro UG (haftungsbeschränkt)",

package/skills/sw-setup/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: sw-setup
-description: Print one environment-readiness table for the project's development/test setup — vendor/, Node, the editor CLIs, shopware-cli, the KB MCP, the acceptance-test project, Playwright browsers, its .env, per-plugin test scaffolding, the project wiki and `.gitignore`, plus the installer CLI's own configuration/drift status. Stops when every row is ticked. When rows are missing, asks one yes/no question and delegates the fix to the installer CLI. Use when asked to set up the project, check if the environment is ready, or bootstrap the tests. Never designs, implements or verifies a feature itself — that's sw-design-solution, sw-implement-feature and sw-verify-feature, which call this skill first. Never writes a host configuration file itself — that's the installer CLI.
+description: Print one environment-readiness table for the project's development/test setup — vendor/, Node, the editor CLIs, shopware-cli, the KB MCP, the acceptance-test project, Playwright browsers, its .env, per-plugin test scaffolding, the project wiki, `.gitignore` and whether the SW AH npm packages are current, plus the installer CLI's own configuration/drift status. Stops when every row is ticked. When rows are missing, asks one yes/no question and delegates the fix to the installer CLI. Use when asked to set up the project, check if the environment is ready, or bootstrap the tests. Never designs, implements or verifies a feature itself — that's sw-design-solution, sw-implement-feature and sw-verify-feature, which call this skill first. Never writes a host configuration file itself — that's the installer CLI.
 when_to_use: Trigger phrases — "set up the project", "is the environment ready", "bootstrap the tests", "sw-setup".
 allowed-tools: Read Glob Grep AskUserQuestion Skill Bash mcp__ShopwareDevKnowledgeBase__kb_status Bash(npx -y @execuro-sw-ecosystem/sw-ecosystem-agentic-harness@latest *)
 ---
@@ -47,8 +47,9 @@ It prints one JSON object (`ok`, `next_step`, `help`, and its own
 `hosts[]`/`drift[]` configuration state). Alongside it, run every
 environment row's check from `reference/rows.md` in this skill's directory —
 read-only, seconds each: file/directory existence, one version command, one
-`kb_status` call. Never write, never install, never ask a question in this
-step.
+`kb_status` call, three `npm view` registry lookups (Package updates row) —
+the one part of step 1 that touches the network, so it is the slow part.
+Never write, never install, never ask a question in this step.
 
 Print one checkbox list, one line per row — the environment rows first, then
 one line per configuration item the CLI's `hosts[]`/`drift[]` reports:
@@ -65,6 +66,7 @@ one line per configuration item the CLI's `hosts[]`/`drift[]` reports:
 - [ ] ATS env — tests/acceptance/.env missing
 - [x] Plugin tests — AhCheckout: phpunit + jest ok
 - [ ] Project wiki — docs/project-wiki/ missing
+- [ ] Package updates — harness 0.1.0 → 0.1.3, Specs Editor not installed
 - [ ] Installer config — .mcp.json entry: drift (from CLI status)
 ```
 
@@ -91,8 +93,10 @@ npx -y @execuro-sw-ecosystem/sw-ecosystem-agentic-harness@latest plan
 
 List the concrete steps in plain words: environment-row fixes in order
 (vendor/ → Visual editors → KB MCP → Acceptance-test project →
-Playwright browsers → ATS env → Plugin tests → Project wiki), then the CLI's
-planned configuration changes last. Skip any row already ticked.
+Playwright browsers → ATS env → Plugin tests → Project wiki → Package
+updates), then the CLI's planned configuration changes last — Package
+updates comes immediately before those, since updating the harness is what
+may change them. Skip any row already ticked.
 
 Ask exactly one question: "Do this and that?" with the steps spelled out in
 plain words (no command dump). Ask the user with a structured question tool
@@ -138,7 +142,7 @@ line:
 
 ## Reference files
 
-`reference/rows.md` in this skill's directory — the eleven environment rows:
+`reference/rows.md` in this skill's directory — the twelve environment rows:
 check command(s), what "ticked" means, the fix steps verbatim from the
 guideline, and which skills the row blocks. Host configuration state (what
 gets installed into `.mcp.json`, permissions, `.gitignore`) is not in this

package/skills/sw-setup/reference/rows.md

@@ -1,11 +1,21 @@
 # Readiness rows
 
-Eleven environment rows. Each: check (read-only), what "ticked" means, the fix
+Twelve environment rows. Each: check (read-only), what "ticked" means, the fix
 (only run on approval, in this order), and which skills the row blocks when
 unticked. Host configuration files (`.mcp.json` entries, `.gitignore` lines,
 permission grants) are not rows here — the installer CLI owns them and
 reports their state in its own `status`/`plan` output; see `SKILL.md`.
 
+When that `status` call reports no install at all (no lock file, so no
+recorded hosts), the installer CLI's `apply --yes`/`install` has no `--host`
+to reuse and, run from this skill, no terminal to ask on — it would exit 2.
+Do not pass a guessed `--host`. Report this to the user instead: the first
+install must be run by them directly in a terminal, e.g.
+`npx -y @execuro-sw-ecosystem/sw-ecosystem-agentic-harness@latest install`,
+which then either takes their `--host` or prompts them interactively. Re-run
+this skill's `status` check afterwards — every later `apply --yes` reuses the
+hosts that first run recorded, and this skill can call it directly again.
+
 ## 1. vendor/
 
 - **Check:** `vendor/shopware/core` exists, `composer.lock` exists,
@@ -218,3 +228,42 @@ So this row never blocks readiness. It asks.
   project, verify-ac-tests screenshots). Idempotent — safe to re-run.
 - **Blocks:** nothing directly; unticked means the next `git status` will
   show generated/secret files as untracked.
+
+## 12. Package updates (optional)
+
+The KB MCP is excluded — it is registered as `@latest` and re-resolves on
+every host launch, so there is nothing to update (see row 5). This row covers
+only the three versioned packages: the harness itself, the Specs Editor and
+the Tender Discovery Tool.
+
+This row never blocks readiness. It folds into step 3's single question.
+
+- **Check:** three `npm view <pkg> version` calls, each with a 10-second
+  timeout — `npm view @execuro-sw-ecosystem/sw-ecosystem-agentic-harness
+  version`, `npm view @execuro-sw-ecosystem/sw-specs-editor version`,
+  `npm view @execuro-sw-ecosystem/sw-tender-discovery-tool version`. Installed
+  versions come from three different places: the harness's from
+  `installed_version` in the `status` JSON the skill already ran in step 1
+  (from the lock file); the Specs Editor's from `version` in
+  `node_modules/@execuro-sw-ecosystem/sw-specs-editor/package.json`; the
+  Tender Discovery Tool's the same way, in its own `node_modules` path. A
+  failed or timed-out `npm view` call reports "could not check" for that
+  package only — never an unticked row, never an error, never a blocked run.
+  No network is a normal condition, not a fault.
+- **Ticked:** all three packages at their target version — the harness at
+  npm's latest, each editor at the pin its own `status` output names
+  (`extra_components[].version`), not at npm's latest.
+- **Unticked:** one line per stale package, `installed → available` — e.g.
+  `harness 0.1.1 → 0.1.3`, `Specs Editor 0.1.0 → 0.1.0 (pinned)` when current.
+  An editor whose npm latest is ahead of the pin is a harness-release lag,
+  not a missing update: report it, but do not offer to install that newer
+  version — only a newer harness can raise the pin.
+- **Fix:** update the harness first — a newer harness may carry newer pins:
+  `npx -y @execuro-sw-ecosystem/sw-ecosystem-agentic-harness@latest install`.
+  That command rewrites the installed `sw-setup` skill itself, so the newer
+  skill takes effect on the next run — which step 3 already causes by
+  re-running step 1. Re-read the new `status` output, then for each stale
+  editor run the same `npm i -D <package>@<version>` shape row 3's Fix uses,
+  with `<package>` and `<version>` taken from that editor's own
+  `extra_components[]` entry in the re-read `status`.
+- **Blocks:** nothing. Out of date is not broken.