Methodology
Sector Radar Method
Denominator: in-cluster corpus, N=24. Source: accepted Chrome Extension Starters report, centroid, calibration, and visual-data artifacts. Reader meaning: this page explains how to interpret public labels, samples, limitations, and correction routes.
Principle
Sector Radar asks what a landscape looks like. It does not rank maintainers, detect authorship, or reduce a repository to a single quality score. It maps pattern convergence, differentiation, and category boundaries so builders can understand the sector they are navigating.
Two-Pass Denominator
Pass 1 surveys the candidate corpus for starter traits and category leakage. Pass 2 defines the centroid from the in-cluster subset only. This prevents frameworks, plugins, samples, stale repositories, and finished extensions from distorting the default Chrome Extension Starter pattern.
The final corpus for this report contains 24 in-cluster repositories: 23 strict-intake candidates, minus one stale repo, plus two topic-tag additions. Adjacent tooling remains visible where it affects builder discovery, but it does not define the starter centroid.
Corpus Boundary
A Chrome Extension Starter must be a public GitHub repository intended as a fork-and-build scaffold for new Chrome or Chromium extensions. It must contain a manifest, build tooling, and at least one wired extension surface.
The boundary excludes frameworks installed as dependencies, build plugins, official samples, CLI scaffolders, finished extensions, curated lists, and generic web app starters. CRXJS is a build plugin; a repo using CRXJS can still be a starter. WXT and Plasmo are adjacent frameworks because they impose their own project model.
Scoring Discipline
Scores are evidence summaries, not universal quality judgments. A high Centroid Match score means a project resembles the sector default. It does not mean the project is better. A high Differentiation score means the project brings a distinct pattern beyond the default. It does not mean the project is safer, more mature, or more useful for every user.
Adoption and repository activity are time-sensitive. All scores are frozen at the 2026-05-12 evidence snapshot so the report can be reviewed against a stable record rather than a moving target.
| Dimension | Question |
|---|---|
| CM | How closely does this repo match the sector centroid? |
| DF | What does the repo offer that is observably distinct? |
| HE | How much sustained human engineering is visible? |
| AD | How much adoption signal exists beyond existence? |
| CI | Do claims match implementation evidence? |
Limitations
| Limitation | How this report handles it |
|---|---|
| Search corpus bias | The corpus reflects repositories visible through Chrome extension starter discovery paths. It may miss private, newly published, renamed, or poorly indexed projects. |
| Time-sensitive evidence | Adoption, commits, manifest status, and documentation may change. The report freezes evidence at a stated snapshot date and invites corrections. |
| Framework adjacency | Frameworks such as WXT and Plasmo are excluded as adjacent tooling rather than starter repos. Repos using CRXJS remain eligible because CRXJS is a Vite plugin. |
| Star count distortion | Stars inform Adoption Depth but do not drive role assignment alone. Historical projects can have high adoption and still sit far from the current centroid. |
| Legacy adoption | MV2-era projects remain visible where they are genuine starters, but they are interpreted as historical where appropriate. |
| Public reputational risk | Public language describes sector position and evidence patterns. It does not claim maintainer intent or moral failure. |
Anticipated Objections
"Does high convergence mean these repos are bad?"
No. High convergence can indicate a legitimate standard, a useful default, or a crowded attractor. Interpretation depends on Human-Edge, Adoption Depth, Integrity, and Differentiation.
"Why classify a genuine starter as Adjacent Infrastructure?"
In this report, EmailThis and fregante are genuine starters retained in the corpus. Their Adjacent Infrastructure label is algorithmic: both have CM=2 and sit far from the current 2026 centroid. The label means architectural distance, not exclusion or low quality.
"Why exclude WXT and Plasmo?"
They are frameworks with their own CLI, conventions, and project model. They are important adjacent infrastructure for extension development, but including them would make the centroid describe framework ecosystems rather than fork-and-build starter repositories.
"Are repo labels fair to maintainers?"
The labels are descriptive and evidence-bound. "Baseline Implementation" means a starter is working but thinner in engineering depth at the snapshot date. "Inactive Scaffold" would mean structurally present with little sustained engineering; no repo in this corpus receives that label.
"Why publish individual repo names at all?"
Sector claims need examples and traceable evidence. The report uses repo names to support the map, but it frames the analysis around sector structure rather than surprise public audits of individual maintainers.
Public Language
Public role labels are descriptive: Category Leader, Differentiated Niche, Strong Default, Baseline Implementation, Inactive Scaffold, and Adjacent Infrastructure. Internal competitive labels do not appear in the public report.
Source Artifacts
The methodology page is grounded in Reports/SECTOR-RADAR-CHROME-EXTENSION-STARTERS.md, Manual-audit/CENTROID-CHROME-EXTENSION-STARTERS.md, Manual-audit/CALIBRATION-TABLE-CHROME-EXTENSION-STARTERS.md, Reports/VISUAL-DATA-CHROME-EXTENSION-STARTERS.md, and Manual-audit/AUDIT-TEMPLATE-SECTOR-RADAR-v1.md.
Corrections
If you maintain a project assessed in this report and believe a claim or score is wrong, contact hello@diversum.dev. Include the project, report section, claim or score in question, and evidence for correction.