Feature: Historical risk intelligence

[PredictabilityAtScale]

Context

Implements the analytics described in plans/feature-risk-intelligence.md to derive historical risk signals for IssueTriage.

Goals

• Correlate past issues with PRs/commits and compute change footprint metrics.
• Parse review timelines for blockers, security flags, and revision friction.
• Synthesize risk levels with evidence snippets consumable by assessment and dashboard flows.
• Run hydration jobs in the background with rate-limit awareness and progress reporting.

Acceptance Criteria

• Background processor hydrates historical datasets for the selected repository within the configured lookback window, handling pagination and rate limits.
• Risk profile API returns metrics (files touched, churn, review friction) plus supporting evidence for a given issue/PR.
• Assessment outputs include risk level modifiers and surface evidence in the panel.
• Dashboard displays risk indicators (badges/tooltips) without perceptible performance degradation.
• Failures recover gracefully with retry/back-off and user-visible status updates.

Dependencies

• Issue discovery model for mapping issues ↔ PRs.
• Assessment engine integration points to ingest risk modifiers.
• Local storage (SQLite or existing store) for aggregated metrics.

Notes

• Extend GitHubClient for timeline/review data; cache summaries to avoid recompute.
• Start with lightweight NLP heuristics (e.g., VADER) for comment severity; reserve LLM analysis for later tiers.

[PredictabilityAtScale]

IssueTriage Assessment

Model: openai/gpt-5-mini
Issue: PredictabilityAtScale/IssueTriage #9
View issue

Dimension	Score
Composite	78.3
Requirements	88.0
Complexity	68.0
Security	75.0
Business Impact	82.0

Summary: The issue describes a focused feature to derive historical risk signals by hydrating GitHub timeline/commit data, computing footprint and review-friction metrics, and surfacing evidence to assessment and dashboard flows. Acceptance criteria and high-level dependencies are provided, so an autonomous agent can implement a v1 pipeline with reasonable defaults. Main implementation complexity arises from GitHub API pagination/rate-limits, background hydration, and integration points (issue→PR mapping and assessment ingestion). A few integration decisions remain unclear and should be answered to avoid blocking a working v1.

Pre-implementation questions:

• Is there an existing 'issue discovery model' artifact/service in this repo or infra that the feature must call to map issues ↔ PRs, or should the agent implement a heuristics-based fallback (e.g., cross-references, linked events, commit messages) for v1?
• What is the assessment engine ingestion contract for risk modifiers (endpoint, auth method, required payload/schema) — or should the agent emit a local, documented API/webhook that assessment can later wire into?
• Will a GitHub credential be provided at runtime (personal access token or GitHub App) and are there required scopes/limits we must assume for hydrations, or should the agent implement a conservative default (client-side backoff, retry) until credentials/config are supplied?

Last updated: 10/20/2025, 8:59:43 AM

[PredictabilityAtScale]

IssueTriage Assessment

Model: openai/gpt-5-mini
Issue: PredictabilityAtScale/IssueTriage #9
View issue

Dimension	Score
Composite	65.4
Requirements	88.0
Complexity	68.0
Security	72.0
Business Impact	82.0

Summary: The issue clearly specifies a feature to hydrate GitHub timelines/commits, compute change-footprint and review-friction metrics, and surface evidence to assessment and dashboard flows. Acceptance criteria, goals, and high-level dependencies are provided so an autonomous agent can implement a v1 pipeline. Main uncertainties are integration touchpoints (issue↔PR mapping, assessment ingestion) and runtime credentials/rate-limit expectations. Implementation complexity is moderate due to background processing and GitHub API constraints.

Pre-implementation questions:

• Which issue→PR mapping source must be used? (an existing 'issue discovery model' service/artifact in repo/infra, or should the agent implement a heuristics fallback for v1?)
• What is the assessment engine ingestion contract (endpoint URL, auth method, required payload) or should the agent expose a documented local webhook/API as the v1 integration point?
• What GitHub credentials and scopes will be provided at runtime (personal access token vs GitHub App) and any rate-limit/usage expectations the agent must respect?

Last updated: 11/3/2025, 1:18:02 PM

[PredictabilityAtScale]

IssueTriage Assessment

Model: openai/gpt-5-mini
Issue: PredictabilityAtScale/IssueTriage #9
View issue

Dimension	Score
Composite	65.8
Requirements	88.0
Complexity	68.0
Security	75.0
Business Impact	82.0

Summary: The issue clearly defines a feature to hydrate GitHub history, compute change-footprint and review-friction metrics, and surface risk evidence to assessment and dashboard flows. Acceptance criteria and high-level dependencies are provided, enabling a v1 implementation with reasonable defaults. Main open integration questions relate to issue↔PR mapping, assessment ingestion contract, and runtime GitHub credentials/rate-limit expectations. An autonomous agent can implement a working pipeline if those three points are clarified.

Pre-implementation questions:

• Which source should the implementation use for issue→PR mapping: an existing 'issue discovery model' service (please provide endpoint/repo) or should the agent implement a heuristics-based fallback (cross-references/linked events/commit messages) for v1?
• What is the assessment engine ingestion contract for risk modifiers (endpoint URL, auth method, required payload) — or should the agent expose a documented local API/webhook as the v1 integration point?
• What GitHub credentials will be provided at runtime (personal access token vs GitHub App) and are there any expected scopes or rate-limit constraints the implementation must respect?

Last updated: 11/3/2025, 4:04:00 PM

[PredictabilityAtScale]

IssueTriage Assessment

Model: openai/gpt-5-mini
Issue: PredictabilityAtScale/IssueTriage #9
View issue

Dimension	Score
Composite	65.8
Requirements	88.0
Complexity	68.0
Security	75.0
Business Impact	82.0

Summary: This issue clearly specifies a v1 feature to hydrate GitHub history, compute change-footprint and review-friction metrics, and surface risk evidence to assessment and dashboard flows, with concrete acceptance criteria. Technical complexity is moderate due to GitHub API pagination/rate limits, background processing, and integration touchpoints. Three integration decisions are unclear and must be resolved before an autonomous agent can produce a working v1 without making potentially incorrect assumptions.

Pre-implementation questions:

• Which source should be used for issue→PR mapping for v1: an existing 'issue discovery model' service (please provide endpoint/repo) or should the agent implement a heuristics-based fallback (cross-references/linked events/commit messages)?
• What is the assessment engine ingestion contract for risk modifiers (endpoint URL, auth method, required payload/schema) or should the agent expose a documented local API/webhook as the v1 integration point?
• What GitHub credentials will be provided at runtime (personal access token vs GitHub App) and are there any required scopes or explicit rate-limit constraints the implementation must respect?

Last updated: 11/11/2025, 6:22:09 PM