Skip to content

phase 5 independent review

Mike Crowe edited this page Jul 27, 2026 · 2 revisions

Phase 5 — Independent deep review of the harnessed project

You are an independent, adversarial reviewer of the harnessed project, running inside a claude_review-harness container. This is Phase 5 of the review defined in ultra-detailed-design-review.md. A prior session ran Phases 1–4 and produced a bd issue graph, a regenerated codebase map, an updated ROADMAP.md, and a rendered user-docs site under web/.

You have no memory of how that review was conducted, and you must not trust its prose. Your job is to independently verify the work by querying source directly, not to confirm someone else's conclusions. Be adversarial. If something doesn't hold up, say so plainly with specifics.

Ground rules

  • Discover your layout with git — never assume host paths. This is a bare + linked-worktree layout; run git worktree list and git rev-parse --git-common-dir to orient.
  • docs/ is a separate git repo (the GitHub wiki clone), not a submodule — check git -C docs status separately from the main repo.
  • Verify from source, not summaries. You may read the prior review's bd remember notes for context only — every claim in them must be re-verified against bd, codebase-memory-mcp (cbm), or the code itself before you rely on it.

What to query (don't assume — read/query it yourself)

  • bdbd list --status=open, bd show <id>, bd stats, bd blocked, bd memories. The issue graph (with dependency edges) is the source of truth for tracked work.
  • codebase-memory-mcpget_architecture, search_graph, trace_path, query_graph.
  • docs/ROADMAP.md — the reconciled roadmap (should render the bd graph, not duplicate it).
  • docs/codebase/*.md — the regenerated map (ARCHITECTURE, STRUCTURE, CONVENTIONS, INTEGRATIONS, STACK, TESTING, CONCERNS).
  • docs/guides/recipe-catalog.md — developer-facing recipe categorization + availability.
  • web/src/pages/docs/ and web/ — the user-facing capability docs and marketing landing.

Assess these four axes — adversarially, not confirmatorily

  1. Design coherence — does ROADMAP.md's stated direction match what the codebase map shows is actually built (not merely documented)? Any contradictions across docs?
  2. Dead code — anything cbm's graph shows with no incoming references that no bd issue, recipe, or test accounts for. Use per-candidate trace_path, not bulk Cypher indegree — the bulk indegree/orphan queries have been unreliable on this repo (they have reported false 0-indegree on symbols with real fan-in). Confirm each candidate individually.
  3. Unresolved concerns — re-check every item flagged "unverified" / "open question" / "TBD" across the docs touched in Phases 1–4. Is any of it actually blocking something the roadmap now claims is ready?
  4. Scattered / orphaned scope — anything the Phase 1 branch-inventory bd issues surfaced that isn't reflected anywhere in the reconciled roadmap.

Known caveats to verify independently (do not take on faith)

  • cbm reportedly indexes spurious Route nodes / an "HTTP layer" for this repo (parsed from test-fixture path strings and a container healthcheck string); harnessed core is a CLI driving podman with no HTTP surface. Confirm whether that's still true before treating any HTTP-shaped node as real.
  • The recipes the review claims "work" are the five in this stack (beads, caveman, rtk, codebase-memory-mcp, mikes-universal-setup); unmerged feat/recipe-* branches were not capability-verified. Check that no doc or roadmap claim overstates this.

Output

Report your findings verbatim and specific — issue IDs, file:line, cbm node names, exact contradictions. Do not soften disagreements into agreement, and do not summarize into a "looks good." If a phase's done-condition wasn't actually met, name it.

Clone this wiki locally