Skip to content

Merge-order guide for the open PR backlog (4 refactor PRs unblock the rest) #120

@andreinknv

Description

@andreinknv

Maintainer guide: how to merge the open PR backlog with minimal friction

Update — April 28, 2026: 14 of my PRs have been pre-rebased onto the post-refactor patterns. The agent-callable code-intelligence layer is fleshing out: #124 (per-symbol coverage from lcov reports) and #125 (static-analysis biomarkers + Code Health score) add two new MCP tools so an AI agent can ask "is this function tested?" and "is this function risky to change?" with a single structured query, instead of reading the source. Both stack on #118 (file-based migrations); #125 also runs as an IndexHook. #122 remains a tiny self-contained perf win in monolithic shape that targets main directly. See the rebase summary comment for the full list. The rebase templates below remain authoritative documentation for external PRs (#58, #91, #89) and for any future PR that needs to land on top of the refactors.


There are ~24 open PRs touching colbymchenry/codegraph. Many of them collide on the same handful of monolithic data structures (lists, switches, version numbers, hardcoded method additions). I've opened 4 refactor PRs that eliminate those collision surfaces. This document tells you the order to merge things in to minimize manual conflict-resolution work, and shows you exactly what the rebase of every existing open PR looks like.


Easiest path for the maintainer: 12 clean merges in 4 rounds

I walked this path end-to-end against a fresh colbymchenry:main checkout three times to confirm — twice with intermediate rebases that broke things in subtle ways, then once cleanly. 12 explicit merges, zero hand-resolution. 829/829 tests pass at the tip. Final state matches andreinknv:integration/all-prs (22 MCP tools, 8 hooks, 18 migrations).

Round 1 — five PRs clean against current main, any order

PR What
#116 refactor: per-language registry
#117 refactor: per-tool MCP registry
#118 refactor: file-based migrations
#119 refactor: index-hook framework
#127 fix(gitignore): anchor coverage/ to repo root

Round 2 — three PRs clean once Round 1 is in

PR Why it's now clean
#92 HCL/Terraform language — needs #116
#94 R language — needs #116
#95 SQL language — needs #116

Round 3 — one anchor merge that brings in 18 PRs at once

PR Effect
#124 per-symbol coverage. This PR's branch carries the entire Phase-4 chain as its base (#102, #105, #106, #110, #111, #112-port, #113, #114, #115, #122-port, #123) plus the 5 Phase-1 fixes that touch src/extraction/index.ts (#93, #100, #101, #103, #104) plus #96, #97, #98, #99, #107, #108, #109. One merge → 18 PRs land as ancestors, each preserved as a merge commit in #124's history.

Round 4 — three PRs, in this order

Order matters for Round 4: #125#126#121. The reason: #125 is now stacked on feat/coverage, so it fast-forwards over #124's anchor commit cleanly. #126 and #121 have non-overlapping changes if #125 is in first.

  1. feat(biomarkers): static-analysis Code Health findings + codegraph_biomarkers MCP tool #125 biomarkers — fast-forward (its branch is feat/coverage + one biomarkers commit)
  2. feat(mcp): surface project root in codegraph_status + actionable errors #126 mcp-default-project-hint — clean (touches tools.ts and tools/status.ts in non-overlapping ways)
  3. feat(mcp): emit server-level instructions in initialize response #121 mcp-server-instructions — clean (rebased onto post-refactor: per-tool MCP registry — eliminate tools[] + case-switch conflicts #117, uses registry pattern)

After Round 4 — closing the rest

These 21 PRs have their content already on main via Round 3's ancestor chain. Each can be closed with a one-line "merged via #124's ancestor chain — see #120" comment, or you can gh pr merge each individually for per-PR attribution badges (most will be Already up to date):

#93, #96, #97, #98, #99, #100, #101, #102, #103, #104, #105, #106, #107, #108, #109, #110, #111, #113, #114, #115, #123

Two PRs land as content-only (no branch-tip ancestor):

External-contributor PRs not part of this path: #52, #57, #58, #66, #80, #89, #91 — these need the original contributor to rebase or accept a co-authored rebase. Templates for that work below.


Alternative path: full per-PR attribution (no anchor)

