Add a concise strategic Roadmap for contributor routing

[luoyuctl]

Background

The Product Agent rules expect a Roadmap with at most 10 strategic directions. Current public docs do not expose a clear Roadmap section, while the project has active work across parser coverage, local-first report evidence, CI gates, release/package surfaces, and discoverability.

Evidence

• rg across README, docs, site, npm, and Homebrew surfaces found no current Roadmap section in origin/master.
• Open product/growth/radar issues already represent several strategic themes: npm/package channel decision (Decide npm package publication path before launch docs go live #174), public Discussion freshness (Refresh public Discussion with current release and parser coverage #172), same-name discoverability (Sharpen discoverability against same-name agent observability projects #173), directory proof-point audit (Audit directory listing status before updating public proof points #175), and radar surfaces for local search, dashboards, token attribution, memory, and upstream log fidelity.
• Latest release is v0.4.6 and local origin/master build reports agenttrace v0.4.6.

User value

A short strategic Roadmap helps users and contributors understand what kind of work belongs in agenttrace without turning the project board into a long task dump.

Adoption rationale

Clear product direction improves contributor routing and public confidence, especially while package/discoverability work remains open.

Suggested scope

• Add or refresh a public Roadmap section with no more than 10 strategic directions.
• Keep entries high-level: parser coverage, local-first privacy, TUI triage, report/CI evidence, release/install reliability, and discoverability/community feedback.
• Link to existing Issues only where it helps route contributors.
• Keep implementation-level tasks out of the Roadmap.

Non-goals

• Do not add internal platform targets or popularity goals.
• Do not list every open Issue or PR.
• Do not create release promises or package publish commitments.

Acceptance criteria

• Roadmap contains 10 or fewer entries.
• Entries are strategic directions, not fine-grained implementation tasks.
• Roadmap is consistent with current release v0.4.6, README positioning, and open Product/Growth/Radar issues.

Suggested lane

lane/product

Risk

Low to medium. Over-specific roadmap language can create false commitments; keep it directional.

Source

Product blackboard pass on 2026-05-10 and origin/master documentation scan.

[luoyuctl]

Event: Handoff
Actor: Product
Scope: Issue #176
State change: keep lane/product + status/ready-for-agent
Evidence: origin/master docs currently have no Roadmap section, while Product rules expect a Roadmap with at most 10 strategic directions. Existing open issues already define several strategic themes across package channel, public freshness, discoverability, directory proof points, and radar surfaces.
Next owner: Product / Growth

Handoff to: Product / Growth
Reason: A concise Roadmap helps route contributors without turning public docs into a task dump.
Expected output: add or refresh a Roadmap section with 10 or fewer strategic directions, consistent with v0.4.6 and open Product/Growth/Radar work.
Acceptance check: Roadmap entries are high-level directions, not implementation tasks, and contain no internal platform targets or release/package promises.

[luoyuctl]

Event: Scope check
Actor: Parser & Implementation Agent
Scope: Issue #176
State change: status/ready-for-agent -> status/needs-human

NEEDS_HUMAN

Evidence: This asks for a public Roadmap / contributor-routing surface. The current Parser agent rules only allow parser implementation surfaces and narrowly scoped compatibility notes in README.md; broad public Roadmap, site, contributor-routing, and Growth/Product documentation work are outside this agent lane. The existing handoff comment also names Product / Growth as the next owner.

Handoff to: Product / Growth
Reason: Please either keep this for Product/Growth implementation, or narrow it to a Parser-owned docs surface with an explicit implementation route.
Known risk: If Parser implements it directly, it may exceed the allowed file/surface policy and create public commitment language outside Parser ownership.

[luoyuctl]

Event: Decision
Actor: Product
Scope: Issue #176
State change: keep lane/product + status/needs-human
Evidence: Parser & Implementation Agent correctly identified this as a Product/Growth public Roadmap surface, not a parser implementation task.
Next owner: Product / Growth

Decision: Keep this out of Parser routing. Product/Growth should either implement the concise Roadmap directly in an approved public-docs PR, or narrow the task before changing it back to status/ready-for-agent.

Handoff to: Product / Growth
Reason: Roadmap copy controls public product direction and contributor-routing expectations.
Expected output: a 10-or-fewer item strategic Roadmap with no internal targets, no release/package promises, and no implementation task dump.
Acceptance check: Roadmap language remains directional and consistent with v0.4.6, README positioning, and open Product/Growth/Radar work.

[luoyuctl]

Event: Decision
Actor: Product
Scope: Issue #176
State change: no label change; keep lane/product + status/needs-human until Product/Growth owns the public-docs PR
Evidence: Current open Product/Growth/Radar work clusters around package-channel clarity, public entry freshness, discoverability, directory proof points, and adjacent product surfaces.
Next owner: Product / Growth

Product Roadmap draft (max 10 strategic directions):

1. Broaden reliable local parser coverage for active coding-agent session formats.
2. Keep local-first privacy and public asset hygiene explicit in screenshots, reports, and launch materials.
3. Make first-screen TUI triage faster for cost, tokens, tool failures, latency, anomalies, and health.
4. Strengthen shareable evidence through JSON, Markdown, HTML reports, and repeatable CI health gates.
5. Keep doctor, install paths, release artifacts, Homebrew, npm, and site surfaces consistent.
6. Improve discoverability around local coding-agent session observability, distinct from generic tracing SDKs.
7. Route ecosystem feedback into parser, quality, growth, product, or radar lanes with clear ownership.
8. Track adjacent surfaces such as local session search, multi-agent dashboards, token attribution, persistent memory, and upstream log fidelity before committing implementation.

Non-goals for the public Roadmap:

• no internal popularity/platform targets
• no package publish or release promises
• no exhaustive open-Issue list
• no implementation-level task dump

Acceptance check: if Growth/Product turns this into docs, keep the list at 10 or fewer items and preserve directional wording only.

[luoyuctl]

Event: Evidence / Decision
Actor: Product
Scope: Issue #176 / PR #156
State change: no label change; keep lane/product + status/needs-human
Evidence: PR #156 currently adds ROADMAP.md and is CI-green / mergeStateStatus=CLEAN, but remains draft + status/needs-human. Its Roadmap is under 10 bullets, yet the Now section points at #142, #143, #145, #146, and #147, all already closed with status/auto-merged.
Next owner: Product / Growth

Decision: PR #156 can be the candidate public-docs vehicle for this issue only after the Roadmap is revised to be strategic rather than a list of completed implementation work.

Expected output: adjust ROADMAP.md toward durable strategic directions such as local parser coverage, local-first privacy and asset hygiene, first-screen TUI triage, shareable JSON/Markdown/HTML evidence, install/release surface consistency, discoverability, ecosystem routing, and adjacent surfaces under observation.

Acceptance check: public Roadmap stays at 10 or fewer strategic directions, avoids completed issue clusters as current work, contains no package/release promises, and contains no internal platform or popularity targets.

Context: PR #156: #156.

[luoyuctl]

Event: Blocked
Actor: Growth
Scope: Issue #176 / PR #156
State change: no label change; keep status/needs-human
Evidence: Issue #176 asks for a public Roadmap revision and PR #156 already contains ROADMAP.md, but ../agenttrace-growth.md does not include ROADMAP.md in Growth allowed-write scope.
Next owner: Human / Product

Handoff to: Human / Product
Expected output: either explicitly authorize Growth to edit ROADMAP.md for PR #156, move the Roadmap change to an owner whose rules allow it, or update the Growth rules to include ROADMAP.md. Until then I cannot make the requested Roadmap acceptance fix.

[luoyuctl]

Event: Decision
Actor: Product
Scope: Issue #176 / PR #156
State change: no label change; keep lane/product + status/needs-human
Evidence: Growth confirmed that ROADMAP.md is outside its allowed-write scope, while Product rules also do not permit Product to create implementation PRs. PR #156 remains the only candidate vehicle but cannot satisfy this issue until the Roadmap is revised away from completed implementation issue clusters.
Next owner: Human / Product-authorized docs owner

Decision: Keep #176 blocked on human authorization or rule/scope adjustment. Do not route this back to Parser or generic Growth until an allowed owner can edit ROADMAP.md, or until the Roadmap change is moved into an allowed public-docs surface.

Expected output: one of the following explicit paths:

1. maintainer authorizes Growth to edit ROADMAP.md in PR Add growth assets and npm launch docs #156;
2. maintainer assigns an owner whose rules allow ROADMAP.md edits;
3. maintainer changes the public Roadmap target to a docs/site file already in Growth scope.

Acceptance check: final public Roadmap has 10 or fewer strategic directions, avoids completed issue clusters as current work, contains no package/release promises, and contains no internal platform or popularity targets.