Audit — Competitive Roadmap and Owner Dashboard Plan

Question

Should the competitive roadmap (2026-08-01-competitive-roadmap.md) and the owner-dashboard-and-capture-loop plan (2026-08-01-owner-dashboard-and-capture-loop.md) be executed as written? Where does their product reasoning break down?

Answer

Both plans are well-engineered and poorly product-reasoned. As engineering documents they are solid: the communities.json correction is honest, Guardrail #10 discipline is maintained, the dependency map is accurate, and every interface field the dashboard code claims to consume (action, snapshot_path, queued, counts.{pending,claimed,done,failed}, max_claimed, candidates_awaiting) matches the actual Python sources (scripts/external_links.py, scripts/auto_ingest.py).[

As product documents they skip assumption-testing entirely:

1. Solutioning before framing. The competitive brief answered its own research question with a “recommended focus”, and the plans treat that recommendation as a validated user need. Nobody asked who the non-technical owner actually is, or whether they struggle with the one-line CLI capture today.[
2. Feature-parity trap, renamed. Each NOW/NEXT/LATER item maps 1:1 to a competitor feature (nashsu→dashboard, lucasastorian→capture, atomicstrata→lifecycle lint, nashsu→graph insights). No item traces back to observed evidence about this vault’s own user.[
3. The deliverable is not a learning. The plan produces a 7-option menu and docs; no metric moves, no hypothesis is tested, no behavior is measured. The dashboard flow (open menu → pick 5 → paste → read → pick 6 → read → pick 3 → read) may be more steps than the CLI it replaces, not fewer.[
4. The tests test the code, not the decision. The Pester assertions prove a label string exists in dashboard.ps1, not that the flow works or that the owner will use it. This is “brainstorming when you should be researching” wearing a TDD costume.[

The audit’s concrete recommendation: park execution. Run a 14-day capture-usage log of the owner’s own ingest behavior. If the owner fumbles with the CLI, the dashboard is justified and the plan is ready. If they don’t, the plan was solving a phantom problem and the real leverage is the NEXT band deterministic query gate.[

An alternative the brief’s framing suppressed: a browser bookmarklet (one click → POST to the MCP server → queued) reuses the same external_links.py capture with zero menu navigation and genuinely fewer steps than today.[

Implications

• The roadmap’s NOW band rests on an untested assumption about the owner’s actual workflow. The cheapest de-risking is observational (14-day usage log), not more TDD.
• The deterministic query gate is the one item both documents agree is unowned by any competitor; it should be ranked by evidence of the owner’s behavior, not by the brief’s dashboard-first framing.
• The brief and this audit disagree on prioritization, not on facts — the brief’s star counts and feature matrix remain accurate. The tension is recorded here as contested for any future reader deciding what to build.

Open Questions

• Who, exactly, is the non-technical owner — and is the “non-technical” claim descriptive or aspirational? (The auditor notes this is itself an untested assertion: the README targets a non-technical reader, but whether the owner-as-user is one is unmeasured.)[
• Is a guided dashboard menu, a bookmarklet, or neither the right capture surface for this vault’s owner?

Related

• competitive-brief-llm-wiki-ecosystem — the brief this audit critiques; same date, conflicting priority signal
• battlecard-nashsu-llm-wiki — the competitor deliverable that motivated the dashboard-first framing
• community-detection-deep-dive — why the roadmap’s communities.json correction matters (Louvain already runs today)
• ecossistema-stacks-vs-nosso-vault — the stack comparison the brief builds on

Sources