If you want every PR branch to be a true git ancestor (so git log --merges shows all 35 PRs as separate merge commits, including #112), skip #124 as anchor and merge each PR directly. Same end-state (829/829 tests), more merge commits, ~9 hand-resolutions on shared files.

Easiest way: run the script

A bash script automates the entire 21-merge sequence with auto-resolution. Maintainer's effort drops to ~3 minutes.

git switch -c merge/all-prs colbymchenry/main          # or wherever your main is
curl -fsSL https://raw.githubusercontent.com/andreinknv/codegraph/tools/merge-helper/scripts/merge-all-prs.sh | bash
npm run build && npm test                              # expect 829/829
git push origin merge/all-prs                          # then click "Merge into main" once

The script:

  • Adds the andreinknv remote if missing, fetches all PR branches.
  • Walks Step A → J in order, doing git merge --no-ff for each PR.
  • For the 9 PRs with shared-file conflicts, automatically runs git checkout andreinknv/integration/all-prs -- <conflicted files> and commits.
  • Runs the final tools.ts dedup step after Step J.
  • Refuses to start with uncommitted changes or a merge in progress (idempotent: reset and re-run).

Source: andreinknv:tools/merge-helper:scripts/merge-all-prs.sh — verified end-to-end on a fresh colbymchenry:main checkout, produces 35/35 ancestors and the same final tree as integration/all-prs.

Why this is harder than the easy path (manual)

Phase-4 PRs (#105, #106, #111, #112, #113, #114, #115) genuinely share src/db/queries.ts, src/db/schema.sql, src/index.ts, and src/mcp/tools.ts — each adds methods/tables/handlers to the same shared resources. Their pairwise conflicts are real semantic overlaps, not branch-divergence artifacts. The script above resolves each by checking out the integration branch's pre-validated combined version, which is why it just works.

Three PR branches were rebased to make this path tractable: #121 onto post-#117, #122 to file-based-migration form, #125 stacked on #124. (#93 and #110 were reverted to their original SHAs after testing showed the rebases broke their "ancestor of #124's chain" property — the close-out story matters more than the per-PR clean merge for those two.)

Sequence (verified end-to-end)

I walked this against a fresh colbymchenry:main. Counts below are exact files-conflicted.

Step PRs What actually happened
A #116, #117, #118, #119, #127 all clean ✓
B #92, #94, #95 all clean ✓
C #96, #97, #98, #99, #107, #108, #109 all clean ✓
D #93 hand-resolves on 3 files (src/types.ts, src/extraction/index.ts, __tests__/sync.test.ts) — git checkout integration/all-prs -- <files>. #100, #101, #103, #104 then become clean (their conflict was with #93's pre-rebase form, not pairwise). 1 hand-resolution, 4 auto-clean
E #110 hand-resolves on 2 files (src/index.ts, src/mcp/tools.ts). Same shortcut.
F #102 clean ✓ ; #122 hand-resolves on 3 files (__tests__/foundation.test.ts, __tests__/pr19-improvements.test.ts, src/db/migrations/index.ts) — its file-based port adds migration 017 which conflicts with the registry index expecting it not to be there yet. 1 hand-resolution
G #105 (7 files), #106 (1 file), #111 (7 files) — each hand-resolves 3 hand-resolutions
H #112 hand-resolves on 12 files (the biggest single conflict). After this lands, #113, #114, #115 become ancestors automatically — no merge needed for them. 1 hand-resolution
I #123 (4 files), #124 (8 files), #126 (1 file) — each hand-resolves 3 hand-resolutions
J #125 fast-forward ✓ ; #121 clean ✓ 0 hand-resolutions

Final cleanup step (caveat the doc previously missed): the iterative git checkout integration/all-prs -- <file> approach can leave duplicate symbols in src/mcp/tools.ts (the same handler/import added by multiple steps' integration files). Run one final git checkout integration/all-prs -- src/mcp/tools.ts after Step J to dedupe. Tests pass before the cleanup; only tsc complains.

End-state (verified):

Why the easy path is still the default recommendation: the anchor approach (12 clean merges) gets the maintainer to the same green-test state in ~5 minutes of click-merge work. The no-anchor alternative is ~30-45 minutes of git checkout integration/all-prs -- <file> invocations for marginal benefit on attribution badges. Only worth it if those badges matter to you for #112 specifically.


The merge order, by phase

The phases below are the conceptual structure the rest of this document references — every dependency table, every rebase template assumes them. The "Easiest path" above collapses these phases into 4 rounds; this list shows the underlying grouping.

Phase 1: easy wins (any order, no shared state)
  #109  watcher flake fix
  #96   docs: non-Claude clients
  #97   docs: language cookbook
  #93   git submodules
  #98   correctness bugs
  #99   defense-in-depth hardening
  #100  HEAD-move sync detection
  #101  extraction/resolution accuracy
  #103  .codegraphignore on git fast path
  #104  FTS stemming/subwords
  #107  search per-file diversification
  #108  perf db cache fix
  #110  review-context MCP tool   (requires #117 first; already rebased onto the post-#117 pattern)

Phase 2: the 4 unblockers (any order, fully independent of each other)
  #116  refactor: language registry
  #117  refactor: MCP tool registry
  #118  refactor: file-based migrations
  #119  refactor: index-hook framework

Phase 3: language PRs — each rebases onto #116 (1-file changes)
  #92   HCL/Terraform
  #94   R
  #95   SQL
  #91   Scala (firehooper)
  #66   Vue (abhijeetj100)
  #58   ReScript (malo)
  #57   mql5 (cfournel)
  #80   pgsql similarity search (bhushan)
  #89   framework route extraction (timomeara)

Phase 4: schema-touching feature PRs — rebase onto #118 + #117 + #119
  #102  UNIQUE on edges
  #105  cochange-graph
  #111  LLM features (4 migrations)
  #112  centrality + churn
  #113  issue-history
  #114  config-refs
  #115  sql-refs
  #122  perf: drop redundant edge indexes (still in monolithic shape — apply Phase 4 cochange template)
  #123  perf: split embeddings + in-memory cache + drop redundant co_changes index (already in file-based shape; depends on #105 + #111)
  #124  feat: per-symbol coverage from lcov + codegraph_coverage MCP tool (file-based migration; depends on #118)
  #125  feat: static-analysis biomarkers + Code Health + codegraph_biomarkers MCP tool (file-based migration + IndexHook; depends on #118 + #119)

Phase 5: misc
  #52   Cursor IDE installer

The four refactors in Phase 2 don't conflict with each other and can be reviewed and merged in any order. Once they're in, every remaining open PR becomes a small, focused, mostly-additive diff.


Why these 4 refactors exist

Every "feature" PR currently fights one of four shared bottlenecks. Each refactor turns the bottleneck into a "drop one file" pattern.

Refactor PR Eliminates Affected PRs
#116 language registry src/types.ts Language union + DEFAULT_CONFIG.include + src/extraction/grammars.ts (WASM_GRAMMAR_FILES, EXTENSION_MAP, getLanguageDisplayName) + src/extraction/languages/index.ts EXTRACTORS map + src/extraction/tree-sitter.ts extractor dispatch #92, #94, #95, #91, #66, #58, #57 (7 language PRs)
#117 MCP tool registry src/mcp/tools.ts tools[] array + case switch in execute() #110, #112, #114, #115 (4 PRs adding MCP tools)
#118 file-based migrations src/db/migrations.ts CURRENT_SCHEMA_VERSION constant + monolithic migrations[] array (and the silent-data-loss bug class where two PRs claiming the same v4 silently no-op the second one) #102, #105, #108, #111, #112, #113, #114, #115 (8 PRs adding schema migrations)
#119 index-hook framework CodeGraph.runDerivedSignals / runIssueHistoryPass / runConfigRefsPass / runSqlRefsPass private methods + their call sites in indexAll and sync #105, #112, #113, #114, #115 (5 PRs adding derived-signal passes)

Each refactor PR ships with:

  • Behavior-preserving changes only (no migrations, no API breaks).
  • Backward-compat re-exports so existing imports keep working unchanged.
  • Structural-invariant tests that fail loudly if a future PR drifts from the registry pattern.
  • A reviewer pass with at least one bug caught and fixed.

Phase 1: 13 PRs that don't conflict with anything

These are small fixes, docs, or features that don't touch the bottleneck files. Merge in any order. One caveat: #110 requires #117 first (it adds an MCP tool, so it must land after the MCP tool registry refactor). #110 is already pre-rebased onto that pattern, so once #117 merges, #110 needs no further rebase work — that's why it appears in the Phase 1 list (no contributor action required).

PR What it does Notes
#109 Adds settle delay to fix fs.watch flake in __tests__/watcher.test.ts This is the watcher test that flakes intermittently across the whole codebase — landing this stops the noise on every CI run
#96 README setup for opencode, Cursor, LangChain, Agent SDK Pure docs
#97 Cookbook for adding a new language Pure docs (worth a re-read after #116 lands so it teaches the new pattern)
#93 Index files inside git submodules Self-contained sync feature
#98 Correctness bugs (Svelte off-by-one, watcher dropped changes, traversal defaults, context clamping) Multiple small fixes
#99 Defense-in-depth hardening (path validation, atomicity, ReDoS, worker lifecycle) Multiple small fixes
#100 Detect HEAD-moving git operations to prevent stale index Self-contained sync feature
#101 Extraction/resolution accuracy (BOM, retry strip, framework regex) Multiple small fixes
#103 Honor .codegraphignore on git fast path Self-contained scan feature
#104 Subword tokens + Porter stemmer + stopword filter for FTS Self-contained search feature
#107 Search per-file diversification Self-contained search feature
#108 Perf: batch node lookups, fix insertNode cache, auto-ANALYZE after writes Touches src/db/queries.ts only
#110 codegraph_review_context MCP tool Requires #117 first. Already pre-rebased onto the post-#117 pattern; no contributor action — mergeable as soon as #117 lands.

Phase 2: the 4 refactors

Open PRs:

They don't conflict with each other. Pick any order. Each is a self-contained refactor with no behavior change, full backward compat, and structural-invariant tests.

Preview branch — what main looks like after all 4 land:
andreinknv:preview/all-four-refactors-merged — branched from colbymchenry:main, the four refactor branches merged in sequence (#117#118#119#116). 417/417 tests pass at the tip (380 baseline + 37 new structural-invariant tests across the four refactors). Each refactor PR also has a maintainer review checklist pinned at the top of its description.

Recommended review order if you want to validate one at a time:

  1. refactor: per-language registry — eliminate cross-PR conflict surface for language additions #116 (language registry) is the easiest to mentally verify — the language list moves into per-file definitions; EXTRACTORS becomes derived from the registry. 16 invariant tests pin down the equivalence.

  2. refactor: file-based migrations — eliminate silent version-collision bugs #118 (migrations) is the highest-impact safety win — it eliminates a silent-data-loss bug class. Two PRs both claiming v4 used to result in "second one's migration silently no-ops on existing DBs." Now their filenames collide on the filesystem instantly. Reviewer caught a hand-typed-version-vs-filename drift bug; fixed by parsing version from filename.

  3. refactor: per-tool MCP registry — eliminate tools[] + case-switch conflicts #117 (MCP tools) is a partial extraction — tools[] array and case switch are gone, but handler bodies still live in ToolHandler. Adding a new tool drops from a 4-way conflict to a 1-way conflict (a method addition). Full body extraction is a follow-up.

  4. refactor: index-hook framework — eliminate per-pass CodeGraph mutations #119 (index hooks) ships with zero registered hooks — it's pure scaffolding for feat(cochange): file-level co-change graph mined from git history #105 / feat(graph): PageRank centrality + per-file churn metrics #112-feat(graph): sql_refs — SQL string-literal call sites (pairs with #95) #115. The framework runs no-ops on main; it only earns its keep when those PRs rebase onto it.

After all four land, Phases 3-5 become much simpler.


Phase 3: language PRs — every rebase looks the same

Pre-requisite: #116 must be merged first.

Rebase status:

Every open language PR currently edits 6 monolithic lists across src/types.ts, src/extraction/grammars.ts, CLAUDE.md, and __tests__/extraction.test.ts. After #116, the rebase is mechanical:

Rebase template (concrete: HCL = #92)

git checkout feat/hcl-terraform-support
git rebase main   # post-#116 main

# You will hit conflicts on every monolithic file. Resolve by DELETING
# the existing additions and creating one new file instead:

Step 1. Discard the conflicting edits:

git checkout main -- \
  src/types.ts \
  src/extraction/grammars.ts \
  src/extraction/languages/index.ts \
  CLAUDE.md \
  __tests__/extraction.test.ts

Step 2. Create one file at src/extraction/languages/hcl.ts:

import { hclExtractor } from './hcl-extractor-config';  // Or reuse your existing extractor file
import type { LanguageDef } from './types';

export const HCL_DEF: LanguageDef = {
  name: 'hcl',
  displayName: 'HCL / Terraform',
  extensions: ['.tf', '.tfvars', '.hcl'],
  includeGlobs: ['**/*.tf', '**/*.tfvars', '**/*.hcl'],
  // For grammar-backed languages:
  // grammar: { wasmFile: 'tree-sitter-hcl.wasm', vendored: true, extractor: hclExtractor },
  // For custom-extractor languages (HCL has its own extractor):
  customExtractor: (filePath, source) => new HclExtractor(filePath, source).extract(),
};

Step 3. Add 2 lines to src/extraction/languages/registry.ts:

import { HCL_DEF } from './hcl';        // alphabetical: between c-cpp and impact
// ...
const ALL_DEFS: readonly LanguageDef[] = [
  // ...
  HCL_DEF,
  // ...
];

Step 4. (Optional) If HCL needs language-specific narrowing in src/resolution/index.ts or src/resolution/import-resolver.ts, add 'hcl' to the Language union in src/types.ts. Most languages don't need this.

Step 5. Keep your test additions in their original __tests__/extraction.test.ts describe block — those don't conflict with anything (the language registry refactor doesn't touch tests).

The diff size goes from "6 files modified" to "1 new file + 2 lines in registry.ts" (+ optional 1 line in Language union).

Same template applies to #94 R, #95 SQL, #91 Scala, #66 Vue, #58 ReScript, #57 mql5. Each language gets its own file; no two languages conflict if their alphabetical positions in registry.ts aren't adjacent.

#80 pgsql similarity and #89 framework route extraction aren't language PRs — they don't need this template. Land them in Phase 1.


Phase 4: schema-touching feature PRs

Pre-requisite: #118 must be merged first (and ideally #117 + #119 too, for PRs that also touch MCP tools or sync hooks).

Rebase status

The template below remains the canonical "how to add a schema-touching feature on top of refactors" reference.

Rebase template (concrete: cochange = #105)

The cochange PR currently adds:

  • version: 4 entry to migrations[] in src/db/migrations.ts
  • Bumps CURRENT_SCHEMA_VERSION to 4
  • A runDerivedSignals-style hook into CodeGraph.indexAll and sync
  • New tables to src/db/schema.sql
  • A new src/cochange/index.ts module

After Phase 2 lands, the rebase becomes:

Step 1. Move the migration body to its own file:

# Find the next free 3-digit prefix:
ls src/db/migrations/[0-9]*.ts
# 002-project-metadata.ts
# 003-lower-name-index.ts
# → next free is 004

Create src/db/migrations/004-cochange-graph.ts:

import type { MigrationModule } from './types';

export const MIGRATION: MigrationModule = {
  description: 'Add co-change graph: per-file commit_count + co_changes table',
  up: (db) => {
    // ... your existing migration body, copied verbatim ...
    const cols = db.prepare(`PRAGMA table_info(files);`).all() as Array<{ name: string }>;
    if (!cols.some((c) => c.name === 'commit_count')) {
      db.exec(`ALTER TABLE files ADD COLUMN commit_count INTEGER NOT NULL DEFAULT 0;`);
    }
    db.exec(`
      CREATE TABLE IF NOT EXISTS co_changes (
        file_a TEXT NOT NULL,
        file_b TEXT NOT NULL,
        count INTEGER NOT NULL,
        PRIMARY KEY (file_a, file_b),
        CHECK (file_a < file_b)
      );
      CREATE INDEX IF NOT EXISTS idx_co_changes_a ON co_changes(file_a);
      CREATE INDEX IF NOT EXISTS idx_co_changes_b ON co_changes(file_b);
    `);
  },
};

Step 2. Register it in src/db/migrations/index.ts:

import { MIGRATION as MIG_004 } from './004-cochange-graph';

const REGISTERED_MODULES: readonly ModuleRef[] = [
  { filename: '002-project-metadata.ts', module: MIG_002 },
  { filename: '003-lower-name-index.ts', module: MIG_003 },
  { filename: '004-cochange-graph.ts',   module: MIG_004 },
];

Step 3. Drop the CURRENT_SCHEMA_VERSION bump from your PR. It's auto-derived from the registry now.

Step 4. Move the runDerivedSignals integration to a hook file src/index-hooks/cochange.ts:

import type { IndexHook, IndexHookContext } from './registry';
import type { SyncResult } from '../extraction';
import { mineCoChanges, applyCoChangeDeltas, ... } from '../cochange';
import { logDebug } from '../errors';

export const HOOK: IndexHook = {
  name: 'cochange',
  async afterIndexAll(ctx) {
    if (ctx.config.enableCoChange === false) return;
    // Move the body of your old runCoChangePass here.
    // Use ctx.queries / ctx.projectRoot / ctx.config.
  },
  async afterSync(ctx, result) {
    if (ctx.config.enableCoChange === false) return;
    // Same, but for incremental sync.
  },
};

Step 5. Register the hook in src/index-hooks/registry.ts:

import { HOOK as COCHANGE_HOOK } from './cochange';

const REGISTERED_HOOKS: readonly IndexHook[] = [
  COCHANGE_HOOK,
];

Step 6. Drop the runDerivedSignals private method from src/index.ts and the call sites in indexAll / sync. The hook runner already wires up your hook.

Same template applies to #112 centrality+churn, #113 issue-history, #114 config-refs, #115 sql-refs, #102 UNIQUE on edges (only the migration step), #108 perf db (if it adds indexes), #111 LLM features (4 migrations: pick 4 free prefixes).

For PRs that also add MCP tools (#112 hotspots, #114 config, #115 sql), follow the MCP tool registration addendum below.


MCP tool registration addendum (Phase 3 + 4 PRs adding tools)

After #117 lands, adding a new MCP tool is:

Step 1. Create src/mcp/tools/<name>.ts:

import { projectPathProperty } from '../tool-types';
import type { ToolModule } from './types';

export const HOTSPOTS_TOOL: ToolModule = {
  definition: {
    name: 'codegraph_hotspots',
    description: '...',
    inputSchema: { type: 'object', properties: { /* ... */, projectPath: projectPathProperty } },
  },
  handlerKey: 'handleHotspots',
};

Step 2. Add 2 lines in src/mcp/tools/registry.ts:

import { HOTSPOTS_TOOL } from './hotspots';
// ...
const ALL_TOOLS: readonly ToolModule[] = [
  // ... alphabetical
  HOTSPOTS_TOOL,
  // ...
];

Step 3. Add the new key to HandlerKey union in src/mcp/tools/types.ts:

export type HandlerKey =
  | 'handleSearch'
  | // ...existing keys...
  | 'handleHotspots';

Step 4. Add async handleHotspots(args: Record<string, unknown>): Promise<ToolResult> { ... } on ToolHandler in src/mcp/tools.ts. The case switch is gone — execute() finds your handler via the registry.

The ToolHandler implements ToolHandlerLike constraint catches the case where you add a key to HandlerKey but forget to implement the method (compile-time error).


Validation steps (apply after every PR lands)

npm run build                               # tsc + asset copy
npm test                                    # full suite — no flake on CI; the watcher test is the one known flake (PR #109 fixes it)

# After #116 (language registry):
node -e "console.log(require('./dist').getSupportedLanguages())"
node -e "console.log(require('./dist/types').DEFAULT_CONFIG.include.length)"

# After #118 (migrations):
node -e "
  const { CURRENT_SCHEMA_VERSION, ALL_MIGRATIONS } = require('./dist/db/migrations');
  console.log('Versions:', ALL_MIGRATIONS.map(m => m.version));
  console.log('Current:', CURRENT_SCHEMA_VERSION);
"

# After #117 (MCP tools):
node -e "console.log(require('./dist/mcp/tools/registry').getToolModules().map(m => m.definition.name))"

Status (April 28, 2026)

Rebases done — no contributor action required:

Still TODO (mine):

Still TODO (external contributors — friendly nudge needed):

Still TODO (CONFLICTING per GitHub — need contributor rebase to current main):

Validation (April 28, 2026): all 30 mergeable PRs stacked together as andreinknv:integration/all-prs — built fresh from colbymchenry:main via 18 sequential merges. 829/829 tests pass, 8 index-hooks fire, 22 MCP tools register, 18 migrations apply cleanly. indexAll + sync round-trip on 4 real codebases (codegraph itself, asf-platform, asf-dashboard, mcp-obsidian-extended).

Of the 35 PR branches: 33 are direct ancestors of integration/all-prs via merge commits. The 2 exceptions — #112 (centrality+churn) and #122 (drop-redundant-edge-indexes) — have their content present via post-refactor port commits in the integration history but their original branch tips aren't ancestors. This is intentional: #122 is documented above as remaining in monolithic shape targeting main directly, and #112 was rebased onto post-refactor patterns as a separate commit chain. Both PRs' code is exercised by the test suite via the integration.

Findings from rebuilding the integration from scratch (worth knowing for the merge order):

(Earlier integration runs measured 757/757 tests + 13 tools + 7 hooks; the deltas are #124, #125, #126, #121, plus the 16 invariant tests added by #116's reviewer pass.)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions