repo-pulse

RepoPulse — Product Definition

Repo: arun-gupta/repo-pulse
Description: OSS Health Score — measures the health of open source projects with percentile-based scoring calibrated against 1600+ GitHub repositories. Produces a composite health score from Activity, Responsiveness, and Sustainability dimensions with actionable recommendations.
Phase 1 Platform: Next.js deployed on Vercel
Phase 1 Data Layer: Next.js API Routes
Development Methodology: SpecKit / Specification-Driven Development (SDD)

This document is the canonical product definition for RepoPulse. It is the source of truth for all features across all phases. .specify/memory/constitution.md references this document. SpecKit specs are traceable to feature IDs defined here.

Roadmap

Phase 1 — Web app + core scoring ✅

Interactive Next.js dashboard on Vercel with OSS Health Score from three scoring buckets (Activity, Responsiveness, Sustainability), percentile-based scoring calibrated against 1600+ repos, and actionable recommendations.

Phase 2 — Expand scoring dimensions

Add new scoring buckets (Documentation, Security, Community, Release Health, Development Cadence, Project Maturity) to the health score. Requirements specs live in linked GitHub issues.

Phase 3 — Integrations

Deliver the OSS Health Score through additional channels (GitHub Action, MCP Server, CLI, badge, PR bot, VS Code extension, webhooks), wrapping the shared analyzer module.

Phase 4 — Git provider support

Provider abstraction layer for GitLab, Bitbucket, and Gitea support alongside GitHub.

Data Source

