[cvega]

What

Addresses the profiler gaps you spotted: it gathered only the per-feature presence signals, one repo per request, and never the actual content volume. This collects real metadata, batches the second pass, and turns that data into an org-wide scale rollup and the first working blocker.

Changes

1. Content-volume counts in discovery (free)

totalCount is a cheap connection aggregate, and discovery already pages the org's repos 100 at a time. So the discovery query now also pulls each repo's issues, pull requests, branches, and tags counts — gathered "from multiple repos at a time" with zero extra requests, exactly the insight you raised.

2. The augment pass is now batched

The one thing that can't fold into a discovery node is the branch-protection rule detail (node-level flags). That pass was one request per repo; it's now an aliased batch — r0: repository(...) {…} r1: repository(...) {…} — profiling 25 repos per request. An org of N repos drops from N requests to ~N/25. The default-branch commit count (history.totalCount, the one count with timeout risk at 100-wide) rides in this smaller-fanout pass too.

It's partial-failure aware: GraphQL returns a null alias + an errors entry when one repo in a chunk is inaccessible (surfaced by the client as a throw carrying partial data). That repo degrades to zeroed signals from the recovered data instead of failing the whole chunk; the run continues.

3. First working blocker

analyze wires the git-archive-size blocker off diskUsage (flagged ≥ 2 GiB as an estimate to confirm with git-sizer). So blockers is no longer always 0 — genuinely large repos now surface.

4. Migration-scale rollup

getProfileDetail derives an org-wide scale (issues, PRs, commits, branches, tags, releases, total size) by summing the persisted signals on read — no schema change, mirroring the insights pattern — surfaced as a "Migration scale" section on the run page.

Performance

	Before	After
Requests for N repos	discovery (N/100) + augment (N)	discovery (N/100) + augment (N/25)
Content volume collected	none	issues, PRs, commits, branches, tags, releases, size

Testing

• 79 profile tests pass. New/updated coverage: discovery content-count mapping; the batched augment (single request for a chunk, input-order, owner/name-per-alias, null-alias degradation, partial-data recovery on error, rethrow when no recoverable data, empty chunk); runner chunking incl. completed chunks persist when a later chunk fails; the git-archive-size blocker (oversized → blocker, under-threshold → clear, null diskUsage → clear, not a false positive); and the scale rollup summation.
• Full gate suite green (ok: true); coverage 86.58% / 84.65%.
• Runtime smoke: seeded a 2-repo run → /api/profile/:id returns the correct scale (issues:15, commits:150, …), the size-blocker persists, and the page renders the Migration scale tiles.

Design notes / deliberately deferred

• Chunk size 25 balances GitHub's per-request node budget (≤ 25 × 100 rules) and query complexity against the request count; easy to tune.
• Commits via history.totalCount is the one count with timeout risk at scale, so it's in the smaller-fanout batch, not the 100-wide discovery page.
• Size detection beyond the disk-usage proxy (release-asset sizes, git-sizer for commit/file/ref limits) remains a separate heavier pass — still honestly reported as indeterminate, per your earlier "defer git-sizer" call.

Note

Two ProfileRun field comments still say "gaps" (the gap → consideration rename leftover I flagged on the docs PR) — left for a separate tidy.