docs: promote #83 and #71 to Tier 0 in backlog

[carlos-alm]

Summary

• Adds new Tier 0 section to BACKLOG.md for items that should be implemented before Phase 4+ roadmap work
• Promotes docs: add dogfood report for v2.2.3-dev #83 (hook-optimized codegraph brief command) from Tier 1i — enriches passively-injected hook context with roles, caller counts, and risk tiers
• Promotes docs: add feature backlog and track file moves in hooks #71 (basic type inference for typed languages) from Tier 1h — closes the biggest graph accuracy gap for TypeScript and Java resolution

Rationale

These two items deliver the highest immediate impact on agent experience and graph accuracy without requiring Rust porting or TypeScript migration. brief (#83) improves the context agents actually see via hooks; type inference (#71) prevents hallucinated "no callers" for method calls through typed variables.

Test plan

• Verify BACKLOG.md renders correctly on GitHub (Tier 0 table, items removed from Tier 1h/1i)
• No code changes — docs only

[greptile-apps]

Greptile Summary

Despite being titled a docs-only PR, this change bundles two distinct bodies of work: (1) a significant ROADMAP.md restructuring that inserts a new Phase 4 — Native Analysis Acceleration and renumbers all downstream phases, and (2) a substantial code refactoring that migrates communities, sequence, triage, symbol-lookup, and dependency from direct better-sqlite3 handles to a Repository abstraction via a new openRepo() helper — along with matching test rewrites that replace temp-file SQLite fixtures with the new InMemoryRepository-based createTestRepo() builder.

Key observations:

• openRepo() in connection.js is clean and well-guarded with an instanceof Repository type check
• Most feature files (communities.js, triage.js) migrate cleanly to the new pattern
• sequence.js introduces a leaky abstraction: it imports SqliteRepository directly and accesses the internal repo.db property to run raw prepared statements for dataflow annotations, bypassing the repository interface — the dataflow queries should be surfaced through the Repository base class
• The createTestRepo() builder has no .churn() method, so the triage "sort by churn" test now trivially passes on all-zero values rather than exercising real ordering logic
• The roadmap renumbering is thorough and consistent (all cross-references and the dependency graph were updated)

Confidence Score: 4/5

• Safe to merge with minor follow-up work recommended for the leaky abstraction in sequence.js and the churn test gap.
• The Repository migration pattern is sound and the bulk of the changes are correct. The two issues are style/coverage concerns rather than bugs: the repo.db access in sequence.js will work correctly today but creates a maintenance hazard, and the churn sort test passes but no longer tests real behavior. Neither issue blocks merging.
• src/features/sequence.js (leaky repo.db access) and tests/integration/triage.test.js (churn test coverage gap)

Important Files Changed

Filename	Overview
src/db/connection.js	Adds openRepo() helper that returns a { repo, close } pair from either an injected Repository instance or a SQLite DB path. Validates the injected value with an instanceof Repository guard.
src/features/sequence.js	Migrated to openRepo pattern but introduces a leaky abstraction: imports SqliteRepository directly and accesses repo.db to run raw SQL for dataflow annotations. Dataflow queries should be moved into the Repository interface rather than bypassing it.
src/graph/builders/dependency.js	Adapted to accept a dbOrRepo union by adding instanceof Repository dispatch throughout. The minConfidence path falls back to getCallEdges() (all edges) when a Repository is passed; a comment acknowledges the limitation.
tests/integration/communities.test.js	Migrated from temp-file SQLite fixtures to createTestRepo() / InMemoryRepository. Tests simplified significantly, fixture logic preserved. No coverage gaps.
tests/integration/triage.test.js	Migrated to createTestRepo() cleanly, but the churn sort test is now a no-op since InMemoryRepository returns churn=0 for all nodes — real churn ordering is no longer tested.

Sequence Diagram

sequenceDiagram
    participant Caller as Feature (communities / sequence / triage)
    participant openRepo as openRepo()
    participant Repo as Repository (interface)
    participant SQLite as SqliteRepository
    participant InMem as InMemoryRepository

    Caller->>openRepo: openRepo(dbPath, opts)
    alt opts.repo is set
        openRepo-->>Caller: { repo: opts.repo, close: noop }
    else open SQLite
        openRepo->>SQLite: new SqliteRepository(db)
        openRepo-->>Caller: { repo: SqliteRepository, close: db.close }
    end

    Caller->>Repo: repo.findCallees(id)
    Repo-->>Caller: callee rows

    Note over Caller,SQLite: sequence.js dataflow path only
    Caller->>SQLite: instanceof SqliteRepository check
    Caller->>SQLite: repo.db.prepare(...) — raw SQL
    SQLite-->>Caller: dataflow rows

Loading

Comments Outside Diff (2)

1. src/features/sequence.js, line 176-177 (link)

   Leaky abstraction — repo.db bypasses the Repository interface

   sequence.js now imports SqliteRepository directly and reaches into its internal db property to run raw prepared statements for dataflow annotations. This ties a feature module to a specific repository implementation:

   import { SqliteRepository } from '../db/repository/sqlite-repository.js';
   ...
   if (hasTable && repo instanceof SqliteRepository) {
     const db = repo.db;
     const getReturns = db.prepare(`SELECT d.expression FROM dataflow d ...`);
     const getFlowsTo  = db.prepare(`SELECT d.expression FROM dataflow d ...`);
   }

   The consequence is that dataflow annotations are silently skipped for any non-SqliteRepository caller (e.g. a future RemoteRepository or a test double). The proper fix is to surface the two queries through the Repository base interface — something like getReturnsForNode(nodeId) and getFlowsToForNode(nodeId) — so every implementation can handle them and the feature code stays decoupled from the storage layer.

   If adding the methods to the interface is out of scope for this PR, at minimum a // TODO comment should note this as a known tech-debt item rather than a structural decision.

2. tests/integration/triage.test.js, line 161-163 (link)

   Churn sort test is now a no-op

   The previous fixture inserted varied churn values (src/handler.js → 50 commits, src/formatter.js → 20, src/math.js → 2), so "sort by churn" exercised real ordering. The new fixture has no .churn() builder method and InMemoryRepository returns churn=0 for every node. The test comment acknowledges this ("verify no errors"), but it means churn-based ranking is no longer tested at all — a >= assertion over identical zeros will trivially pass even if the sort logic is broken.

   Consider either:

   1. Adding a .churn(file, count) method to TestRepoBuilder / InMemoryRepository so churn data can be seeded and the assertion can verify real ordering, or
   2. Keeping one small SQLite fixture (similar to the retained dataflow test) specifically for the churn sort case.

_{Last reviewed commit: 09dd0a7}

[greptile-apps]

Missed section renumber

Phase 10 was renumbered to Phase 11 throughout the file, but this subsection heading was left as 10.6 instead of 11.6. All other subsections under Phase 11 (11.1–11.5) were updated correctly.

Suggested change

	### 10.6 -- Auto-generated Docstrings
	### 11.6 -- Auto-generated Docstrings

[carlos-alm]

Fixed in ed1d34d. The subsection heading was renumbered from 10.6 to 11.6 — it belongs under Phase 11 (Interactive Visualization & Advanced Features), not Phase 10.

[greptile-apps]

minConfidence silently ignored for Repository path

When dbOrRepo is a Repository and minConfidence is set, the code falls back to getCallEdges() with no filtering — returning all call edges regardless of confidence. The comment acknowledges this, but callers (e.g. viewer.js, export.js) pass minConfidence expecting it to filter low-confidence edges. This means Repository-backed graphs will include edges that would be excluded in the SQLite path.

Consider filtering in JS after fetching:

Suggested change

	if (minConfidence != null) {
	edges = db
	.prepare("SELECT source_id, target_id FROM edges WHERE kind = 'calls' AND confidence >= ?")
	.all(minConfidence);
	if (isRepo) {
	// minConfidence filtering not supported by Repository — fall back to getCallEdges
	edges = dbOrRepo.getCallEdges();
	} else {
	edges = dbOrRepo
	.prepare("SELECT source_id, target_id FROM edges WHERE kind = 'calls' AND confidence >= ?")
	.all(minConfidence);
	}
	if (isRepo) {
	// Repository has no minConfidence param — filter in JS
	edges = dbOrRepo.getCallEdges().filter(e => e.confidence == null || e.confidence >= minConfidence);
	} else {

[carlos-alm]

This is roadmap documentation only — no code changes in this PR. The minConfidence silent-ignore issue for the Repository path was already fixed in PR #462 (merged). The roadmap text here describes future work, not current behavior.

[carlos-alm]

@greptileai

[carlos-alm]

@greptileai