Roadmap after 2.10: a feed map, a visual atlas and a code graph. What would you use?

[rushar-labs]

Update, 2026-09-30. Mermaid for the maps and the WorkGraph shipped in 2.11.0. The feed map, the static atlas and the Lane Dashboard views move to 2.12, and the code graph to 2.13; ROADMAP.md keeps the current plan. The questions below still apply.

This thread collects input on the two minors planned after 2.10. It describes a direction, not a delivery promise: the CHANGELOG and the release notes remain the record of what shipped.

Where the maps are today

Every map in HPP is a projection of files you already have (manifests, event logs, JSON you supply), and the same input prints the same output. On 2.10.0:

command	formats
hpp graph --view capability|operational|agent|evidence|code	JSON or Mermaid (GitHub draws Mermaid on its own)
hpp map lane|agent|monitor|context	JSON
hpp work plan|waves	JSON
hpp doctor --matrix	Markdown: host × module × channel

The code view shows which surfaces each module declares. It is not a graph of your code.

2.10.0 also ships the Lane Dashboard in the lane-kit: a page on 127.0.0.1 that you start and stop, showing the lane board, the live lanes, each lane's mailbox and the backlog with its waves, where every action is also a terminal command.

What is planned

2.11: see the state

1. --format mermaid for the maps and for the WorkGraph, with the same determinism tests the graphs already have.
2. A feed map: one timeline of what happened across lanes (claims, verdicts, messages sent and read, deliveries, handoffs, heartbeats), derived from records the harness already writes.
3. A static atlas: hpp atlas --html writes one self-contained page with every view of a project, drawn from the same JSON. Each view shows the command that reproduces it and the hash of its source. It opens as a file; there is no server.
4. The Lane Dashboard showing the same views, drawn from the same JSON, next to the actions it already offers.

2.12: a code graph of your project

A base built on the Python standard library (modules, imports, definitions and calls from ast; for other languages an import graph only, declared as such), plus a contract, hpp.codegraph/v1, for an external indexer you declare. HPP would normalise and measure that input; it would not depend on it. The graph is built on demand, stored by commit hash and reported as stale when it is old, with no watcher. It would feed lane territory by dependency, WorkGraph checks, the blast radius of an attestation and the atlas's code view.

What would help

• Which of these would you use first, and for what?
• For the feed: which events do you need to see, and which would be noise?
• For the atlas and the dashboard: which view would you open first?
• For the code graph: which languages matter to you, and which index format would you want to plug in?

When you can, answer with your setup: host, bundle and the command you would run. One point per comment keeps the thread readable, and an upvote on a comment counts as agreement. A proposal that grows its own design belongs in Ideas.

Pode responder em português.