Skip to main content
Quality scorecards turn CI evidence into release-ready insights — which features are covered, what regressed, and what to export for auditors.

​
Accessing quality data

Navigate to Quality in the lanesync.dev dashboard, or use the API:
Filter by owner, repo, milestone, test type, and environment.

​
Scorecard views

​
Linking tests to features

Tests map to features via:
  1. sdlc.yaml patterns — glob → external ID
  2. CI environment variables — feature reference in pipeline
  3. Test naming / report metadata — e.g. Feat_<issue#>_ in JUnit class names
Configure patterns in Configure sdlc.yaml:
See Quality tracking for the full list.

​
Feature issues and FEAT-IDs

The Features tab lists GitHub issues labelled feature. Each row shows a FEAT-ID and health (stable / degraded / no tests) from linked tests.
  • New capability → its own FEAT-ID
  • Follow-up / regression on existing work → add a line in the issue body: Existing feature: #123, or cite FEAT-xxxxxxxx, or use an explicit keyword reference (fixes #123, from #123, title (#123))
  • Do not rely on casual #123 mentions in prose — they are ignored
  • Multiple issues can share one FEAT-ID; the dashboard shows link reason text for each issue

​
Regression detection (anomalies)

LaneSync assigns stable test case IDs and compares the current milestone to the last production-deployed release (baseline), per environment. Latest run wins within each scope.
Response includes baseline and current when a prior deployed release exists. Evidence upload runs on dev and release/ branches (not typical PR refs). Use a release branch run to populate staging anomalies for a new version.

​
Export reports

Download for release reviews or compliance:

​
Evidence integration

Scorecards populate from CI evidence upload. Ensure your pipeline:
  1. POSTs metrics to /api/evidence/upload
  2. Uploads JUnit via /api/evidence/upload-report
  3. Runs on release branch (or configured branch)