feat(metrics): Add rework rate OTEL metrics (#265) — 5th DORA metric

[tamirdresher]

Summary

Add PR rework rate as OTEL metrics in squad-sdk, following the exact pattern of the existing metrics (#261–#264) in \otel-metrics.ts.

This replaces #381 (the standalone CLI command approach) with a proper SDK-level OTEL metric that integrates into the existing telemetry pipeline.

What's included

\packages/squad-sdk/src/runtime/rework.ts\ — Pure calculation module

• Typed interfaces: \PrInfo, \PrReview, \PrCommit, \PrReworkResult, \ReworkSummary\
• \calculatePrRework()\ — per-PR rework analysis (commits after first review)
• \calculateReworkSummary()\ — aggregate metrics across multiple PRs

\otel-metrics.ts\ — #265 — Rework Rate Metrics\ section

Four OTEL instruments following the exact same lazy-init pattern:

• \squad.rework.rate\ (Gauge) — current rework rate percentage
• \squad.rework.cycles\ (Histogram) — review cycles per PR
• \squad.rework.rejection_rate\ (Gauge) — percentage of PRs with changes requested
• \squad.rework.time_ms\ (Histogram) — time spent in rework

Export functions:
ecordReworkMetrics(result)\ and
ecordReworkSummary(summary)\

Tests — 19 Vitest tests (all passing)

• 9 tests for \calculatePrRework\ (edge cases: no reviews, post-review commits, multiple cycles, nested commit objects, empty data, missing author, filtered reviews, rework time)
• 4 tests for \calculateReworkSummary\ (empty, aggregate, all-clean, single high-rework)
• 6 tests for OTEL metric recording (
  ecordReworkMetrics,
  ecordReworkSummary, instrument creation, reset)

Changeset

@bradygaster/squad-sdk: minor\ — Add rework rate OTEL metrics (#265)

Metrics tracked (the 5th DORA metric)

Metric	Description
Rework Rate	commits after first review / total commits × 100
Review Cycles	changes-requested → approved transitions
Rejection Rate	PRs with ≥1 changes requested / total PRs × 100
Rework Time	last approval − first changes-requested

Refs #265

[tamirdresher]

Follow-up Ideas for Rework Rate

Three enhancements that would make this metric self-sustaining:

1. GitHub Actions Cron — Automated Assessment

A scheduled workflow (daily/weekly) that runs the calculation without any CLI session. Calls gh to get recent merged PRs, computes rework metrics, and:

• Emits OTEL metrics to a configured collector
• Writes results to .squad/monitoring/rework-metrics.json
• If rework rate exceeds threshold, creates an issue
• Could feed into Ralph's work-check cycle

2. Ralph Integration — Self-Correction Loop

Wire into Ralph's weekly retro: high rework = flag it, Lead runs retro, team adjusts. Low rework sustained over N weeks = reduce review gates, lower polling, auto-promote skill confidence. The "nap" concept: a well-calibrated squad can relax its guardrails.

3. Azure DevOps Support

Current impl uses gh CLI. For ADO repos, need az repos pr list or ADO REST API. The calculation logic in rework.ts is provider-agnostic — just needs PrInfo, PrReview, PrCommit shaped data. An ADO adapter that maps to these interfaces would make it work across both platforms.

Happy to contribute any of these as follow-up PRs.

[tamirdresher]

Note: CI failure is a pre-existing issue on dev branch, not from this PR.

The CLI build fails on missing SDK exports (listRoles, searchRoles, getCategories, getRoleById, generateCharterFromRole) in roles.ts, cast.ts, and coordinator.ts. These imports exist in the CLI but the SDK doesn't export them yet. This breaks any PR targeting dev right now.

Our changes (squad-sdk only) compile clean - the rework.ts module and otel-metrics.ts additions type-check without errors.

Re: ADO support - the calculation in rework.ts is already provider-agnostic (just needs PrInfo/PrReview/PrCommit data). Rather than shipping adapter classes, this is better handled at the agent/skill layer - the Squad coordinator already knows how to call gh vs az based on repo context. A skill template documenting both data sources is sufficient.