When to Archive a Ruleset
Archive a ruleset when: the technology it covers is no longer used (the Angular ruleset after migrating to React), the project it served is decommissioned (the client project is complete and the code is in maintenance mode), the ruleset has been superseded (the old TypeScript ruleset is replaced by a new, restructured version), or the ruleset was an experiment that did not work out (a trial ruleset that the team decided not to adopt). In all cases: the ruleset is no longer actively used but its history has value.
Archive, do not delete: deleting a ruleset removes its version history, the record of what conventions were used and when, and the ability to reference old rules for understanding legacy code. Archiving: preserves all of this while removing the ruleset from active listings. An archived ruleset: invisible in the active ruleset browser, visible in the archive section for historical reference, and restorable if needed (the technology comes back, the project is reactivated).
The quarterly cleanup: during the quarterly rule review, identify rulesets that are candidates for archival. Questions: is any project still using this ruleset? Was this ruleset pulled in the last 90 days? Has the technology this ruleset covers been deprecated in the organization? Rulesets that answer: no, no, yes → archive. AI rule: 'The quarterly review includes a cleanup pass. Identify unused rulesets. Archive them. Keep the active library lean — only rulesets that are in active use.'
Step 1: The Archive Process
Before archiving: verify no projects are actively using the ruleset. In the RuleSync dashboard: check the 'Assigned Projects' for the ruleset. If projects are assigned: unassign them first (or migrate them to a replacement ruleset). If projects are assigned and actively pulling: do NOT archive without migrating. The project: would lose its rules on the next pull attempt. AI rule: 'Always check assigned projects before archiving. Archiving a ruleset with active assignments: breaks those projects' rule sync.'
Unassign from projects: for each assigned project, either remove the ruleset assignment (the project no longer needs it — the technology was decommissioned) or replace with a successor ruleset (the project is migrating to a new technology — assign the new technology's ruleset before removing the old one). The replacement: should happen in one operation (assign new, remove old) so the project is never without rules.
Archive the ruleset: in the RuleSync dashboard: Rulesets → [ruleset name] → Settings → Archive. The ruleset: moves to the archived section. It is no longer visible in the active ruleset browser. Version history: preserved. The ruleset: can be viewed in the archive for reference and restored to active status if needed. AI rule: 'Archive is reversible. Delete is not. Always archive. Never delete — even if you are sure you will never need it again.'
Archiving a ruleset with active project assignments: the next time those projects run rulesync pull, they cannot find the ruleset. The sync: fails. The project: stuck on old rules with no update path. Always: check assigned projects → unassign or migrate → then archive. The check: takes 10 seconds in the dashboard. Skipping it: creates a support ticket and a frustrated team.
Step 2: Preserving Institutional Knowledge
Why keep archived rulesets: a developer is maintaining legacy code from 2024. The code follows conventions that are no longer the organization's standard. The developer: needs to understand those old conventions to maintain the code correctly. The archived ruleset: documents what conventions were in place when the code was written. Without the archive: the developer guesses at the old conventions or treats legacy code as non-standard (when it was standard at the time it was written).
The archive as documentation: each archived ruleset: includes its version history (how the rules evolved over time), the date range it was active (when it was used and when it was archived), the projects it served (which codebases were built under these conventions), and the reason for archival (why it was retired — technology change, reorganization, superseded by a better version). This metadata: turns the archive into a development history document.
Referencing archived rules: when working on legacy code, a developer can: view the archived ruleset in the dashboard, temporarily use it for AI-assisted maintenance (configure the AI to follow the old conventions when editing legacy files), or extract specific rules from the archive for a legacy maintenance section in the current rule file. AI rule: 'Archived rulesets are a reference library for legacy code maintenance. They document: what conventions were in place when the legacy code was written.'
A developer maintains a module written in 2024 under the 'TypeScript Conventions v1' ruleset. The current ruleset is v3 with different error handling patterns. Without the archive: the developer does not know what conventions the module was built under. They apply v3 conventions to v1 code: creating inconsistency within the module. With the archive: they reference v1, understand the original conventions, and maintain the module consistently.
Step 3: Ruleset Library Hygiene
A cluttered ruleset library: 40 active rulesets, but only 15 are assigned to any project. The other 25: experimental rulesets that were never adopted, old technology rulesets that were superseded, and project rulesets for decommissioned projects. The clutter: makes it harder for teams to find the right ruleset, creates confusion about which rulesets are current, and increases the maintenance burden (the platform team tracks all 40 even though 25 are unused).
The cleanup process: quarterly, review all active rulesets. For each: check if it is assigned to any project (if not: candidate for archival), check if it was pulled in the last 90 days (if not: candidate for archival), and check if it has been superseded by a newer version (if yes: archive the old version). The result: only actively used rulesets in the active library. Everything else: archived with preserved history.
Naming convention for clarity: use a naming convention that signals status. Active: 'TypeScript Conventions v2' (current version). Superseded: 'TypeScript Conventions v1 [superseded by v2]' (rename before archiving so the archive clearly indicates why it was retired). This convention: makes the archive self-documenting. A developer browsing the archive: immediately understands each ruleset's status. AI rule: 'Rename with a status suffix before archiving: [superseded by X], [technology deprecated], [project decommissioned]. The archive tells its own story.'
Archive browser shows: 'TypeScript Conventions v1.' Why was it archived? When? What replaced it? Unknown without clicking in. Better: rename to 'TypeScript Conventions v1 [superseded by v2, archived 2026-03]' before archiving. Now the archive entry: tells its own story. The developer browsing the archive: knows immediately why it was retired, when, and what to use instead. Ten extra seconds of renaming: saves minutes of investigation for every future archive browser.
Archival Summary
Summary of archiving old AI rulesets.
- When: technology deprecated, project decommissioned, ruleset superseded, experiment abandoned
- Archive, never delete: preserves version history, enables legacy code reference, is reversible
- Before archiving: verify no active projects. Unassign or migrate to replacement ruleset first
- Preserve: version history, date range, served projects, and reason for archival
- Legacy reference: archived rulesets document conventions when legacy code was written
- Quarterly cleanup: review all active rulesets. Archive unused (no assignments, no pulls in 90 days)
- Naming: add status suffix before archiving ([superseded by v2], [technology deprecated])
- Library hygiene: only actively used rulesets in the active library. Everything else: archived