topicforge 0.7.0__tar.gz → 0.7.1__tar.gz

{topicforge-0.7.0 → topicforge-0.7.1}/CHANGELOG.md

@@ -7,6 +7,52 @@ and this project adheres to [Semantic Versioning 2.0.0](https://semver.org/spec/
 
 ## [Unreleased]
 
+## [0.7.1] - 2026-10-14
+
+QoS fix suggestions and agent-friction fixes from the blind evaluation (`docs/EVAL.md`). Additive only: no field or
+input was renamed, removed or retyped (`docs/CONTRACT.md` section 9).
+
+### Added
+
+- `detect_qos_mismatches` fills `suggested_fixes` (output contract 2, additive; see
+  `docs/CONTRACT.md` section 3.1): "diagnose, propose the exact fix, verify". Each QoS
+  mismatch report and each `partition` split gets up to one fix per side that can change
+  (`MismatchReport.suggested_fixes`, and the new `NotMatchedPair.suggested_fixes`), with its
+  tradeoff and a `verify_with` call. A ROS 2 topic with a Reliability or Durability finding
+  gets a `qos_override` parameter-file entry; every other case gets a `dds_profile` (Fast DDS
+  XML plus the cyclonedds-python equivalent, since Cyclone DDS has no XML QoS profile).
+  Covered: Reliability, Durability, Deadline, Liveliness, Ownership, LatencyBudget and
+  Partition; other findings get a hint instead. Identical findings on a topic share the
+  first report's fixes. Text only: TopicForge never applies a fix, and a test fails any
+  suggestion containing a stop, remove or write verb.
+- `list_participants` and `participant_events`: `restarts_by_name` (`{name: {lives,
+  departures}}` for names seen with several GUIDs or lost) and `restarts_note`, so an agent
+  no longer counts GUIDs to find a restart loop.
+- `participant_events`: `age_s` on each event, seconds between the event and the response
+  (`null` in mock mode).
+- `detect_qos_mismatches`: `summary`, a one-line reading of the scan that says when pairs are
+  not matched and no data flows, even with an empty `reports`.
+- `list_endpoints`: optional input `fields` (`full` default, or `compact`) with the output
+  fields `fields` and `qos_summary`; compact replaces each `qos` by a one-line summary and
+  drops `type_id`, `announced_ns` and `ros_topic_note`.
+
+### Changed
+
+- `tools/list` is about 37 percent smaller (about 178 KB to 113 KB compact), because some
+  clients truncated it: tool and field descriptions are shorter, and the generated schema
+  titles and nested-model docstrings are no longer served. Names, types, defaults and
+  constraints are unchanged. The long explanations moved to `docs/CONTRACT.md` section 9.
+- `domain_id` on `list_participants`, `participant_events`, `topic_metrics` and
+  `list_endpoints`: the description now opens with "Ignored", and a non-zero value that
+  differs from the domain joined at startup adds an explicit sentence to the response `note`
+  (the response `domain_id` already named the observed domain).
+
+### Fixed
+
+- `scripts/ground_truth/compare.py` counts only active DDS participants: the `ros2` CLI
+  processes that `get_node_info` starts stay listed with status `left` and inflated the count
+  (found on the OmniSim kit run of 2026-10-14 on 0.7.0: 76 checks passed, 0 failed).
+
 ## [0.7.0] - 2026-10-12
 
 Breaking release: output contract 2 (see `docs/MIGRATION-0.7.md`), the move to the MCP SDK
@@ -1615,7 +1661,8 @@ Initial MVP release of TopicForge: ROS Topic Inspector & Bag Analyzer MCP server
 - The write path (publishing, commanding robots) is intentionally out of scope for the MVP.
 - `analyze_bag` in live mode parses `ros2 bag info` text output; deeper anomaly detection remains mock-only for now.
 
-[Unreleased]: https://github.com/yaniswav/TopicForge/compare/v0.7.0...HEAD
+[Unreleased]: https://github.com/yaniswav/TopicForge/compare/v0.7.1...HEAD
+[0.7.1]: https://github.com/yaniswav/TopicForge/compare/v0.7.0...v0.7.1
 [0.7.0]: https://github.com/yaniswav/TopicForge/compare/v0.6.4...v0.7.0
 [0.6.4]: https://github.com/yaniswav/TopicForge/compare/v0.6.3...v0.6.4
 [0.6.3]: https://github.com/yaniswav/TopicForge/compare/v0.6.2...v0.6.3

{topicforge-0.7.0 → topicforge-0.7.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: topicforge
-Version: 0.7.0
+Version: 0.7.1
 Summary: ROS Topic Inspector & Bag Analyzer MCP server for AI agents
 Project-URL: Homepage, https://github.com/yaniswav/TopicForge
 Project-URL: Repository, https://github.com/yaniswav/TopicForge
@@ -75,7 +75,7 @@ Every tool also declares itself read-only in the MCP protocol (`readOnlyHint`, `
 
 It gives the agent fourteen typed tools that return frozen Pydantic schemas (output contract 2: one object per tool, one `note`, units in the field names; see [`docs/CONTRACT.md`](docs/CONTRACT.md)), identical whether the server talks to a real robot or to its built-in mock fixtures. Ask why `nav_planner` gets no scan, and the agent reads the bus, finds the BEST_EFFORT writer facing a RELIABLE reader and names the incompatible policy (see [`examples/02-debug-qos-mismatch.md`](examples/02-debug-qos-mismatch.md)). It is meant for ROS2 developers, robotics ML/CV engineers and teams that cannot accept a write path into a production stack.
 
-For DDS, TopicForge joins a domain as a read-only participant through one open-source binding (Eclipse CycloneDDS from PyPI) and reads the builtin discovery topics that the OMG DDS-RTPS protocol standardizes. So far the author has observed Cyclone DDS and Dust DDS participants on a live bus. RTI Connext, OpenDDS, CoreDX and Fast DDS announce themselves through the same standard discovery, but none of them has been observed yet. This covers discovery only: participants, readers, writers and their QoS. See [`docs/dds-interop-matrix.md`](docs/dds-interop-matrix.md).
+For DDS, TopicForge joins a domain as a read-only participant through one open-source binding (Eclipse CycloneDDS from PyPI) and reads the builtin discovery topics that the OMG DDS-RTPS protocol standardizes. Cyclone DDS, Fast DDS and Dust DDS participants have been observed on live buses: the Fast DDS ones on every CI run of the ROS 2 test bench (Humble and Jazzy with `rmw_fastrtps_cpp`) and in the OmniSim validation. RTI Connext, OpenDDS and CoreDX announce themselves through the same standard discovery, but none of them has been observed yet. This covers discovery only: participants, readers, writers and their QoS. See [`docs/dds-interop-matrix.md`](docs/dds-interop-matrix.md).
 
 ## Quickstart
 
@@ -103,7 +103,7 @@ The server speaks MCP over stdio and waits for a client, so wire it into one. Fo
 
 Then ask it to list the topics or to analyze `/tmp/demo.mcap`. For Claude Code: `claude mcp add topicforge -- topicforge`. If the client cannot launch the server (WSL2 to Windows, a robot over an SSH tunnel), `topicforge --transport streamable-http --port 8765` serves `http://127.0.0.1:8765/mcp` on loopback only; see [`docs/CLIENTS.md`](docs/CLIENTS.md#local-http-transport).
 
-**Other MCP clients.** Ready-to-paste configs for Claude Desktop, Cursor, VS Code, Windsurf, Cline, Roo Code, Continue, Zed, JetBrains, Codex, Gemini CLI, Goose and more are in [`docs/CLIENTS.md`](docs/CLIENTS.md). One-click: [Add to Cursor](https://cursor.com/install-mcp?name=topicforge&config=eyJjb21tYW5kIjoidXZ4IiwiYXJncyI6WyItLWZyb20iLCJ0b3BpY2ZvcmdlPT0wLjcuMCIsInRvcGljZm9yZ2UiXSwiZW52Ijp7IlRPUElDRk9SR0VfTU9ERSI6ImF1dG8iLCJUT1BJQ0ZPUkdFX0REU19CQUNLRU5EIjoiY3ljbG9uZSIsIlRPUElDRk9SR0VfRERTX0RPTUFJTl9JRCI6IjAifX0%3D) | [Install in VS Code](https://vscode.dev/redirect/mcp/install?name=topicforge&config=%7B%22command%22%3A%22uvx%22%2C%22args%22%3A%5B%22--from%22%2C%22topicforge%3D%3D0.7.0%22%2C%22topicforge%22%5D%2C%22env%22%3A%7B%22TOPICFORGE_MODE%22%3A%22auto%22%2C%22TOPICFORGE_DDS_BACKEND%22%3A%22cyclone%22%2C%22TOPICFORGE_DDS_DOMAIN_ID%22%3A%220%22%7D%7D).
+**Other MCP clients.** Ready-to-paste configs for Claude Desktop, Cursor, VS Code, Windsurf, Cline, Roo Code, Continue, Zed, JetBrains, Codex, Gemini CLI, Goose and more are in [`docs/CLIENTS.md`](docs/CLIENTS.md). One-click: [Add to Cursor](https://cursor.com/install-mcp?name=topicforge&config=eyJjb21tYW5kIjoidXZ4IiwiYXJncyI6WyItLWZyb20iLCJ0b3BpY2ZvcmdlPT0wLjcuMSIsInRvcGljZm9yZ2UiXSwiZW52Ijp7IlRPUElDRk9SR0VfTU9ERSI6ImF1dG8iLCJUT1BJQ0ZPUkdFX0REU19CQUNLRU5EIjoiY3ljbG9uZSIsIlRPUElDRk9SR0VfRERTX0RPTUFJTl9JRCI6IjAifX0%3D) | [Install in VS Code](https://vscode.dev/redirect/mcp/install?name=topicforge&config=%7B%22command%22%3A%22uvx%22%2C%22args%22%3A%5B%22--from%22%2C%22topicforge%3D%3D0.7.1%22%2C%22topicforge%22%5D%2C%22env%22%3A%7B%22TOPICFORGE_MODE%22%3A%22auto%22%2C%22TOPICFORGE_DDS_BACKEND%22%3A%22cyclone%22%2C%22TOPICFORGE_DDS_DOMAIN_ID%22%3A%220%22%7D%7D).
 
 Setup for a real ROS2 environment (WSL2, Linux, Docker, native Windows) is in [`docs/TESTING.md`](docs/TESTING.md); recurring monitoring prompts and the privacy contract are in [`docs/TUTORIEL.md`](docs/TUTORIEL.md).
 
@@ -174,7 +174,7 @@ Samples with comments are in [`.env.example`](.env.example). Any invalid value s
 
 External validation against a simulated robot's ground truth (OmniSim): [docs/VALIDATION.md](docs/VALIDATION.md).
 
-- DDS validation is partial. The Cyclone adapter has run against a real bus, with Cyclone and Dust DDS participants, on Windows and in CI on Ubuntu and Windows (`.github/workflows/demo.yml`). The Fast DDS adapter has never run against a bus, and no RTI, OpenDDS, CoreDX or OpenSplice participant has been observed by this project. The multi-vendor claim rests on the RTPS protocol guarantee, not on a recorded cross-vendor run.
+- DDS validation is partial. The Cyclone adapter has run against real buses with Cyclone, Fast DDS and Dust DDS participants, on Windows and in CI on Ubuntu and Windows (`.github/workflows/demo.yml`, `.github/workflows/ros2-live.yml`). The Fast DDS adapter (TopicForge joining through the `fastdds` binding) has never run against a bus, and no RTI, OpenDDS, CoreDX or OpenSplice participant has been observed by this project. The multi-vendor claim rests on the RTPS protocol guarantee, not on a recorded cross-vendor run.
 - User-topic payloads are not decoded. `peek_dds_samples` on a user topic returns count 0 and a note that the topic is announced on the bus; no traffic is read. `topic_metrics` therefore has data only for the builtin discovery topics and says so in its `status`. It is a discovery-layer probe, not a publish-rate monitor.
 - Liveliness at runtime is not observed. A writer that is alive but silent (a hung process whose lease is still renewed) looks healthy, because TopicForge reads discovery, not data. An opt-in data probe is planned. A crash and a clean leave cannot be told apart, and `lost_ns` is an upper bound of the death.
 - Cyclone vendor ids: participants that do not follow the RTPS vendor-id convention in their GUID prefix (Dust DDS, and RTI by default) are reported with vendor `unknown`.
@@ -205,7 +205,7 @@ When on, each tool call emits one event with exactly six fields:
 | `tool_name`  | `"list_topics"` | One of the fourteen tools, never argument values            |
 | `latency_ms` | `12.34`         | Handler wall-clock duration, 2 decimals                     |
 | `mode`       | `"mock"`        | Mode of the adapter actually serving: `mock` or `live`      |
-| `version`    | `"0.7.0"`       | TopicForge server version                                   |
+| `version`    | `"0.7.1"`       | TopicForge server version                                   |
 | `session_id` | `"a1b2c3..."`   | Random UUID per process, never persisted                    |
 | `success`    | `true`          | Whether the handler returned or raised                      |
 
@@ -237,7 +237,7 @@ Tests run against the mock adapter, the live adapter's pure parsers and the bind
 
 ## Upgrading
 
-TopicForge is pre-1.0; [`CHANGELOG.md`](CHANGELOG.md) lists every change, including the yanked releases and removed extras. 0.7.0 changes the shape of tool results (`contract_version` 2): [`docs/MIGRATION-0.7.md`](docs/MIGRATION-0.7.md) maps every old field to its new one.
+TopicForge is pre-1.0; [`CHANGELOG.md`](CHANGELOG.md) lists every change, including the yanked releases and removed extras. 0.7.0 changed the shape of tool results (`contract_version` 2): [`docs/MIGRATION-0.7.md`](docs/MIGRATION-0.7.md) maps every old field to its new one.
 
 ## Layout
 

{topicforge-0.7.0 → topicforge-0.7.1}/README.md

@@ -14,7 +14,7 @@ Every tool also declares itself read-only in the MCP protocol (`readOnlyHint`, `
 
 It gives the agent fourteen typed tools that return frozen Pydantic schemas (output contract 2: one object per tool, one `note`, units in the field names; see [`docs/CONTRACT.md`](docs/CONTRACT.md)), identical whether the server talks to a real robot or to its built-in mock fixtures. Ask why `nav_planner` gets no scan, and the agent reads the bus, finds the BEST_EFFORT writer facing a RELIABLE reader and names the incompatible policy (see [`examples/02-debug-qos-mismatch.md`](examples/02-debug-qos-mismatch.md)). It is meant for ROS2 developers, robotics ML/CV engineers and teams that cannot accept a write path into a production stack.
 
-For DDS, TopicForge joins a domain as a read-only participant through one open-source binding (Eclipse CycloneDDS from PyPI) and reads the builtin discovery topics that the OMG DDS-RTPS protocol standardizes. So far the author has observed Cyclone DDS and Dust DDS participants on a live bus. RTI Connext, OpenDDS, CoreDX and Fast DDS announce themselves through the same standard discovery, but none of them has been observed yet. This covers discovery only: participants, readers, writers and their QoS. See [`docs/dds-interop-matrix.md`](docs/dds-interop-matrix.md).
+For DDS, TopicForge joins a domain as a read-only participant through one open-source binding (Eclipse CycloneDDS from PyPI) and reads the builtin discovery topics that the OMG DDS-RTPS protocol standardizes. Cyclone DDS, Fast DDS and Dust DDS participants have been observed on live buses: the Fast DDS ones on every CI run of the ROS 2 test bench (Humble and Jazzy with `rmw_fastrtps_cpp`) and in the OmniSim validation. RTI Connext, OpenDDS and CoreDX announce themselves through the same standard discovery, but none of them has been observed yet. This covers discovery only: participants, readers, writers and their QoS. See [`docs/dds-interop-matrix.md`](docs/dds-interop-matrix.md).
 
 ## Quickstart
 
@@ -42,7 +42,7 @@ The server speaks MCP over stdio and waits for a client, so wire it into one. Fo
 
 Then ask it to list the topics or to analyze `/tmp/demo.mcap`. For Claude Code: `claude mcp add topicforge -- topicforge`. If the client cannot launch the server (WSL2 to Windows, a robot over an SSH tunnel), `topicforge --transport streamable-http --port 8765` serves `http://127.0.0.1:8765/mcp` on loopback only; see [`docs/CLIENTS.md`](docs/CLIENTS.md#local-http-transport).
 
-**Other MCP clients.** Ready-to-paste configs for Claude Desktop, Cursor, VS Code, Windsurf, Cline, Roo Code, Continue, Zed, JetBrains, Codex, Gemini CLI, Goose and more are in [`docs/CLIENTS.md`](docs/CLIENTS.md). One-click: [Add to Cursor](https://cursor.com/install-mcp?name=topicforge&config=eyJjb21tYW5kIjoidXZ4IiwiYXJncyI6WyItLWZyb20iLCJ0b3BpY2ZvcmdlPT0wLjcuMCIsInRvcGljZm9yZ2UiXSwiZW52Ijp7IlRPUElDRk9SR0VfTU9ERSI6ImF1dG8iLCJUT1BJQ0ZPUkdFX0REU19CQUNLRU5EIjoiY3ljbG9uZSIsIlRPUElDRk9SR0VfRERTX0RPTUFJTl9JRCI6IjAifX0%3D) | [Install in VS Code](https://vscode.dev/redirect/mcp/install?name=topicforge&config=%7B%22command%22%3A%22uvx%22%2C%22args%22%3A%5B%22--from%22%2C%22topicforge%3D%3D0.7.0%22%2C%22topicforge%22%5D%2C%22env%22%3A%7B%22TOPICFORGE_MODE%22%3A%22auto%22%2C%22TOPICFORGE_DDS_BACKEND%22%3A%22cyclone%22%2C%22TOPICFORGE_DDS_DOMAIN_ID%22%3A%220%22%7D%7D).
+**Other MCP clients.** Ready-to-paste configs for Claude Desktop, Cursor, VS Code, Windsurf, Cline, Roo Code, Continue, Zed, JetBrains, Codex, Gemini CLI, Goose and more are in [`docs/CLIENTS.md`](docs/CLIENTS.md). One-click: [Add to Cursor](https://cursor.com/install-mcp?name=topicforge&config=eyJjb21tYW5kIjoidXZ4IiwiYXJncyI6WyItLWZyb20iLCJ0b3BpY2ZvcmdlPT0wLjcuMSIsInRvcGljZm9yZ2UiXSwiZW52Ijp7IlRPUElDRk9SR0VfTU9ERSI6ImF1dG8iLCJUT1BJQ0ZPUkdFX0REU19CQUNLRU5EIjoiY3ljbG9uZSIsIlRPUElDRk9SR0VfRERTX0RPTUFJTl9JRCI6IjAifX0%3D) | [Install in VS Code](https://vscode.dev/redirect/mcp/install?name=topicforge&config=%7B%22command%22%3A%22uvx%22%2C%22args%22%3A%5B%22--from%22%2C%22topicforge%3D%3D0.7.1%22%2C%22topicforge%22%5D%2C%22env%22%3A%7B%22TOPICFORGE_MODE%22%3A%22auto%22%2C%22TOPICFORGE_DDS_BACKEND%22%3A%22cyclone%22%2C%22TOPICFORGE_DDS_DOMAIN_ID%22%3A%220%22%7D%7D).
 
 Setup for a real ROS2 environment (WSL2, Linux, Docker, native Windows) is in [`docs/TESTING.md`](docs/TESTING.md); recurring monitoring prompts and the privacy contract are in [`docs/TUTORIEL.md`](docs/TUTORIEL.md).
 
@@ -113,7 +113,7 @@ Samples with comments are in [`.env.example`](.env.example). Any invalid value s
 
 External validation against a simulated robot's ground truth (OmniSim): [docs/VALIDATION.md](docs/VALIDATION.md).
 
-- DDS validation is partial. The Cyclone adapter has run against a real bus, with Cyclone and Dust DDS participants, on Windows and in CI on Ubuntu and Windows (`.github/workflows/demo.yml`). The Fast DDS adapter has never run against a bus, and no RTI, OpenDDS, CoreDX or OpenSplice participant has been observed by this project. The multi-vendor claim rests on the RTPS protocol guarantee, not on a recorded cross-vendor run.
+- DDS validation is partial. The Cyclone adapter has run against real buses with Cyclone, Fast DDS and Dust DDS participants, on Windows and in CI on Ubuntu and Windows (`.github/workflows/demo.yml`, `.github/workflows/ros2-live.yml`). The Fast DDS adapter (TopicForge joining through the `fastdds` binding) has never run against a bus, and no RTI, OpenDDS, CoreDX or OpenSplice participant has been observed by this project. The multi-vendor claim rests on the RTPS protocol guarantee, not on a recorded cross-vendor run.
 - User-topic payloads are not decoded. `peek_dds_samples` on a user topic returns count 0 and a note that the topic is announced on the bus; no traffic is read. `topic_metrics` therefore has data only for the builtin discovery topics and says so in its `status`. It is a discovery-layer probe, not a publish-rate monitor.
 - Liveliness at runtime is not observed. A writer that is alive but silent (a hung process whose lease is still renewed) looks healthy, because TopicForge reads discovery, not data. An opt-in data probe is planned. A crash and a clean leave cannot be told apart, and `lost_ns` is an upper bound of the death.
 - Cyclone vendor ids: participants that do not follow the RTPS vendor-id convention in their GUID prefix (Dust DDS, and RTI by default) are reported with vendor `unknown`.
@@ -144,7 +144,7 @@ When on, each tool call emits one event with exactly six fields:
 | `tool_name`  | `"list_topics"` | One of the fourteen tools, never argument values            |
 | `latency_ms` | `12.34`         | Handler wall-clock duration, 2 decimals                     |
 | `mode`       | `"mock"`        | Mode of the adapter actually serving: `mock` or `live`      |
-| `version`    | `"0.7.0"`       | TopicForge server version                                   |
+| `version`    | `"0.7.1"`       | TopicForge server version                                   |
 | `session_id` | `"a1b2c3..."`   | Random UUID per process, never persisted                    |
 | `success`    | `true`          | Whether the handler returned or raised                      |
 
@@ -176,7 +176,7 @@ Tests run against the mock adapter, the live adapter's pure parsers and the bind
 
 ## Upgrading
 
-TopicForge is pre-1.0; [`CHANGELOG.md`](CHANGELOG.md) lists every change, including the yanked releases and removed extras. 0.7.0 changes the shape of tool results (`contract_version` 2): [`docs/MIGRATION-0.7.md`](docs/MIGRATION-0.7.md) maps every old field to its new one.
+TopicForge is pre-1.0; [`CHANGELOG.md`](CHANGELOG.md) lists every change, including the yanked releases and removed extras. 0.7.0 changed the shape of tool results (`contract_version` 2): [`docs/MIGRATION-0.7.md`](docs/MIGRATION-0.7.md) maps every old field to its new one.
 
 ## Layout
 

{topicforge-0.7.0 → topicforge-0.7.1}/docs/CLIENTS.md

@@ -6,7 +6,7 @@ TopicForge (ROS 2 / DDS) is a local, read-only MCP server that speaks stdio.
 Every client below launches it as a child process with the same command:
 
 ```
-uvx --from "topicforge==0.7.0" topicforge
+uvx --from "topicforge==0.7.1" topicforge
 ```
 
 and the same three environment variables:
@@ -21,7 +21,7 @@ The registry name is `io.github.yaniswav/topicforge`. Where a client asks for a
 display name, use **TopicForge (ROS 2 / DDS)**: an unrelated SEO product is also
 called TopicForge in the MCP registries.
 
-The version pin (`==0.7.0`) is moved on every release together with the other
+The version pin (`==0.7.1`) is moved on every release together with the other
 version strings; a test keeps them in sync.
 
 ## Before you start
@@ -44,7 +44,7 @@ version strings; a test keeps them in sync.
   `"--from"` in the args. To build the binding yourself, install the Cyclone C library and
   run `pip install "topicforge[dds]"`. The `[dds]` and `[dds-cyclone]` extras still work
   as aliases, so older commands keep installing.
-- **pip alternative.** `pip install "topicforge==0.7.0"`, then use
+- **pip alternative.** `pip install "topicforge==0.7.1"`, then use
   `"command": "topicforge"` (or `"command": "python", "args": ["-m", "topicforge"]`)
   with no `args` for uvx. Use the absolute path of the binary if the client does
   not see your venv.
@@ -72,7 +72,7 @@ say where the file lives and what differs.
   "mcpServers": {
     "topicforge": {
       "command": "uvx",
-      "args": ["--from", "topicforge==0.7.0", "topicforge"],
+      "args": ["--from", "topicforge==0.7.1", "topicforge"],
       "env": {
         "TOPICFORGE_MODE": "auto",
         "TOPICFORGE_DDS_BACKEND": "cyclone",
@@ -95,7 +95,7 @@ claude plugin install topicforge@topicforge
 Or just the server:
 
 ```
-claude mcp add topicforge --env TOPICFORGE_MODE=auto --env TOPICFORGE_DDS_BACKEND=cyclone --env TOPICFORGE_DDS_DOMAIN_ID=0 -- uvx --from "topicforge==0.7.0" topicforge
+claude mcp add topicforge --env TOPICFORGE_MODE=auto --env TOPICFORGE_DDS_BACKEND=cyclone --env TOPICFORGE_DDS_DOMAIN_ID=0 -- uvx --from "topicforge==0.7.1" topicforge
 ```
 
 ## Claude Desktop
@@ -112,9 +112,9 @@ the common JSON shape above and restart the app completely. On Windows, if
 
 The one-click links in this page and in the README are https redirects, because GitHub and PyPI strip `cursor://` and `vscode:` links. Only the raw schemes are documented by Cursor and VS Code; the https forms (`cursor.com/install-mcp`, `vscode.dev/redirect/mcp/install`) were observed to redirect correctly on 2026-10-06 but are not in the vendors' docs (unverified, last checked 2026-10-06). The raw links are given as a fallback.
 
-One click: [Add TopicForge to Cursor](https://cursor.com/install-mcp?name=topicforge&config=eyJjb21tYW5kIjoidXZ4IiwiYXJncyI6WyItLWZyb20iLCJ0b3BpY2ZvcmdlPT0wLjcuMCIsInRvcGljZm9yZ2UiXSwiZW52Ijp7IlRPUElDRk9SR0VfTU9ERSI6ImF1dG8iLCJUT1BJQ0ZPUkdFX0REU19CQUNLRU5EIjoiY3ljbG9uZSIsIlRPUElDRk9SR0VfRERTX0RPTUFJTl9JRCI6IjAifX0%3D)
+One click: [Add TopicForge to Cursor](https://cursor.com/install-mcp?name=topicforge&config=eyJjb21tYW5kIjoidXZ4IiwiYXJncyI6WyItLWZyb20iLCJ0b3BpY2ZvcmdlPT0wLjcuMSIsInRvcGljZm9yZ2UiXSwiZW52Ijp7IlRPUElDRk9SR0VfTU9ERSI6ImF1dG8iLCJUT1BJQ0ZPUkdFX0REU19CQUNLRU5EIjoiY3ljbG9uZSIsIlRPUElDRk9SR0VfRERTX0RPTUFJTl9JRCI6IjAifX0%3D)
 
-If that page does not open Cursor, use the raw deeplink: `cursor://anysphere.cursor-deeplink/mcp/install?name=topicforge&config=eyJjb21tYW5kIjoidXZ4IiwiYXJncyI6WyItLWZyb20iLCJ0b3BpY2ZvcmdlPT0wLjcuMCIsInRvcGljZm9yZ2UiXSwiZW52Ijp7IlRPUElDRk9SR0VfTU9ERSI6ImF1dG8iLCJUT1BJQ0ZPUkdFX0REU19CQUNLRU5EIjoiY3ljbG9uZSIsIlRPUElDRk9SR0VfRERTX0RPTUFJTl9JRCI6IjAifX0=`
+If that page does not open Cursor, use the raw deeplink: `cursor://anysphere.cursor-deeplink/mcp/install?name=topicforge&config=eyJjb21tYW5kIjoidXZ4IiwiYXJncyI6WyItLWZyb20iLCJ0b3BpY2ZvcmdlPT0wLjcuMSIsInRvcGljZm9yZ2UiXSwiZW52Ijp7IlRPUElDRk9SR0VfTU9ERSI6ImF1dG8iLCJUT1BJQ0ZPUkdFX0REU19CQUNLRU5EIjoiY3ljbG9uZSIsIlRPUElDRk9SR0VfRERTX0RPTUFJTl9JRCI6IjAifX0=`
 
 Or paste the common JSON shape into `~/.cursor/mcp.json` (all projects) or
 `.cursor/mcp.json` (one project).
@@ -125,9 +125,9 @@ The `plugin/` folder of this repository is also an [Agent Plugins](https://agent
 
 ## VS Code / GitHub Copilot
 
-One click: [Install in VS Code](https://vscode.dev/redirect/mcp/install?name=topicforge&config=%7B%22command%22%3A%22uvx%22%2C%22args%22%3A%5B%22--from%22%2C%22topicforge%3D%3D0.7.0%22%2C%22topicforge%22%5D%2C%22env%22%3A%7B%22TOPICFORGE_MODE%22%3A%22auto%22%2C%22TOPICFORGE_DDS_BACKEND%22%3A%22cyclone%22%2C%22TOPICFORGE_DDS_DOMAIN_ID%22%3A%220%22%7D%7D)
+One click: [Install in VS Code](https://vscode.dev/redirect/mcp/install?name=topicforge&config=%7B%22command%22%3A%22uvx%22%2C%22args%22%3A%5B%22--from%22%2C%22topicforge%3D%3D0.7.1%22%2C%22topicforge%22%5D%2C%22env%22%3A%7B%22TOPICFORGE_MODE%22%3A%22auto%22%2C%22TOPICFORGE_DDS_BACKEND%22%3A%22cyclone%22%2C%22TOPICFORGE_DDS_DOMAIN_ID%22%3A%220%22%7D%7D)
 
-Fallback, the raw URL handler: `vscode:mcp/install?%7B%22name%22%3A%22topicforge%22%2C%22command%22%3A%22uvx%22%2C%22args%22%3A%5B%22--from%22%2C%22topicforge%3D%3D0.7.0%22%2C%22topicforge%22%5D%2C%22env%22%3A%7B%22TOPICFORGE_MODE%22%3A%22auto%22%2C%22TOPICFORGE_DDS_BACKEND%22%3A%22cyclone%22%2C%22TOPICFORGE_DDS_DOMAIN_ID%22%3A%220%22%7D%7D`
+Fallback, the raw URL handler: `vscode:mcp/install?%7B%22name%22%3A%22topicforge%22%2C%22command%22%3A%22uvx%22%2C%22args%22%3A%5B%22--from%22%2C%22topicforge%3D%3D0.7.1%22%2C%22topicforge%22%5D%2C%22env%22%3A%7B%22TOPICFORGE_MODE%22%3A%22auto%22%2C%22TOPICFORGE_DDS_BACKEND%22%3A%22cyclone%22%2C%22TOPICFORGE_DDS_DOMAIN_ID%22%3A%220%22%7D%7D`
 
 Or put this in `.vscode/mcp.json` (the key is `servers`, not `mcpServers`), or run
 "MCP: Add Server" from the Command Palette:
@@ -138,7 +138,7 @@ Or put this in `.vscode/mcp.json` (the key is `servers`, not `mcpServers`), or r
     "topicforge": {
       "type": "stdio",
       "command": "uvx",
-      "args": ["--from", "topicforge==0.7.0", "topicforge"],
+      "args": ["--from", "topicforge==0.7.1", "topicforge"],
       "env": {
         "TOPICFORGE_MODE": "auto",
         "TOPICFORGE_DDS_BACKEND": "cyclone",
@@ -167,7 +167,7 @@ Servers", and paste the common JSON shape (the file is
 Project file `.roo/mcp.json` (takes precedence) or the global `mcp_settings.json`
 opened from the MCP view. Paste the common JSON shape. Roo's docs say Windows
 needs a `cmd /c` wrapper for `npx`; for `uvx`, try it directly first and fall back
-to `"command": "cmd", "args": ["/c", "uvx", "--from", "topicforge==0.7.0",
+to `"command": "cmd", "args": ["/c", "uvx", "--from", "topicforge==0.7.1",
 "topicforge"]` if it fails to start.
 
 ## Continue
@@ -184,7 +184,7 @@ mcpServers:
     command: uvx
     args:
       - "--from"
-      - "topicforge==0.7.0"
+      - "topicforge==0.7.1"
       - "topicforge"
     env:
       TOPICFORGE_MODE: auto
@@ -201,7 +201,7 @@ In `settings.json`, under `context_servers`:
   "context_servers": {
     "topicforge": {
       "command": "uvx",
-      "args": ["--from", "topicforge==0.7.0", "topicforge"],
+      "args": ["--from", "topicforge==0.7.1", "topicforge"],
       "env": {
         "TOPICFORGE_MODE": "auto",
         "TOPICFORGE_DDS_BACKEND": "cyclone",
@@ -227,7 +227,7 @@ run with the dds extra can exceed, so set it to 60 s:
 ```toml
 [mcp_servers.topicforge]
 command = "uvx"
-args = ["--from", "topicforge==0.7.0", "topicforge"]
+args = ["--from", "topicforge==0.7.1", "topicforge"]
 startup_timeout_sec = 60
 
 [mcp_servers.topicforge.env]
@@ -258,7 +258,7 @@ extensions:
     name: TopicForge (ROS 2 / DDS)
     type: stdio
     cmd: uvx
-    args: [--from, "topicforge==0.7.0", topicforge]
+    args: [--from, "topicforge==0.7.1", topicforge]
     enabled: true
     envs: { "TOPICFORGE_MODE": "auto", "TOPICFORGE_DDS_BACKEND": "cyclone", "TOPICFORGE_DDS_DOMAIN_ID": "0" }
     timeout: 300
@@ -325,7 +325,7 @@ when the question matches.
 
 ## Troubleshooting
 
-- Run the command by hand first: `uvx --from "topicforge==0.7.0" topicforge --version`.
+- Run the command by hand first: `uvx --from "topicforge==0.7.1" topicforge --version`.
 - Server starts but sees no DDS participants: check the domain id, and that the
   client machine is on the same network as the robot (DDS discovery uses
   multicast UDP). Ask the assistant to call `health_check`.

{topicforge-0.7.0 → topicforge-0.7.1}/docs/CONTRACT.md

@@ -14,12 +14,13 @@ Sections:
 
 1. Principles
 2. Decisions
-3. Reserved optional fields
+3. Optional fields
 4. Rate verdicts
 5. Reserved multimodal exception
 6. Change policy and tests
 7. 0.7.0 migration list
 8. Node tools
+9. 0.7.x additions
 
 ## 1. Principles
 
@@ -249,34 +250,50 @@ values a tool can return:
 {"timestamp_ns": 1760000000123456789, "stamp_source": "dds_source"}
 ```
 
-## 3. Reserved optional fields
+## 3. Optional fields
 
-These shapes are fixed now so that they can be added later without a break. Until a
-tool fills them, they do not appear in its output (1.3, mechanism 1). Each is optional
-and additive.
+Some shapes were fixed before any tool filled them, so that they could be added without a
+break. Each is optional and additive; a tool that does not fill one omits its content (1.3,
+mechanism 1).
 
 ### 3.1 `suggested_fixes`
 
-Not a tool: an optional list on a diagnostic finding (first on a QoS mismatch report).
-TopicForge diagnoses, proposes a fix as text, a human applies it, TopicForge verifies.
+Populated by `detect_qos_mismatches` since 0.7.1, on `reports[]` (RxO mismatches) and on
+`not_matched[]` (`partition` splits only). Not a tool: an optional list on a diagnostic
+finding. TopicForge diagnoses, proposes a fix as text, a human applies it, TopicForge
+verifies. Other tools may fill it later with the same shape.
 
 ```json
 {"suggested_fixes": [
   {"kind": "qos_override",
    "target": "reader /nav2/controller on /scan",
-   "text": "qos_overrides./scan.subscription.reliability: best_effort",
-   "tradeoff": "The reader stops requesting retransmission, so it can miss samples.",
-   "verify_with": "detect_qos_mismatches"}
+   "text": "/nav2/controller:
+  ros__parameters:
+    qos_overrides./scan.subscription.reliability: best_effort",
+   "tradeoff": "The reader stops requesting retransmission, so it can miss samples. Only works if the node enabled QoS overrides (rclcpp/rclpy QosOverridingOptions); pass the file when the node starts: --ros-args --params-file <file>.",
+   "verify_with": "detect_qos_mismatches(topic='rt/scan')"}
 ]}
 ```
 
 | Field | Content |
 | --- | --- |
-| `kind` | one of `cli`, `qos_override`, `dds_profile`, `launch_param` (closed set) |
+| `kind` | one of `cli`, `qos_override`, `dds_profile`, `launch_param` (closed set). 0.7.1 emits `qos_override` and `dds_profile` |
 | `target` | which node or which side to change, writer or reader |
 | `text` | the exact command, YAML or XML to apply |
 | `tradeoff` | what is lost by applying it |
-| `verify_with` | the TopicForge tool to run again to confirm the repair |
+| `verify_with` | the TopicForge tool and arguments to run again to confirm the repair |
+
+Behaviour:
+
+- A finding gets one fix per side that can change, most often two (the safer side first,
+  explained in `tradeoff`). A finding with no supported fix (DestinationOrder,
+  DataRepresentation, History) has an empty list and a `hints` entry.
+- `qos_override` is used for a ROS 2 topic (`rt/` prefix) when only Reliability and
+  Durability differ; everything else is a `dds_profile`: a Fast DDS XML profile followed by
+  the cyclonedds-python equivalent.
+- Findings with the same topic and compared values share one set of fixes, carried by the
+  first report; the others have an empty list and a `hints` entry says so. A fix lists at most
+  three nodes.
 
 Rules:
 
@@ -284,7 +301,9 @@ Rules:
   text for a human; TopicForge never applies them". `readOnlyHint` stays true.
 - No destructive verb: nothing that kills a process, shuts down a lifecycle node,
   deletes or unsets a parameter, removes a file. A test fails any suggestion whose
-  `text` contains a forbidden verb; the list lives in that test.
+  `text`, `target` or `tradeoff` contains a forbidden word (kill, pkill, delete, rm,
+  shutdown, deactivate, cleanup, set, publish, call, launch, restart, reset); the list
+  lives in that test.
 - When two sides can fix the problem (the writer or the reader), both are offered as
   separate entries, each with its own `tradeoff`.
 
@@ -628,3 +647,130 @@ Rules:
 - A name used by several nodes is flagged: `duplicate_count` above 1 and a `note`, because the
   CLI answers for one of them without saying which.
 - An unknown node is an `isError` result naming close matches (1.6).
+
+## 9. 0.7.x additions
+
+Everything here is additive (1.9): a new optional field or input with a backward-compatible
+default, or a description that says the same thing in fewer words. No property was renamed,
+removed or retyped; `scripts/contract/snapshot_tools.py` regenerates the snapshots and the diff
+shows only added properties.
+
+### 9.1 Listing size
+
+`tools/list` carries the description, input schema and output schema of every tool, and some
+clients truncate it. In 0.7.0 it was about 178 KB compact (14 tools); 0.7.1 serves about 113 KB.
+How:
+
+- Pydantic's generated `title` is dropped from every property and nested model, and the
+  docstring of a nested model is dropped (the model name stays). The output type name stays as
+  the `title` of each `outputSchema`. Done by `tools/schema_compact.py`.
+- Field descriptions are one sentence, and self-explanatory ones (`reader_guid`, `returned`)
+  have none. The longer explanations are in this section and in section 4; the rules a client
+  needs stay in the tool description.
+- `tests/test_friction_fixes.py` fails if the listing grows back over 120 KB.
+
+Rule for new fields: one sentence, no history, no restating the name.
+
+### 9.2 `restarts_by_name`
+
+A restarted ROS 2 node is a new DDS participant with a new GUID and the same name, so
+`seen_count` (observations of one GUID) stays at 1 and an agent had to count GUIDs by hand.
+`list_participants` and `participant_events` now carry:
+
+- `restarts_by_name: {name: {lives, departures}}`. `lives` is the number of distinct GUIDs
+  that carried the name (restarts = `lives` - 1); `departures` is the number of times a
+  participant with that name was lost.
+- Only names with `lives` > 1 or `departures` > 0 are listed, so a healthy bus adds nothing. A
+  name that is absent ran once and stayed.
+- `list_participants` counts the participants it lists (`status` `left` is a departure), bounded
+  by the lifecycle buffer. `participant_events` counts the events in the `lookback_s` window
+  only: a participant discovered before the window and still active does not appear, and one
+  that left inside it counts one life and one departure.
+- Participants and events without a `name` are excluded and `restarts_note` says how many.
+  Dust DDS announces no name, and every Fast DDS participant of a ROS 2 setup is named `/`, so
+  those cannot be separated by name.
+
+### 9.3 `domain_id` is ignored, and says so
+
+`domain_id` on `list_participants`, `participant_events`, `topic_metrics` and `list_endpoints`
+never selected a domain: the adapter reports the one it joined at startup
+(`TOPICFORGE_DDS_DOMAIN_ID`, `health_check.dds_domain_id`). The parameter stays (removing it
+is a break). Its description now starts with "Ignored" and the response `domain_id` is the
+domain actually observed.
+
+When a non-zero `domain_id` differs from the joined domain, the response `note` says
+`domain_id N was ignored: this server observes domain M ...`. Chosen over raising an
+`AdapterError` because a note is additive and cannot break a client that always passed the
+wrong value, while an error would; the envelope already carries the real domain. The default
+`0` cannot be told from "not given", so an explicit `0` is never flagged, and an omitted
+argument never produces a note when the joined domain is not 0. The mock adapter does not
+report a joined domain and gives no note.
+
+### 9.4 `list_endpoints` `fields`
+
+New optional input `fields`: `"full"` (default, unchanged output) or `"compact"`. Compact
+keeps every endpoint and the `by_topic` roll-up, sets `qos` to `null` and fills the new
+`qos_summary` with a one-line reading (`RELIABLE VOLATILE KEEP_LAST(10) deadline=100ms
+partitions=a`, defaults left out), and drops `type_id`, `announced_ns` and `ros_topic_note`.
+The response echoes the level in `fields`. Use `full` on one topic or participant to read a
+complete QoS. In compact mode `qos_summary` is `qos unresolved` when the QoS could not be
+resolved.
+
+### 9.5 `MismatchScan.summary`
+
+One line stating the counts: `0 incompatible, 0 risky QoS pair(s); 3 pairs will never match
+(3 by partition): no data flows between them, see `not_matched`; 5 pairs will match given the
+announced QoS.` An empty `reports` next to a non-empty `not_matched` can no longer be read as
+an all-clear from the summary alone. The counts are over the whole scan, before the 200-entry
+cap. Built in `adapters/common/qos_scan.py`, so every backend and the mock carry it.
+
+### 9.6 `ParticipantEvent.age_s`
+
+Seconds between `timestamp_ns` and the moment the response was built (never negative, three
+decimals), next to the `*_ns` fields that are hard to read. `null` in mock mode, whose timeline
+is a fixed 2024 anchor. Only the events got it: the other `*_ns` stamps of the listing
+(`first_seen_ns`, `last_seen_ns`) would add a field to every participant for little reading
+value; compare against `health_check.now_ns` when needed.
+
+### 9.7 Explanations moved out of the schema
+
+- `TopicRate.startup_burst_count`: on a live call the fresh `ros2 topic echo` prints the
+  messages its reader queued before the first callback (up to 5) in one go. A leading run of
+  intervals under a quarter of the median interval is that drain; those messages are set aside
+  before the intervals, `observed_frequency_hz` and the verdict, are still counted in
+  `message_count`, and still feed `sim_frequency_hz`. Always 0 on `recorded_ns`.
+- `TopicRate.observed_frequency_hz` is coarse when the messages span under about a second (one
+  late message moves it by several percent): compare `sim_frequency_hz` when present and ask
+  for `count` 50 on a topic above 20 Hz. `sim_frequency_hz` is `null` when the messages carry no
+  stamp (`stamp_source` `none` or `recorded`) or the stamps do not advance.
+- `TopicRate.verdict`: a `silent` topic may be latched; a topic with several publishers such as
+  `/tf` reads `erratic` without being broken; a simulated or bridged sensor whose intervals
+  alternate reads `jittery` while healthy: compare `max_gap_s` with `interval_median_s` before
+  suspecting a lost message.
+- `MessageSample.timestamp_ns` on simulated time is sim time since the simulation started (a
+  few seconds, not a date) and 0 is a valid value. `peek_bag_samples` gives a message without a
+  header the bag record time (`stamp_source` `recorded`), also in `recorded_ns`. Mock samples
+  with a header carry synthetic increasing values. `stamp_source`: `sample_messages` gives
+  `header`, `payload` or `none`; `peek_bag_samples` `header`, `payload` or `recorded`;
+  `peek_dds_samples` `dds_source` or `none`.
+- `MessageSample.payload`: `_truncated_fields` lists the dotted paths of arrays, strings or bytes
+  cut at `max_array_length` (a string of exactly that length plus `...` that was not cut is
+  listed too); `_raw_text` holds the unparsed output only when a message could not be parsed;
+  with `arrays_summary_only` an array is a string such as `<sequence type: float, length: 541>`.
+  A message over the size cap may be dropped with a `note`.
+- `MessageSample.summary` is computed on the whole message even when `payload` is cut, and is
+  `null` for a scan whose arrays were replaced by `arrays_summary_only`.
+- `ParticipantInfo.lost_ns` and `ParticipantEvent.time_source` for `lost`: an upper bound of when
+  the participant died. After a clean shutdown it is the exact leave time; after a crash it is
+  when the lease expired, and the two cannot be told apart. The process died at or before it,
+  and at most one lease earlier (10 s Cyclone default, 20 s Fast DDS, 100 s RTI).
+- `ParticipantInfo.vendor` is read from the vendor prefix of the participant GUID. Dust DDS and
+  RTI Connext do not put their vendor id there, and the Cyclone Python binding does not expose
+  the RTPS header vendor id, so those are `unknown` (the participant is still reported). See
+  `docs/dds-interop-matrix.md`.
+- `QosProfile.partitions`: no Partition policy is the default partition, reported as `[""]`,
+  never `[]`; `null` only when the backend cannot read partitions at all. `history` is reported
+  only for TopicForge's own endpoints and for Cyclone peers that set it (see `history_note`);
+  a reader `deadline_ns` tighter than the writer's is incompatible.
+- `HealthReport.ros2_distro` discloses `ROS_DISTRO` by design under the local-trust threat model
+  (README "Security model"); a hosted multi-tenant endpoint would scrub it.

{topicforge-0.7.0 → topicforge-0.7.1}/docs/DDS_QUICKSTART.md

@@ -2,7 +2,7 @@
 
 A short tour of TopicForge's DDS observability tools. The server joins the bus as a read-only DDS-RTPS participant and reads the builtin discovery topics, which the OMG protocol standardizes for every conformant vendor (observed so far: Cyclone DDS and Dust DDS). The `MiddlewareAdapter` protocol has no write method, so the MCP client cannot publish back on any backend. This guide does not assume ROS2.
 
-Validation status. The Cyclone adapter has run against a live bus, with a Python / Cyclone participant and Dust DDS participants in Rust, Python and C, on Windows and in CI (Ubuntu and Windows, `.github/workflows/demo.yml`); see [`scripts/integration/README.md`](../scripts/integration/README.md). The Fast DDS adapter has never run against a bus, and no RTI, OpenDDS, CoreDX or OpenSplice participant has been observed yet. For runnable live scenarios (who is on the bus, why two nodes cannot talk, a node that crashed, a late joiner that misses data), see [`examples/dds/README.md`](../examples/dds/README.md). Multi-vendor positioning: [`dds-interop-matrix.md`](dds-interop-matrix.md).
+Validation status. The Cyclone adapter has run against a live bus, with a Python / Cyclone participant and Dust DDS participants in Rust, Python and C, on Windows and in CI (Ubuntu and Windows, `.github/workflows/demo.yml`); see [`scripts/integration/README.md`](../scripts/integration/README.md). Fast DDS participants (ROS 2 nodes on `rmw_fastrtps_cpp`) are observed by the Cyclone adapter on every run of the ROS 2 test bench in CI; the Fast DDS adapter itself (joining through the `fastdds` binding) has never run against a bus, and no RTI, OpenDDS, CoreDX or OpenSplice participant has been observed yet. For runnable live scenarios (who is on the bus, why two nodes cannot talk, a node that crashed, a late joiner that misses data), see [`examples/dds/README.md`](../examples/dds/README.md). Multi-vendor positioning: [`dds-interop-matrix.md`](dds-interop-matrix.md).
 
 ## 1. Mock mode
 

{topicforge-0.7.0 → topicforge-0.7.1}/docs/EVAL.md

@@ -112,6 +112,20 @@ Claude run reported none.
 - **Unnamed or unknown-vendor participant** read as a possible problem in 2 of
   3 healthy-bus runs.
 
+Addressed in 0.7.1 (changes made after the runs above, not re-measured by a new
+evaluation round):
+
+- Listing size: `tools/list` went from about 178 KB to about 113 KB compact
+  (`docs/CONTRACT.md` section 9.1).
+- Empty `reports` next to `not_matched`: `MismatchScan.summary` states the counts
+  (section 9.5).
+- `domain_id`: the description opens with "Ignored" and the response `note` flags a
+  differing non-zero value (section 9.3).
+- `*_ns` fields: `age_s` on participant events (section 9.6).
+- `seen_count` and restarts: `restarts_by_name` on `list_participants` and
+  `participant_events` (section 9.2).
+- Verbose `list_endpoints`: `fields` `compact` (section 9.4).
+
 ## Description edit made
 
 One, description only, no contract change: `list_participants` now states that

{topicforge-0.7.0 → topicforge-0.7.1}/docs/TESTING.md

@@ -15,7 +15,7 @@ How to get a working ROS2 environment to point TopicForge at, and how to wire it
 ```bash
 python -m venv .venv && source .venv/bin/activate   # Windows: .venv\Scripts\Activate.ps1
 pip install topicforge
-python -m topicforge --version                      # -> topicforge 0.7.0
+python -m topicforge --version                      # -> topicforge 0.7.1
 TOPICFORGE_MODE=mock python -m topicforge           # blocks on stdio; MCP clients spawn it
 ```
 
@@ -41,7 +41,7 @@ python3 -m venv ~/topicforge-venv && source ~/topicforge-venv/bin/activate
 pip install topicforge          # Ubuntu 22.04 ships Python 3.10, which is enough
 ```
 
-Then run live mode with three terminals. In the first, `ros2 run demo_nodes_cpp talker` publishes `/chatter` at about 1 Hz. In the second, `ros2 topic list` should show `/chatter`. In the third, source ROS2, activate the venv and run `TOPICFORGE_MODE=live python -m topicforge`. The startup line reads `topicforge 0.7.0 ready (mode=live, requested_mode=live, adapter=ros2_cli, telemetry=off)`; `mode=mock` means `ros2` was not found and the server fell back to fixtures.
+Then run live mode with three terminals. In the first, `ros2 run demo_nodes_cpp talker` publishes `/chatter` at about 1 Hz. In the second, `ros2 topic list` should show `/chatter`. In the third, source ROS2, activate the venv and run `TOPICFORGE_MODE=live python -m topicforge`. The startup line reads `topicforge 0.7.1 ready (mode=live, requested_mode=live, adapter=ros2_cli, telemetry=off)`; `mode=mock` means `ros2` was not found and the server fell back to fixtures.
 
 ## Linux native