Read a persisted deep-research report for a repository

Identifier of this report.

The `owner/name` the research was run on.

Whether the research finished.

Why the research failed, when it did. Null on a report that succeeded.

The repository header as read from GitHub at research time: description, topics, primary language, stars, forks, created/pushed instants, license, archived and fork flags.

Who actually builds this, recency-weighted: Push and merged-PR actors over the last year, scored so current maintainers outrank drive-by history. Each row carries the activity counts, first/last seen, whether they own the repo, `depth` (authored vs merged-for-others vs review work in this repository), and — where Vamo knows them — contact-shaped identity facts: name, title, LinkedIn URL, resolved city and country, raw location, company, cracked score 0-100 with its tier, gem score, seniority, years of experience, and `hasEmail` (the address itself is a paid facet).

The earliest recorded starrers — who was there before the crowd, oldest first, hydrated with the same identity facts. Dataset coverage starts 2023, so for older repos this is "earliest recorded", not "earliest ever". Absent on reports produced before it was recorded.

A sample of the repo’s most recent starrers, hydrated with the same identity facts, so the CURRENT audience is readable person by person next to the `starPlacements` bands that summarise it.

The repo’s most recent forkers, dated and hydrated with the same identity facts as `starrers`. Forks are the audience surface GitHub left open when it closed repo-side stargazer enumeration in 2026, so on a repo whose recent stars can no longer be read this list IS the current audience. Absent on reports produced before forkers were captured.

How this repo’s star audience places against the wider field of scored repositories, as formatted bands. This is the read for "is this project respected by people who build, or just popular": `audienceWeight` for the authority behind the audience, `audienceShare` for how much of it are builders rather than passers-by, and `authenticity` for whether the stars arrived the way real discovery arrives. Null when the repo is not scored, and absent on reports produced before placements were recorded — in both cases absence of a measurement, never a bad result.

Work-distribution, succession, and momentum measurements over the FULL contributor set (not just the recency-weighted top slice above), anchored per-repo at that repo’s own last contribution: how many people carry half/80% of the work, the top-1/3/5 concentration shares, a Gini coefficient, quarter-over-quarter builder and activity momentum ratios, and contributor retention. Every flat field above measures HOW CONCENTRATED the building is and is blind to who does it; the nested `contributorQuality` block adds that axis, weighting the same work by each contributor’s cracked score (`eliteWorkMass`/`eliteWorkShare`, with `scoredContributors`/`scoredWorkShare` as their own coverage denominators, since an unscored contributor is outside the scored population rather than a weak one). It is nested because its POPULATION is different: the ranked top slice the `contributors` array carries, never the full set the flat fields aggregate, so the two are never averaged or compared. It rides here whenever contributors surfaced, including when the full-set measures did not. Null on reports computed before this measure existed.

Distinct ACTIVE contributors per calendar month over the trailing year: `{ status: "ok", measure, source, months: [{ month, contributors }] }`. An activity trend, never a cumulative "contributors ever" total — it goes DOWN when a repo gets quieter, and `measure` names what the numbers are so a reader cannot relabel a decline as growth. `status: "ok"` with an empty `months` is a MEASUREMENT (the query ran, the repo had no in-window activity); `{ status: "query_failed" }` is not a measurement at all and is worth re-asking. Null means only that the report predates this measure, and a report written between it landing and the status wrapper carries the bare `{ measure, source, months }` object instead.

The `forkers` and `starrers` lists re-aggregated into a month-by-month audience curve: ascending contiguous `months` of `{ month, forkers, scoredForkers, forkerEliteMass, starrers, scoredStarrers, starrerEliteMass }`, plus the `forkersTotal`/`forkersScored`/`starrersTotal`/`starrersScored` denominators behind them. Raw counts are the primary signal; the elite-mass fields are a partial-coverage overlay that weights each month’s audience by what those people build themselves, which is why each carries its own scored denominator rather than being averaged in. A month is `null` when NO source observed it (the frozen mirror and the live graph cover disjoint eras) and `0` only when a source did cover it and saw nothing, so a gap in the curve is never a quiet month. Null overall when neither list carried dated rows, and absent on reports produced before this was computed.

Whether the CODE moves, where the audience curves say only who is watching: GitHub’s trailing-52-week commit rollup bucketed into `{ month, commits, weeks }` per calendar month. A verdict object rather than a bare trend, because the three ways there is no trend are three different facts. `{ status: "ok", months }` is measured, and a year of `commits: 0` there is a real finding about the repo. `{ status: "not_computed" }` means GitHub had not built the series when we asked (its stats endpoints answer a cold repo with an empty 202, and the ask itself warms it), so the next dive of the same repo likely gets it — never read it as a zero-commit year. `{ status: "unavailable" }` means the ask failed outright and says nothing about the repo. `weeks` is each month’s coverage denominator: a 52-week window opens and closes mid-month, so the first and last buckets hold fewer weeks and would otherwise read as a slump. Null when the report predates this measure; a report written between it landing and the verdict shape carries a bare ARRAY of months, which reads as `ok`.

WHAT-domain tags (fintech, mobile, devtools) read off this repo’s topics + description + manifest dependencies — never the README body, which has no cross-repo repetition to corroborate a loose match against for a single repo. Null on reports produced before this field existed.

HOW-it-builds tags (react, rust, kafka) read the same way as `subjects`, same vocabulary as a developer report’s `technologies`, computed alongside `subjects` but never blended in. Null on reports produced before this field existed.

The dataset instant the contributor and starrer windows end at.

The dataset instant the contribution (push/merged-PR) window ends at — later than `anchor`, since contribution data lags star data. Empty on reports computed before this measure existed.

How many contributors the report carries, strongest first. Every builder in the window on current reports (up to 10,000); 300 or 30 on older ones.

TOTAL distinct human contributors in the window. `contributors` is the top slice; this says what the cap hid. 0 on reports produced before it was recorded.

How many recent starrers were sampled.

TOTAL distinct starrers in the sample window. 0 on reports produced before it was recorded.

How many recent forkers were sampled and hydrated into `forkers`. 0 on reports produced before forkers were captured.

TOTAL forks GitHub reports for the repo (its own `forkCount`), not just the sampled slice — the denominator that says whether `forkers` is the whole audience or the most recent face of it. 0 on reports produced before it was recorded.

How many surfaced people resolved to a known identity in Vamo’s index — the denominator behind the hydrated facts.

When the research started, as an ISO 8601 instant.

When the research finished, as an ISO 8601 instant.

The people who merge and review other people’s pull requests but rarely push, so they do not rank among `contributors`, each with the same `person` block. Empty when the report predates contributor depth.