refactor: remove retired data format support

docs/DEPLOYMENT.md

@@ -111,7 +111,10 @@ The workflow:
 7. waits for `/api/health/database` to report healthy;
 8. retains the logs and exits unsuccessfully if health verification fails.
 
-The outage covers backup, migration, and container startup.
+The outage covers backup, migration, and container startup. Migrations may also
+remove records that use retired data formats when a release explicitly ends
+compatibility. The deployment backup remains the recovery source for those
+records; the application does not repair or reinterpret them at runtime.
 The scheduler calls a bearer-authenticated endpoint on the application service
 once per minute. Scheduled message delivery therefore uses the web process's
 existing embedded-database connection instead of opening the locked database
@@ -123,7 +126,9 @@ consolidation, and email digest checks and is not published through a host port.
 Initialize the first staging release from the development database, including
 users, roles, builds, guides, proposals, audit history, avatars, and uploaded
 game-data icons. The staging importer refuses a target database that contains
-users, builds, audits, or proposals.
+users, builds, audits, or proposals. It also requires the source and target
+table sets to match exactly; snapshots with retired or unknown tables are
+rejected.
 
 First stop this project's development server. The embedded database must not be
 open while its complete transfer bundle is created:

docs/DESIGN_SYSTEM.md

@@ -1700,10 +1700,9 @@ Exclusive child-record relationships use a searchable assignment block directly
 after the record identity. The header names the parent type, states the
 relationship and capacity in plain language, and shows current usage as `N / N`.
 The registry repeats the assigned parent beside each child so exclusivity can be
-audited without opening the editor. Legacy records may remain visibly
-`UNASSIGNED`, but creation, restoration, and successful edits require a valid
-active parent. Capacity rules are enforced on the server and never communicated
-by color alone.
+audited without opening the editor. Records that require an exclusive parent
+must always have a valid active assignment. Capacity rules are enforced on the
+server and never communicated by color alone.
 
 Rank cards present the complete rank description, structured effects, point
 cost, Credits, and material cost together. Specialized Alpha, Beta, and Gamma
@@ -1762,8 +1761,9 @@ user buys every available Rank 1 and Rank 2 in preceding rows and enforces the
 49-point limit. Cost telemetry lists Credits and components beside each rank.
 
 Saved loadouts store focus, node ranks, nine Skill Chips, effect modes, and
-combat assumptions. Version 1 loadouts keep their three legacy chips in an
-unassigned recovery list until the user places them under compatible abilities.
+combat assumptions. The builder accepts only the current complete structure.
+Invalid local drafts are discarded; invalid server records are unavailable and
+removed through a backed-up database migration.
 
 ### Calculation revision controls
 

docs/architecture.md

@@ -275,11 +275,11 @@ distinct secondary stats from those separate pools.
 Every active Skill Chip definition belongs exclusively to one active
 specialization ability through `skill_chip_sets.specialization_ability_id`.
 An ability has capacity for exactly three active definitions. The save and
-restore actions enforce that capacity, while legacy rows may remain nullable
-until they are edited. A specialization focus is builder-ready only when each
-of its three assigned abilities has all three active Skill Chip definitions.
-Skill Chip mutations refresh readiness for focuses that reference both the
-previous and resulting ability.
+restore actions enforce that capacity, and the foreign key is required for
+every row. A specialization focus is builder-ready only when each of its three
+assigned abilities has all three active Skill Chip definitions. Skill Chip
+mutations refresh readiness for focuses that reference both the previous and
+resulting ability.
 
 Both set-bonus progression systems use the number of equipped High-end chips as
 the interpolation step. For `h` High-end chips, where `h` is zero through
@@ -308,10 +308,11 @@ Specialization proposal workflow.
 
 Loadout schema version 2 stores one focus, the selected rank for each tree node,
 nine Skill Chips, conditional-effect modes, and encounter assumptions. Each of
-the three focus abilities owns three chip positions. Version 1 migration keeps
-the three old chips in `specialization.unassignedChips`; the builder requires
-the user to place them under compatible abilities before it reports a complete
-calculation.
+the three focus abilities owns three chip positions. Runtime readers accept
+only the exact version 2 structure. Local drafts, saved builds, shared builds,
+and calibration snapshots reject older or partial structures instead of
+repairing them. Database migration removes obsolete snapshots after the
+required environment backup.
 
 # Versioned combat calculations