Records Surface sort step and UI — sort ships as part of the **Sort & Filter Lens**, the second lens in step 2's default set (alongside the existing **Pack Firing Lens**); `lens` is the architectural primitive this spec introduces and lenses are *swappable* (one active per step at a time), not stackable; each step ships with a small curated default lens set and the registry stays *open* so new lenses can join without architecture changes

Today's Records Surface renders 96 records in CSV order. The 2026-06-09 ship made augmentation state visible (the `corpus_count` chip + four system columns in v9), but the operator can't *re-order* the list to focus their attention on the tier-2 middle-band records the [[../explorations/Operator-Built-Flows-Beyond-The-Universal-Pipeline]] explored. Sort is the cheapest move that unlocks that scenario. This spec ships sort inside the **Sort & Filter Lens** — the second lens in step 2's default set. The first lens, the existing pack-firing UI (bundle picker + roster + 'fire on 96 rows' button), is named in this spec as the **Pack Firing Lens** so the architecture has language for it. Lenses are *swappable* — one active per step at any moment; the step counter in the FLOW header shows which lens is active and right-clicking it opens the lens menu. The agent has the same authority: `/lens sort` (or 'let me sort these records') swaps step 2's active lens. State persists across swaps so the operator can toggle between Pack Firing and Sort & Filter without losing their bundle selection or their sort. The lens registry is **open** — new lenses appear in a step's menu by dropping a manifest, not by editing a closed enum; the default set per step is the *curated opinion the app ships with*, not the *closed universe of possible lenses*.