Context
The existing badges data layer can store achievement grants and derive badges from them, but grants are not yet populated from data already held by the platform. Staff also lack a safe administrative interface for reviewing and correcting grants or explaining why members gained or lost badges.
Automatic achievement data can change over time. For example, a commit may become associated with a member, or an existing attribution may be corrected. The system therefore needs to handle both newly discovered and stale grants while protecting manual decisions and maintaining a clear audit trail.
What’s needed
Build the shared foundation for achievement ingestion and badge administration:
-
Introduce a reusable synchronization engine that compares current source data with stored automatic grants.
-
Provide two operating modes:
- Backfill: Adds missing grants only and can never remove existing ones.
- Reconcile: Adds missing grants and removes stale automatic grants, with a dry-run preview before changes are applied.
-
Protect manual grants from all automatic synchronization.
-
Refuse potentially dangerous reconciliation when a source unexpectedly returns no data.
-
Log every real synchronization run, including its source, trigger, operator, result, and number of grants added or removed.
-
Connect badge revocations caused by synchronization to the relevant run so staff can explain what happened.
-
Provide secure, permission-controlled admin actions for running backfills, reconciliations, and badge recalculations.
-
Allow staff to manually grant, invalidate, revalidate, revoke, or reinstate records with required notes and attribution, while preventing hard deletion and silent edits.
-
Make badge thresholds append-only so changes preserve history and do not silently rewrite existing configuration.
-
Add a member-level admin view that explains whether a badge is held or missing because of thresholds, revocation, or visibility settings.
Initial ingestion scope
This ticket connects only the code-commits achievement source to the new ingestion engine.
The registry and synchronization workflow should be reusable, but other automatic achievement sources, such as library authorship, maintainership, releases, and formal reviews, will be connected in separate later PRs.
Until those PRs are completed, the admin source selector will contain only code-commits and the option to process all currently registered sources. Achievement types that require manual grants should still be manageable through the admin interface.
Desired outcome
After this ticket, code-commit achievements can be safely backfilled and reconciled against stored grants. Staff will have an audited, permission-controlled interface for managing achievements and badges, previewing destructive changes, and explaining each member’s badge status.
This establishes the common ingestion and administration framework. The remaining achievement sources, scheduled execution, existing admin-button migration, and public-facing UI will be handled separately.
Context
The existing badges data layer can store achievement grants and derive badges from them, but grants are not yet populated from data already held by the platform. Staff also lack a safe administrative interface for reviewing and correcting grants or explaining why members gained or lost badges.
Automatic achievement data can change over time. For example, a commit may become associated with a member, or an existing attribution may be corrected. The system therefore needs to handle both newly discovered and stale grants while protecting manual decisions and maintaining a clear audit trail.
What’s needed
Build the shared foundation for achievement ingestion and badge administration:
Introduce a reusable synchronization engine that compares current source data with stored automatic grants.
Provide two operating modes:
Protect manual grants from all automatic synchronization.
Refuse potentially dangerous reconciliation when a source unexpectedly returns no data.
Log every real synchronization run, including its source, trigger, operator, result, and number of grants added or removed.
Connect badge revocations caused by synchronization to the relevant run so staff can explain what happened.
Provide secure, permission-controlled admin actions for running backfills, reconciliations, and badge recalculations.
Allow staff to manually grant, invalidate, revalidate, revoke, or reinstate records with required notes and attribution, while preventing hard deletion and silent edits.
Make badge thresholds append-only so changes preserve history and do not silently rewrite existing configuration.
Add a member-level admin view that explains whether a badge is held or missing because of thresholds, revocation, or visibility settings.
Initial ingestion scope
This ticket connects only the
code-commitsachievement source to the new ingestion engine.The registry and synchronization workflow should be reusable, but other automatic achievement sources, such as library authorship, maintainership, releases, and formal reviews, will be connected in separate later PRs.
Until those PRs are completed, the admin source selector will contain only
code-commitsand the option to process all currently registered sources. Achievement types that require manual grants should still be manageable through the admin interface.Desired outcome
After this ticket, code-commit achievements can be safely backfilled and reconciled against stored grants. Staff will have an audited, permission-controlled interface for managing achievements and badges, previewing destructive changes, and explaining each member’s badge status.
This establishes the common ingestion and administration framework. The remaining achievement sources, scheduled execution, existing admin-button migration, and public-facing UI will be handled separately.