GitHub GraphQL API (https://api.github.com/graphql) is the primary data source.

Fetches all required metrics in 1–3 requests per repo vs. 10–15 REST calls
Precise field selection — no over-fetching
Single auth mechanism: GitHub Personal Access Token with repository read access sufficient for the required GraphQL and REST calls
REST API may supplement only where GraphQL cannot reach a specific metric
GITHUB_TOKEN is always read from environment — never hardcoded

OSS Health Score

RepoPulse computes a composite OSS Health Score from weighted scoring buckets. Each bucket produces a percentile score (0–99) relative to repos in the same star bracket, calibrated against 1600+ real GitHub repositories.

Implemented buckets

Bucket	Weight	What it measures	Derived from
Activity	36%	PR flow, issue flow, commit cadence, completion speed, release frequency	Weighted composite of 5 sub-scores
Responsiveness	36%	Response times, resolution speed, maintainer signals, backlog health, engagement quality	Weighted composite of 5 sub-scores
Sustainability	28%	Contributor concentration (top 20% commit share)	Inverted percentile of concentration ratio

Planned buckets (Phase 2)

See Phase 2 roadmap for the full list. Weights are rebalanced as new buckets are added.

Ecosystem profile

Three additional percentile dimensions are shown on the scorecard but not included in the health score composite:

Dimension	Metric	Purpose
Reach	Star count percentile	Project visibility and adoption
Attention	Watcher-to-star ratio percentile	Active follower interest
Engagement	Fork-to-star ratio percentile	Builder participation

Scoring methodology

All scores are percentile-based, not categorical. The scoring methodology, calibration data, and statistical approach are documented in docs/scoring-and-calibration.md.

Scores are assigned only when sufficient verified data exists. Otherwise: "Insufficient verified public data".

Accuracy Policy

Every metric must come from a verified public GitHub GraphQL API response
No estimation, interpolation, inference, or fabrication — ever
Missing data is acceptable and marked "unavailable" — invented precision is not
Never substitute one metric for another
Organizational diversity is surfaced as "Could not verify contributor organization publicly" when not inferable — never approximated

Phase 1 — Web App (Next.js / Vercel)

Stack

Framework: Next.js 14+ (App Router)
Deployment: Vercel — zero-config
Styling: Tailwind CSS
Visualization: Spectrum/profile UI via React components
Stateless — no database, no auth system, all analysis is on-demand

API Contract

POST /api/analyze
Body:     { "repos": ["owner/repo", ...], "token"?: "ghp_..." }
Response: { "results": AnalysisResult[] }

POST /api/analyze-org
Body:     { "org": "github-org", "token"?: "ghp_..." }
Response: { "org": "github-org", "results": OrgRepoSummary[] }

Server-side token (GITHUB_TOKEN env var) takes precedence. If absent, token is supplied client-side from localStorage. Token is never included in URLs or exposed to the client bundle.

Planned Features

Each feature is the unit of a SpecKit spec — one feature maps to one spec file. Acceptance criteria define the testable surface. Features are behavioral contracts, not implementation tasks.

Phase 1 — Web App

`[P1-F01]` Repo Input

User can provide one or more GitHub repositories for analysis.

Acceptance criteria

Textarea accepts one owner/repo slug per line, or comma-separated, or full GitHub URLs (https://github.com/owner/repo) — slug is extracted automatically
Client-side validation rejects malformed slugs before submission (owner/repo pattern, trims whitespace)
Empty submission is blocked with an inline error
Duplicate slugs are removed client-side before passing to the data fetching layer
Valid input is passed to the data fetching layer unchanged

Out of scope

Saving or persisting repo lists across sessions
Browsing or searching GitHub repos from within the UI

`[P1-F16]` Org-Level Repo Inventory

User can provide a GitHub organization and get a high-level inventory of its public repositories.

Acceptance criteria

Input accepts a top-level GitHub org slug or GitHub org URL and normalizes it to the org name before submission
App fetches the org’s public repositories using public GitHub metadata only
Results render in a sortable table with one row per repo
Every visible column supports ascending and descending local sorting without rerunning the org request
Table includes at least: repository name, description, primary language, stars, forks, watchers, open issues count, last pushed date, and repo URL
Users can choose which optional columns are visible while Repository remains pinned
Table supports lightweight filtering by repo name, language, and archived status
Large org inventories support local pagination controls with configurable rows per page
Org-level summary area shows high-level rollups such as total public repos, total stars, most-starred repos, most recently active repos, language distribution, and archived vs active repo count
Each repo row links into the existing repo-level analysis flow so users can drill into a specific repository
Users can select any number of repositories from the org inventory table and launch the existing repo-analysis flow for that selection; the queued org-aggregation pipeline handles rate-limit and progress concerns, so there is no per-selection cap
Empty orgs, invalid orgs, and rate-limit states are handled clearly without fabricating results
Once an org analysis run completes, the org-summary view exposes a tabbed result area whose tab strip mirrors the per-repo Results Shell (Overview, Contributors, Activity, Responsiveness, Documentation, Security) plus an org-only Governance tab, positioned between Documentation and Security, that gathers org-level hygiene and policy signals (org admin activity, designated maintainers, governance file presence, license consistency). The Governance tab is org-summary-only — there is no per-repo Governance tab.
The org-summary strip also includes a Recommendations tab positioned after Security (issue #359). It aggregates the per-repo recommendation catalog into top systemic issues across the analyzed repo set, grouped by CHAOSS dimension (Activity, Responsiveness, Contributors, Documentation, Security), sorted by the number of affected repos. Each aggregated entry expands to show the alphabetical list of affected repo slugs for direct triage. The tab reuses the per-repo recommendation catalog as its source of truth — no new recommendation rules are introduced.

Design constraints

This is a high-level organization inventory view, not a full CHAOSS analysis computed for every repo in the org
Phase 1 implementation stays within lightweight public metadata and should avoid expensive per-repo deep fetches by default
Table layout must remain usable on desktop and mobile, with pagination or virtualization available for large orgs

Out of scope

Analyzing private repositories
Running the full per-repo metric pipeline automatically for every repo in an org
Historical org snapshots or trend charts
Cross-org comparison

`[P1-F02]` Authentication

User can authenticate with GitHub to enable data fetching.

Acceptance criteria

Token input field accepts a GitHub Personal Access Token
Token is stored in localStorage — never transmitted anywhere except the GitHub GraphQL API
UI displays the required token guidance for supported GitHub auth
Missing token with no server-side fallback blocks submission with a clear error

Out of scope

Multi-account or org-level token management
OAuth flow is handled by P1-F14

`[P1-F03]` Deployment

RepoPulse deploys to Vercel with minimal configuration.

Acceptance criteria

Deployable to Vercel with zero config
GITHUB_TOKEN configurable as a Vercel environment variable for shared/team deployments
When GITHUB_TOKEN is set as a Vercel environment variable, it is used server-side and the token input field is hidden in the UI
No database, no auth system — stateless by default
GITHUB_TOKEN never exposed to the client bundle

Out of scope

Self-hosted Docker deployment (not blocked, just not documented in Phase 1)
Multi-region or edge deployment configuration

`[P1-F04]` Data Fetching

The analyzer fetches exact, verified metric data from GitHub for each repo.

Acceptance criteria

All data fetched via GitHub GraphQL API in 1–3 requests per repo
Next.js API Route (/api/analyze) proxies GraphQL requests server-side
Per-repo error isolation: one failed repo does not block results for others
Rate limit state is surfaced to the user (remaining calls, Retry-After when exhausted)
Loading state shown per repo during fetch
No metric is estimated, inferred, or fabricated — missing fields are marked "unavailable"
Data fetched per repo covers the following placeholders:
- Repo metadata: name, description, created date, primary language
- Ecosystem signals: stars, forks, watchers
- Activity: commits (last 30d, last 90d, last 180d), releases (last 12mo), PRs opened / merged / closed, issues opened / closed, and contributor-activity flow timing where specified
- Contributors: unique commit authors (last 90d), total contributors, commit counts per author
- Responsiveness: issue first-response timestamps, issue close timestamps, PR merge timestamps

Out of scope

Caching or persisting fetched data
Webhook-triggered or scheduled fetching (Phase 2)

`[P1-F05]` Ecosystem Map

Repos are summarized in an interactive ecosystem view with a spectrum-based ecosystem profile.

Acceptance criteria

Each successful repo surfaces an ecosystem profile with three tiered dimensions:
- Reach
- Builder Engagement
- Attention
Spectrum bands are defined in shared config and rendered consistently in the UI; component logic must not hardcode the thresholds independently
Each successful repo card shows exact stars / forks / watches plus derived fork rate and watcher rate where they are verifiable
Single-repo input remains fully useful: the repo is still profiled without requiring a comparison set
Repos with unavailable ecosystem metrics are never given fabricated rates or derived profile tiers

Out of scope

Saving or sharing a generated visualization directly
Animating transitions between analyses

`[P1-F15]` Results Shell

RepoPulse presents analysis in a stable app shell so users can submit repos once and switch between result views cleanly.

Acceptance criteria

A top header/banner shows the RepoPulse brand and a visible GitHub repo link
Repo input and Analyze action live in a stable analysis panel that remains visible above the result views
Successful analyses populate a tabbed result area rather than stacking every future view vertically
The shell organizes result views in a stable order with Overview first and domain views such as Contributors, Activity, Responsiveness, and Comparison available as tabs
The Overview tab is the first populated results tab and can absorb cross-feature summary content until later tabs deliver distinct value
Switching tabs does not re-submit the analysis request or trigger extra API calls
The shell works for single-repo and multi-repo analyses on desktop and mobile layouts

Out of scope

Persisting the selected tab across sessions
Replacing later feature-specific behavior inside each tab
User-customizable tab sets or dashboard layout editing

`[P1-F06]` Repo Comparison

Users can compare two or more repos side by side across all health metrics.

Acceptance criteria

Repository input exposes both Analyze and Compare actions in repo mode, both backed by the same analysis request
Compare is available only when at least two valid repos are entered and no more than four repos are eligible for comparison
Any analysis of 2+ repos surfaces a comparison view alongside the individual repo cards
Choosing Compare opens the results workspace directly on Comparison after analysis completes
Comparison table shows selected metrics in rows, repos in columns, with comparison-focused delta messaging highlighted more prominently than raw values
Comparison view uses a user-selectable anchor repo as the baseline for delta interpretation; the first mentioned successful repo is the default anchor
Comparison table is organized into clearly labeled sections such as Overview, Contributors, Activity, and Responsiveness
Users can enable or disable entire comparison sections, with all sections enabled by default
Users can choose which comparison attributes are shown; all supported attributes are selected by default
Comparison view includes a user-selectable median column across the chosen repos; it is visible by default
Every visible comparison column is sortable in ascending or descending order within the current section context
The UI clearly communicates the maximum of 4 compared repositories before and during analysis input
When more than 4 repos are analyzed, users choose which 4 appear in the Comparison view via a participants picker; anchor selection is independent of subset selection and changing the anchor implicitly includes it in the participants
Metrics unavailable for one repo are shown as — in that column, never omitted from the row
Comparison is driven entirely from the already-fetched AnalysisResult[] — no additional API calls
All metric categories represented: ecosystem signals, activity, contribution dynamics, responsiveness
Comparison view is exportable as JSON and Markdown alongside individual repo exports

Design constraints (inform all upstream features)

AnalysisResult schema must be flat and consistent enough to diff across repos without transformation — design this from the start
Ecosystem profile summaries are the visual entry point into comparison; the comparison table is the detail layer
UI layout must accommodate 2–4 repos in comparison without horizontal scroll on desktop viewports
The anchor model should make “better or worse than the baseline” easier to understand than a neutral spreadsheet alone

Out of scope

Saving or naming a comparison set
Diffing snapshots across time (Future — FUT-F01)
More than 4 repos in a single comparison

`[P1-F07]` Metric Cards

Each repo is summarized in a scannable card showing key health signals.

Acceptance criteria

One card per repo displaying: stars, forks, watches, created date, ecosystem profile summary (Reach / Builder Engagement / Attention), and one score badge per CHAOSS-aligned dimension (Activity, Sustainability, Responsiveness)
Ecosystem profile badges use consistent visual treatment across Reach / Builder Engagement / Attention tiers
Score badge colors: High = green, Medium = amber, Low = red, Insufficient = gray — consistent across all three CHAOSS score badges
CHAOSS category label shown beneath each score badge so the framing is always visible
Card click or expand reveals missing-data detail for that repo without duplicating the deeper metric views hosted in later tabs

Out of scope

Pinning or reordering cards
Inline side-by-side card layout — comparison detail is handled by P1-F06

`[P1-F08]` Activity (CHAOSS-aligned: activity flow)

The analyzer measures how a repo’s recent activity and delivery flow change across configurable recent windows.

Acceptance criteria

Metrics computed:
- commits over time in 30d, 90d, and 180d windows
- PR throughput: opened, merged, closed
- issue flow: opened, closed
- release cadence and version frequency
- PR merge rate (merged / opened)
- issue closure rate (closed / opened) for the selected window
- stale issue ratio (open older than selected window / total open)
- median time to merge PRs
- median time to close issues
The Activity tab shows selected-window raw counts and throughput ratios together so users can interpret percentages in context
The Activity tab is the primary home for activity-flow ratios such as PR merge rate, issue closure rate, and stale issue ratio; these ratios are explained in context here before they are reused in any later cross-repo ratio rollup
The Activity score in the Activity tab follows the selected recent-activity window, while the overview badge may continue to use the canonical default score window
The first implementation focuses on ratios and fixed-window comparisons; full time-series trend charts for commits, PRs, and issues are a follow-up once bucketed trend data is carried in the shared analysis payload
Activity score — High / Medium / Low — assigned only when sufficient verified data exists; otherwise surfaces Insufficient verified public data
Activity score is based on a weighted combination of:
- recent volume: commits, PRs, and issues across 30d, 90d, and 180d
- flow: PRs merged vs. opened and issues closed vs. opened
- cadence: release cadence and version frequency
- completion speed: median time to merge PRs and median time to close issues
Activity scoring proposal for the first implementation:
- 20% PR flow
  - PRs opened vs. merged vs. closed
  - PR merge rate
- 20% issue flow
  - issues opened vs. closed
  - stale issue ratio
- 20% completion speed
  - median time to merge PRs
  - median time to close issues
- 20% sustained activity
  - commits across 30d, 90d, and 180d
- 20% release cadence
  - release frequency
  - version movement
Score interpretation proposal:
- High: sustained recent activity, healthy PR/issue flow, meaningful release cadence, and relatively fast merge/close medians
- Medium: meaningful activity is present, but cadence, throughput, or completion speed is uneven
- Low: weak recent activity, weak flow, stale completion times, or little meaningful release motion
- Insufficient verified public data: minimum required activity and flow inputs are not available
Activity score should balance absolute volume with ratios and medians, so larger repositories do not automatically outrank smaller but healthy ones
Activity owns throughput, cadence, and time-to-completion signals, while Responsiveness remains focused on first-response and maintainer-engagement latency
All thresholds defined in config, not hardcoded in logic
UI exposes thresholds via a “How is Activity scored?” help surface and keeps primary values visible without tooltip-only disclosure
CHAOSS category label displayed alongside the score in the UI

Out of scope

User-adjustable thresholds in the UI (Future backlog)
Commit frequency broken down by day of week or time of day
Full commit / PR / issue sparkline charts before bucketed trend series are added to the shared AnalysisResult payload

`[P1-F09]` Contributors

The Contributors workspace measures the depth and distribution of contributor activity, with a dedicated Sustainability pane for broader resilience and organizational-risk signals.

Acceptance criteria

Top-level results navigation places Contributors immediately after Overview
The Contributors tab includes a Recent activity window control with presets:
- 30d
- 60d
- 90d (default)
- 180d
- 365d
Changing the Recent activity window updates contributor-derived metrics locally without rerunning analysis
The Contributors tab is organized into two panes:
- Core
- Sustainability
The initial Core pane in P1-F09 includes:
- a Contributor composition summary card
- GitHub API contributors as the top-level contributor-count source
- active / repeat / one-time / inactive contributor composition for the selected recent-activity window
- contributor-composition ratios such as repeat contributors / total contributors and new contributors / total contributors when those ratios are publicly verifiable from the shared analysis payload
- person-level contribution heatmap for the selected recent-activity window
The Sustainability pane includes the Sustainability score and related explanation surfaces
The Sustainability pane owns contribution concentration and related top-20%-share explanation surfaces
The Sustainability pane also includes:
- maintainer or owner count from supported public repository files such as OWNERS, OWNERS.alias, MAINTAINERS, MAINTAINERS.md, .github/CODEOWNERS, or GOVERNANCE.md
- observed types of contributions from verified recent repository activity
The Sustainability pane includes an Organization Affiliation subsection for:
- Elephant Factor (verified public GitHub organization membership)
- single-vendor dependency ratio (verified public GitHub organization membership)
- organization contribution chart showing all public org memberships per contributor
- explicit “Unaffiliated” category for contributors without public org membership
- transparency callout: affiliations reflect current membership at analysis time, not historical employment
Resilience score — High / Medium / Low — derived from contribution dynamics data; assigned only when concentration data is verifiable
Scoring logic: high contribution concentration = fragile; moderate concentration = moderate; distributed contributors = strong, with insufficient verified public data blocking the score when contributor-distribution evidence is incomplete
All thresholds defined in config, not hardcoded in logic
CHAOSS category label displayed alongside the score in the UI
Missing data explicitly listed in the per-repo callout panel
Additional later sustainability signals remain tracked in the product/docs roadmap rather than rendered as placeholder UI in the current pane:
- no contributions in the last 6 months
- new contributors (first verified contribution in last 90d)
- new vs. returning contributor ratio per release cycle
- organizational diversity
- organization-level contribution heatmap
- unique employer/org count among contributors
- richer Elephant Factor and vendor-risk refinements beyond the experimental heuristic (CHAOSS metric reference)

Out of scope

Manually overriding org affiliation
Bus Factor calculation (Future backlog)

`[P1-F10]` Responsiveness (CHAOSS: Responsiveness)

The analyzer measures how quickly maintainers engage with community activity.

Acceptance criteria

The Responsiveness tab is organized into panes that map directly to the feature’s metric groups:
- Issue & PR response time
- Resolution metrics
- Maintainer activity signals
- Volume & backlog health
- Engagement quality signals
Issue & PR response time includes:
- time to first issue response
- time to first PR review
- median response times
- 90th percentile response times
Resolution metrics includes:
- issue resolution duration
- PR merge duration
- issue resolution rate (closed / opened) for the selected window
Maintainer activity signals includes:
- contributor response rate
- ratio of bot responses vs. human responses
Volume & backlog health includes:
- stale issue ratio
- stale PR ratio
Engagement quality signals includes:
- PR review depth
- issues closed without comment
Computed from exact timestamps in GraphQL issue and PR event data — no estimation
Response and resolution metrics SHOULD expose both median and p90 values when enough verified public data exists, so outliers are visible without requiring full event-history charts
Responsiveness score — High / Medium / Low — assigned only when sufficient event data exists; otherwise surfaces Insufficient verified public data
Responsiveness score is based on a weighted combination of:
- 30% Issue & PR response time
- 25% Resolution metrics
- 15% Maintainer activity signals
- 15% Volume & backlog health
- 15% Engagement quality signals
All thresholds defined in config, not hardcoded in logic
If GitHub does not surface required event timestamps via GraphQL, fields are marked "unavailable" and called out explicitly in the missing data panel
CHAOSS category label displayed alongside the score in the UI

Out of scope

Bus Factor and responder concentration risk, which belong in contributor/sustainability analysis
Review turnaround time per reviewer
Label assignment lag
Open issue or PR trend charts over time
Reopened issue rate
SLA tracking over time (Future backlog)

`[P1-F11]` Health Ratios (deprecated — tab removed)

The dedicated Health Ratios tab has been removed. Its ratios are fully covered by domain-specific tabs (Overview, Contributors, Activity) and the Comparison view. The underlying ratio computation logic in lib/health-ratios/ is retained for use by exports, contributors, and comparison features.

Out of scope

Custom ratio definitions by the user

`[P1-F12]` Missing Data & Accuracy

The UI makes data gaps explicit and never hides them.

Acceptance criteria

Per-repo callout panel lists every field that could not be verified from the API
Fields marked unavailable in the JSON output are visually distinguished in the UI (not hidden, not zeroed out)
No metric is estimated, inferred, or substituted — enforced in the analyzer module and visible in the UI

Out of scope

Suggesting alternative data sources for missing fields

`[P1-F14]` GitHub OAuth Authentication

User authenticates with GitHub via OAuth. OAuth replaces the PAT input and the server-side GITHUB_TOKEN — each user’s own OAuth token is used for all API calls, distributing rate limit consumption across users rather than sharing a single server quota.

Acceptance criteria

“Sign in with GitHub” button initiates the OAuth flow using a registered GitHub OAuth App
OAuth access token is stored in localStorage
OAuth token grants the same repository read access expected by the analyzer
After successful OAuth login, the token input field is replaced with a signed-in indicator showing the GitHub username
User can sign out, which clears the stored OAuth token from localStorage
OAuth is required to use the app — unauthenticated access is not supported
GITHUB_CLIENT_ID and GITHUB_CLIENT_SECRET are stored as environment variables — never committed, never sent to the client
OAuth callback is handled server-side; the access token is never exposed in the URL
Server-side GITHUB_TOKEN environment variable is removed — no longer needed
PAT input field is removed from the UI

Out of scope

Multi-account or org-level OAuth management
Token refresh / long-lived session management (Phase 1 is stateless)
Coexistence with PAT — PAT support is fully replaced by OAuth

`[P1-F13]` Export

Users can take analysis results out of the UI in standard formats.

Acceptance criteria

Download full AnalysisResult[] as JSON
Download summary as Markdown report (CHAOSS-aligned format)
Copy shareable URL that encodes the repo list as query params — token never included in the URL

Out of scope

PDF export
CSV export
Saved reports or report history (Future backlog)

Phase 2 — Expand scoring dimensions

Phase 2 adds new scoring buckets to the OSS Health Score. Each bucket produces a percentile score and is weighted into the composite health score. Requirements specs live in the linked GitHub issues — see Spec ownership below.

Feature ID	Feature	Issues
P2-F01a	Documentation scoring (basic)	#66
P2-F02	Licensing & Compliance	#115
P2-F03	Inclusive naming	#107
P2-F01b	Documentation scoring (advanced)	#110, #67
P2-F04	Governance & Transparency	#116
P2-F05	Community scoring	#70
P2-F06	Foundation-aware recommendations	#119
P2-F07	Security scoring	#68, #71
P2-F08	Accessibility & Onboarding	#117
P2-F09	Release health scoring	#69
P2-F10	Development cadence	#73
P2-F11	Project maturity	#74
P2-F12	Ecosystem Reach	#118

Phase 3 — Integrations

These features deliver the OSS Health Score through additional channels, wrapping the shared analyzer module without duplicating logic.

Feature ID	Feature	Issues
P3-F01	Public REST API	#120
P3-F02	GitHub Action	—
P3-F03	MCP Server	—
P3-F04	Embeddable badge	#72
P3-F05	CLI tool	#82
P3-F06	PR comment bot	#83
P3-F07	VS Code extension	#84
P3-F08	Webhook receiver	#85

Phase 4 — Git provider support

A provider abstraction layer allows the analyzer to work with multiple Git hosting platforms.

Provider	Status
GitHub	Supported
GitLab	Planned
Bitbucket	Future
Gitea	Future

Future / Backlog

Historical trending — store snapshots over time, chart metric trajectory per repo
Bus Factor — contributor risk beyond concentration ratio
Inside-out maintainer practices audit — #99

Spec Ownership

Phase 1 features are shipped. Their requirements specs are frozen in this document (the [P1-F__] sections above). For Phase 2 and beyond, requirements specs live in GitHub issues — not in this document. This avoids duplication and keeps active specs where discussion happens.

Document responsibilities

Document	Owns	Contains
PRODUCT.md (this file)	Product vision, architecture, API contract, accuracy policy	Phase 1 specs (shipped, frozen). Phase 2+ summary tables with issue links
GitHub Issues	Phase 2+ requirements specs	Acceptance criteria, signals, scoring approach, open questions
DEVELOPMENT.md	Implementation sequencing, workflow, DoD	Feature order tables for each phase, SpecKit loop instructions
SpecKit specs (`specs/NNN-*/`)	Technical contracts	TypeScript interfaces, view props, data flow — generated during implementation

Feature development flow

GitHub Issue (requirements spec)
  │  "What to build, why, acceptance criteria"
  │
  ▼
/speckit.specify (reads issue as input)
  │  Generates specs/NNN-feature-name/ with technical contracts
  │
  ▼
/speckit.plan → /speckit.tasks → /speckit.implement
  │  Plan, break down, build
  │
  ▼
PR with test plan → merge

The GitHub issue is the input to /speckit.specify, not a duplicate of its output. The issue defines what and why; SpecKit generates how (TypeScript interfaces, view props, data flow contracts).

Development Workflow

See docs/DEVELOPMENT.md for the full SpecKit feature loop, Definition of Done, and phase-by-phase feature order.

This site is open source. Improve this page.

repo-pulse

RepoPulse — Product Definition

Roadmap

Phase 1 — Web app + core scoring ✅

Phase 2 — Expand scoring dimensions

Phase 3 — Integrations

Phase 4 — Git provider support

Data Source

OSS Health Score

Implemented buckets

Planned buckets (Phase 2)

Ecosystem profile

Scoring methodology

Accuracy Policy

Phase 1 — Web App (Next.js / Vercel)

Stack

API Contract

Pages

Planned Features

Phase 1 — Web App

[P1-F01] Repo Input

[P1-F16] Org-Level Repo Inventory

[P1-F02] Authentication

[P1-F03] Deployment

[P1-F04] Data Fetching

[P1-F05] Ecosystem Map

[P1-F15] Results Shell

[P1-F06] Repo Comparison

[P1-F07] Metric Cards

[P1-F08] Activity (CHAOSS-aligned: activity flow)

[P1-F09] Contributors

[P1-F10] Responsiveness (CHAOSS: Responsiveness)

[P1-F11] Health Ratios (deprecated — tab removed)

[P1-F12] Missing Data & Accuracy

[P1-F14] GitHub OAuth Authentication

[P1-F13] Export

Phase 2 — Expand scoring dimensions

Phase 3 — Integrations

Phase 4 — Git provider support

Future / Backlog

Spec Ownership

Document responsibilities

Feature development flow

Development Workflow

`[P1-F01]` Repo Input

`[P1-F16]` Org-Level Repo Inventory

`[P1-F02]` Authentication

`[P1-F03]` Deployment

`[P1-F04]` Data Fetching

`[P1-F05]` Ecosystem Map

`[P1-F15]` Results Shell

`[P1-F06]` Repo Comparison

`[P1-F07]` Metric Cards

`[P1-F08]` Activity (CHAOSS-aligned: activity flow)

`[P1-F09]` Contributors

`[P1-F10]` Responsiveness (CHAOSS: Responsiveness)

`[P1-F11]` Health Ratios (deprecated — tab removed)

`[P1-F12]` Missing Data & Accuracy

`[P1-F14]` GitHub OAuth Authentication

`[P1-F13]` Export