feat(date-range-picker): t-paliad-248 — symmetric picker + filter-bar wiring

Slice A complete. Builds on the additive backend constants (commit
34e3d71) by shipping the user-facing surface.

# Pure helpers (no DOM)

frontend/src/client/date-range-picker-pure.ts (190 LoC) — TimeSpec
shape, ALL_HORIZONS / PAST_HORIZONS / NEXT_HORIZONS registries,
horizonBounds (mirrors view_service.go), isValidHorizon, isValidISODate
(strict — rejects 2026-02-30 etc.), validateCustomRange, parseURL /
serializeURL (canonical ?horizon=...&horizon_from=...&horizon_to=...
with default-omission), isDefault.

frontend/src/client/date-range-picker-pure.test.ts (38 bun tests,
118 expect calls): registries, horizon bounds for all 14 values,
ISO-date validity rejects calendar-impossible dates, validateCustomRange
on every error branch, parseURL fallback to default, serializeURL
default-omission + key-override + custom-bounds, full round-trip.

# DOM mount

frontend/src/client/date-range-picker.ts (290 LoC) — mountDateRangePicker
returns {element, getValue, setValue, close, destroy}. Trigger button
in a .multi-anchor wrapper, popover panel reusing .multi-panel
positioning. Symmetric chip row: past fan (right-aligned) | ALLES
centre (target glyph U+2316) | next fan. 'Anpassen' chip toggles an
inline date-pair editor with Apply / Cancel + a live validation
message that surfaces only the meaningful 'inverted range' error
during typing (empty/format errors are visible via the disabled
Apply button). Outside-click + Esc close the popover, focus returns
to the trigger. setValue lets the host sync from URL changes.

# Filter-bar wiring

frontend/src/client/filter-bar/axes.ts:renderTimeAxis — the disabled
'Anpassen' stub (t-paliad-163 Phase 2 placeholder) is gone; the axis
mounts the picker instead. New default presets surface 6 chips +
ALLES centre + Anpassen, plus the per-surface timePresets override
filters down to whatever subset the surface declares. 'any' still
maps to BarState.time = undefined to keep the canonical URL short
and preserve the existing 'no overlay' semantics.

frontend/src/client/filter-bar/types.ts — TimeOverlay.horizon union
extended with next_1d / next_14d / next_all / past_1d / past_14d /
past_all.

frontend/src/client/filter-bar/url-codec.ts — parseHorizon accepts
the six new values; existing 9 values continue to round-trip.

frontend/src/client/filter-bar/url-codec.test.ts — round-trip
iteration extended to all 14 horizons.

frontend/src/client/views/types.ts — TimeHorizon TS mirror extended.

frontend/src/client/projects-detail.ts — horizonBounds covers the
six new values (open-ended for next_all/past_all so the upstream
filter treats nil bounds as 'no narrowing in that direction').

# i18n + retired legacy keys

frontend/src/client/i18n.ts — 30 new keys per language (date_range.*
namespace for the picker + 6 missing views.horizon.* labels for
existing dynamic-key composition in views.ts:317). Legacy
views.bar.time.* keys (10 per language) retired with a one-line
breadcrumb comment pointing at the date_range.* namespace.

frontend/src/i18n-keys.ts — regenerated by build.ts.

# CSS

frontend/src/styles/global.css — date-range-* class block (256 LoC).
Trigger button, popover panel, past/centre/next groups, custom-range
editor, mobile stack at <540px. Reuses --color-accent /
--color-accent-light / --color-bg-lime-tint / --color-border /
--color-text + .agenda-chip / .agenda-chip-active for chip styling
so every active state lights up with the same lime accent as every
other paliad filter chip — no new tokens, no fresh dark-mode
contrast risk (t-paliad-150 / fritz lesson held).

# Surfaces lit up by this single change

- /projects/:id Verlauf (filter-bar consumer)
- /views runtime
- /views/:id Custom-Views editor
- /inbox InboxFilterBar

All four pick up the picker on their next page load. Per-surface
presets (timePresets MountOpt) preserved exactly; Verlauf still
shows the past-only subset, /inbox the forward-leaning subset etc.
The custom chip that's been disabled-with-coming_soon since
t-paliad-163 now works.

# Tests + build hygiene

- go build ./... clean
- go test ./internal/services/ clean (filter_spec + new bounds test)
- bun test passes (150 tests, 8 files, 377 expect calls)
- bun run build clean (2848 i18n keys, data-i18n scan clean)

# What's NOT in this slice

- /agenda chip-row migration (Slice B).
- /admin/audit-log + /projects/:id/chart migration (Slice C).
- upckommentar-style range slicer for custom mode (Slice D, separate
  task).

docs/design-date-range-picker-2026-05-25.md

@@ -0,0 +1,856 @@
+# Symmetric date-range picker — design
+
+**Date:** 2026-05-25
+**Task:** t-paliad-248 (Gitea m/paliad#79)
+**Inventor:** atlas
+**Branch:** `mai/atlas/inventor-symmetric-date`
+**Status:** READ-ONLY design. Awaiting head's go/no-go before coder shift.
+
+---
+
+## §0 TL;DR
+
+Today paliad has **three independent date-range schemes** scattered across surfaces:
+
+1. **`/agenda`** — future-only chip row [7|14|30|90 Tage], state `rangeDays`.
+2. **`/admin/audit-log`** — past-only `<select>` [24h|7d|30d|custom|all] + manual `<input type="date">` pair.
+3. **`/projects/:id/chart`** — symmetric `RangePreset` [1y|2y|all|custom] + manual date pair.
+
+…plus a **fourth, unified `TimeHorizon` contract** (`internal/services/filter_spec.go`, mirrored in `frontend/src/client/views/types.ts`) that's used by the filter-bar, Verlauf, Custom Views, and InboxFilterBar — but its "Anpassen" custom-range chip is still stubbed (`filter-bar/axes.ts:105-112`, marked Phase 2, disabled, "coming soon" tooltip).
+
+The fix is **not** "build a fourth scheme." The fix is to **finish the TimeHorizon contract** (add `past_14d`, `next_14d`, `past_all`, `next_all`), build **one reusable `<DateRangePicker>`** that emits a `TimeSpec`, then migrate the three legacy affordances to it.
+
+**Layout (m's brief, locked):**
+
+```
+┌──────────────────────────────────────────────────────────────┐
+│ [Zeitraum: Nächste 30 Tage ▾]                                │
+└──────────────────────────────────────────────────────────────┘
+                ↓ click to open
+┌──────────────────────────────────────────────────────────────┐
+│  Vergangenheit          (ALLE)          Zukunft              │
+│  [Ganze Vergangenheit] [⌖ ALLE] [Ganze Zukunft]              │
+│  [90 T] [30 T] [14 T] [7 T]   [7 T] [14 T] [30 T] [90 T]     │
+│                                                              │
+│  ── oder benutzerdefiniert ──                                │
+│  Von [____.____.____]  Bis [____.____.____]   [Anwenden]     │
+└──────────────────────────────────────────────────────────────┘
+```
+
+**Slice plan:**
+
+- **Slice A** — `<DateRangePicker>` component + 4 new horizon constants (`past_14d`, `next_14d`, `past_all`, `next_all`). Wired onto filter-bar `time` axis first (lights up Verlauf + InboxFilterBar + views simultaneously by replacing the stubbed Phase-2 chip).
+- **Slice B** — `/agenda` migrates (highest-traffic standalone consumer).
+- **Slice C** — `/admin/audit-log` + `/projects/:id/chart` migrate. Each surface picks the preset subset it cares about.
+- **Slice D** *(optional, later)* — upckommentar-style two-handle slicer replaces the inline date-pair for the "custom" mode.
+
+**Hard rules honoured:**
+
+- No new top-level table or migration in Slice A — purely additive enum values + Go switch arms.
+- No new dependency in Slice A — slicer is deferred (it's a non-trivial port from Svelte to paliad's plain TSX renderer).
+- Backward-compatible URL shape — each surface keeps its current short-alias parser (e.g. `?range=30` → `horizon=next_30d`) and additionally accepts the canonical `?horizon=…&from=…&to=…`.
+
+---
+
+## §1 Current state — every date-range affordance
+
+Cataloguing **every** place a paliad user picks a past/future window, with file:line refs.
+
+### 1.1 `/agenda` — future-only chip row
+
+`frontend/src/agenda.tsx:64-67`:
+
+```tsx
+<button className="agenda-chip" data-range="7"  >7 Tage</button>
+<button className="agenda-chip" data-range="14" >14 Tage</button>
+<button className="agenda-chip" data-range="30" >30 Tage</button>
+<button className="agenda-chip" data-range="90" >90 Tage</button>
+```
+
+State machine `frontend/src/client/agenda.ts:80-104`:
+
+- `state.rangeDays ∈ {7,14,30,90}` (set `VALID_RANGES`). Default `30`.
+- URL: `?range=30&types=…&event_type=…`.
+- Fetch: `GET /api/agenda?from=<today>&to=<today+rangeDays-1>&types=…`.
+- **Future-only by construction** — m's complaint applies precisely here. No "past 7 days" affordance, no "all" affordance.
+
+### 1.2 `/admin/audit-log` — past-only `<select>` + manual date pair
+
+`frontend/src/admin-audit-log.tsx:50-65`:
+
+```tsx
+<select id="audit-range">
+  <option value="24h">Letzte 24h</option>
+  <option value="7d" selected>Letzte 7 Tage</option>
+  <option value="30d">Letzte 30 Tage</option>
+  <option value="custom">Benutzerdefiniert</option>
+  <option value="all">Alles</option>
+</select>
+<!-- custom toggles a date-pair: -->
+<input type="date" id="audit-from" />
+<input type="date" id="audit-to" />
+```
+
+State machine `frontend/src/client/admin-audit-log.ts:135-174`:
+
+- `rangePresetToFrom(preset)` converts `"24h" | "7d" | "30d"` → `Date`. `"custom"` reads `from`/`to` inputs. `"all"` clears both bounds.
+- URL: `?source=…&range=7d&q=…&from=…&to=…&limit=…&before_ts=…&before_id=…` (cursor-paged).
+- **Past-only by construction.** No future-projection — this is an audit log, looking forward makes no sense.
+
+### 1.3 `/projects/:id/chart` — symmetric `RangePreset`
+
+`frontend/src/client/views/types.ts:77-79`:
+
+```ts
+range_preset?: "1y" | "2y" | "all" | "custom";
+range_from?: string;
+range_to?: string;
+```
+
+UI `frontend/src/projects-chart.tsx:78-82`:
+
+```tsx
+<input type="date" id="projects-chart-range-from" />
+<input type="date" id="projects-chart-range-to" />
+```
+
+State machine `frontend/src/client/projects-chart.ts:73-118`:
+
+- `rangeFromURL()` → `{preset, from?, to?}` with default `"1y"`.
+- "1y" = `today-1y..today+1y`, "2y" = `today-2y..today+2y`, "all" derived from loaded events, "custom" = read inputs.
+- URL: `?range=1y&from=YYYY-MM-DD&to=YYYY-MM-DD`.
+- **Symmetric around today** by construction — this is a chart, not a filter; the user is panning a viewport, not picking a fan.
+
+### 1.4 `views-editor.tsx` (Custom Views config form)
+
+`frontend/src/views-editor.tsx:102-109`:
+
+```tsx
+<select id="editor-time-horizon">
+  <option value="next_7d">Nächste 7 Tage</option>
+  <option value="next_30d">Nächste 30 Tage</option>
+  <option value="next_90d">Nächste 90 Tage</option>
+  <option value="past_30d">Letzte 30 Tage</option>
+  <option value="past_90d">Letzte 90 Tage</option>
+  <option value="any">Beliebig</option>
+</select>
+```
+
+- Mixes past + future, but only 5 horizons exposed (no 14d, no past_7d, no all).
+- Persists into `paliad.user_views.filter_spec` (JSON column) as a `TimeSpec`.
+- **This is the closest existing affordance to m's symmetric fan**, but rendered as a plain `<select>` and incomplete.
+
+### 1.5 Filter-bar `time` axis (riemann's t-paliad-163 Phase 1)
+
+`frontend/src/client/filter-bar/axes.ts:65-115`:
+
+- Renders a chip cluster: `[next_7d, next_30d, next_90d, past_30d, any]` (default presets, line 77-79).
+- **"Anpassen" chip is disabled** with `coming_soon` tooltip (line 108-112). This is the documented Phase 2 substrate.
+- Surfaces declaring axis `time` thread their own preset list via `RenderAxisOpts.timePresets` — e.g. Verlauf overrides to `["past_7d","past_30d","past_90d","any"]` (`frontend/src/client/projects-detail.ts:2310`).
+
+Consumers:
+- `/projects/:id` Verlauf (`projects-detail.ts:2296` initial state, 2310 preset override).
+- `/views` and `/views/:id` (Custom Views runtime).
+- `/inbox` (`InboxFilterBar` flow — t-paliad-138/139 derived inbox).
+
+### 1.6 `horizonBounds()` — the materializer
+
+`frontend/src/client/projects-detail.ts:393-406` mirrors the Go-side `computeViewSpecBounds()` (`internal/services/view_service.go:156-187`):
+
+```ts
+case "past_7d":  return { from: offset(-7),  to: offset(1) };
+case "past_30d": return { from: offset(-30), to: offset(1) };
+case "past_90d": return { from: offset(-90), to: offset(1) };
+case "next_7d":  return { from: day,         to: offset(7) };
+case "next_30d": return { from: day,         to: offset(30) };
+case "next_90d": return { from: day,         to: offset(90) };
+default:         return {};
+```
+
+(Backend equivalent: `internal/services/view_service.go:160-186`.)
+
+### 1.7 Single-date inputs (NOT date-range — listed for completeness)
+
+These are out of scope but mentioned so the audit is exhaustive:
+
+- `verfahrensablauf.tsx:174` — `#trigger-date` (calculator anchor).
+- `fristenrechner.tsx:496,504,616` — `#trigger-date`, `#priority-date`, `#event-date` (calculator).
+- `admin-rules-edit.tsx:265` — `#preview-trigger-date`.
+- `deadlines-detail.tsx:82` — `#deadline-due-edit` (inline-edit).
+- `deadlines-new.tsx:116` — `#deadline-due` (form).
+- `appointments-new.tsx`, `appointments-detail.tsx` — `start_at`/`end_at`.
+- `projects-detail.tsx:181` — `#smart-timeline-milestone-date` (add-milestone modal).
+- `components/ProjectFormFields.tsx:134,138` — `#project-filing-date`, `#project-grant-date`.
+
+### 1.8 Summary matrix
+
+| Surface | Direction | Presets | Custom | URL contract | Default |
+|---|---|---|---|---|---|
+| `/agenda` | Future | 7\|14\|30\|90 | — | `?range=N` | 30d |
+| `/admin/audit-log` | Past | 24h\|7d\|30d\|all + custom | date pair | `?range=…&from=…&to=…` | 7d |
+| `/projects/:id/chart` | Symmetric ±N | 1y\|2y\|all + custom | date pair | `?range=…&from=…&to=…` | 1y |
+| `/views/:id` editor | Past+Future mix | next_7d\|next_30d\|next_90d\|past_30d\|past_90d\|any | — | persisted JSON | next_30d |
+| Filter-bar `time` axis | Past+Future mix | next_7d\|next_30d\|next_90d\|past_30d\|any | **stubbed** | persisted + `?…__time_from=` | per surface |
+| Verlauf | Past + any | past_7d\|past_30d\|past_90d\|any | **stubbed** | URL | past_30d |
+| InboxFilterBar | Mix | filter-bar default | **stubbed** | URL | per surface |
+
+Three of seven surfaces have **incomplete** custom-range affordances. None of the seven exposes the full symmetric fan m wants.
+
+---
+
+## §2 upckommentar slicer pattern
+
+Verified by reading source at `/home/m/dev/web/upc-kommentar/src/lib/`:
+
+- **`DateRangeSlider.svelte`** (component, 448 lines).
+- **`date-range-slider-pure.ts`** (pure-math helpers, 487 lines, fully unit-tested).
+- **`InboxFilterBar.svelte`** (host).
+
+### 2.1 What it is
+
+A **two-handle range slider** that wraps `svelte-range-slider-pips` (npm: `svelte-range-slider-pips@4`). The slider's rail is the upckommentar floor (`2023-01-01`) to today, and the two handles define `dateFrom` and `dateTo`. Step is **1 day** regardless of zoom.
+
+Public contract (DateRangeSlider.svelte:57-82):
+
+```ts
+interface Props {
+  minISO: string;                 // axis lower bound, default 2023-01-01
+  maxISO: string;                 // axis upper bound, today
+  fromISO: string | null;         // current From (null = parked at min)
+  toISO: string | null;           // current To   (null = parked at max)
+  onChange: (from, to) => void;   // emits on every slider change
+  testid?: string;
+  axisWidthPx?: number;           // test override for jsdom
+}
+```
+
+### 2.2 Anchor rail + granularity
+
+Below the slider rail is a **custom-rendered anchor rail** (the lib's own pips are hidden via `pips={false}` because they're evenly-spaced approximations — issue #42 in upckommentar). Anchor day-numbers come from `pipAnchorsFor(granularity, minDay, maxDay)`:
+
+- **year:** every Jan 1 in range.
+- **month:** every 1st-of-month.
+- **day:** every Monday.
+
+Edges (`minDay`, `maxDay`) are always anchors so the user can park at the slider's extremes.
+
+Granularity has **+/- zoom buttons** in the top-right of the slider (`year → month → day`), with each level showing more anchors.
+
+### 2.3 Click-to-snap (left half / right half)
+
+`DateRangeSlider.svelte:219-240` + pure helper `endOfPeriodDay()`:
+
+- **Left half of an anchor label** → snap closest handle to **start** of period (the anchor day itself, e.g. Jan 1).
+- **Right half of the same label** → snap to **end** of period (Dec 31 for year, last-of-month for month, Sunday for day).
+- Keyboard activation falls back to left-half (start-of-period) deterministically.
+
+### 2.4 Label thinning + two-row alternation
+
+`pipLabelStrideFor()` + `pipLabelRow()` (pure helpers):
+
+- Measures rail width via `ResizeObserver`.
+- Computes a stride — only every Nth label is rendered.
+- Adjacent rendered labels alternate row 0 / row 1 (~1.1em offset down) so they can sit closer horizontally without colliding.
+
+### 2.5 Handle behaviour
+
+- `range=true` draws a colored bar between handles.
+- `draggy=true` lets the user drag the **bar itself** to shift the window without changing its width.
+- `pushy=true` — handles push each other when crossed.
+- `float=true` — tooltip floats above the dragged handle showing `DD.MM.YYYY`.
+
+### 2.6 URL contract on host
+
+`InboxFilterBar.svelte` debounces `onChange` at 250ms, then writes:
+
+```
+?date_from=2024-03-15&date_to=2024-09-30
+```
+
+When a handle is parked at min/max, that bound is **omitted** from the URL (`valuesToFromTo()` in the pure module). So `?date_from=2024-03-15` alone means "from March 15 onwards, no upper bound."
+
+### 2.7 What's worth borrowing for paliad
+
+| Element | Borrow? | Why |
+|---|---|---|
+| Two-handle drag | **Yes — but defer to Slice D** | Excellent fine-tune UX. Non-trivial to port without `svelte-range-slider-pips` (or a Svelte ↔ TSX adapter). |
+| Anchor rail with click-to-snap | Yes (in Slice D) | Year/month/Monday anchors are the right granularities. |
+| Label thinning + two-row alternation | Yes (in Slice D) | Makes the rail readable at any width. |
+| Granularity + zoom +/- | Yes (in Slice D) | Single most useful interaction; users don't drag pixel-precise. |
+| Epoch-day pure math | Yes — verbatim | The `date-range-slider-pure.ts` module is well-tested and dependency-free. Port to TS in paliad's pure-helper layer. |
+| `null` = parked at edge | Yes — already aligned | TimeHorizon's `past_all` / `next_all` map cleanly to "one bound parked at infinity." |
+| The library `svelte-range-slider-pips` itself | **No** | Adds a Svelte dependency to a non-Svelte project. Slice D would build a tiny equivalent on top of `<input type="range">` × 2 + CSS — or vendor the lib's pure parts. |
+
+### 2.8 What does NOT apply to paliad
+
+- **Floor at 2023-01-01.** upckommentar starts at the UPC's first day. paliad has decade-old patents and future-projecting deadlines; the axis must extend in both directions. We use `today ± 5 years` as the default visible range with `past_all` / `next_all` chips to escape it.
+- **Single granularity locked per session.** upckommentar's UI shows one of year/month/day at a time. paliad's typical use ("next 30 days for the deadline list") doesn't benefit from a zoom; the chips ARE the granularity. Slicer in Slice D only opens when the user picks "Anpassen" — at which point the zoom UI makes sense.
+
+---
+
+## §3 Component design — `<DateRangePicker>`
+
+### 3.1 Public API
+
+```ts
+type TimeHorizonExt =
+  | "next_7d"  | "next_14d" | "next_30d" | "next_90d" | "next_all"
+  | "past_7d"  | "past_14d" | "past_30d" | "past_90d" | "past_all"
+  | "any" | "custom";
+
+interface DateRangePickerProps {
+  // Current state. The component is fully controlled.
+  value: TimeSpec;
+  onChange: (next: TimeSpec) => void;
+
+  // Per-surface preset filter — omit a chip by leaving it out of the array.
+  // Default: all symmetric chips + "any" + "custom".
+  presets?: TimeHorizonExt[];
+
+  // Closed-state button label override. Defaults to the i18n key for value.horizon
+  // (e.g. "Letzte 30 Tage"). Override for surfaces that want a heading prefix
+  // like "Zeitraum: Letzte 30 Tage".
+  labelPrefix?: string;
+
+  // i18n strings consumed via the i18n.ts dictionary. No props for individual labels.
+  // Localisation flows through existing data-i18n attributes.
+
+  // Surface tag — used to derive a stable testid and URL-param namespace if
+  // the host wires URL serialization through helpers we provide (see §4).
+  surface: string;          // e.g. "agenda" | "audit-log" | "filter-bar"
+
+  // Mode — popover (default) or modal (rare).
+  mode?: "popover" | "modal";
+
+  // Anchor / placement for popover mode. Defaults to "below".
+  placement?: "below" | "above" | "right";
+}
+```
+
+`TimeSpec` mirrors the existing shape (`internal/services/filter_spec.go:107-112`), extended with the 4 new horizon values:
+
+```ts
+interface TimeSpec {
+  horizon: TimeHorizonExt;
+  field?: "auto" | "created_at";
+  from?: string;            // ISO YYYY-MM-DD; set only when horizon === "custom"
+  to?: string;
+}
+```
+
+### 3.2 States
+
+The component is a small state machine:
+
+```
+closed ────[click button]────► open
+  ▲                              │
+  └──[click outside / Esc]───────┘
+                                 │
+       open ───[click chip]──── closed (commit immediately)
+                                 │
+       open ───[click "Anpassen"]► custom-editor
+                                 │
+       custom-editor ─[Anwenden]► closed (commit)
+       custom-editor ─[Esc]─────► open
+```
+
+- **closed** — single button with current selection label and a chevron `▾`. No outline/highlight unless the value is not the default for this surface.
+- **open** — popover anchored below the button (or below-then-flip-up on viewport-bottom). Contains the symmetric chip row + ALL center + "Anpassen" sub-section.
+- **custom-editor** — replaces the "Anpassen" link with two `<input type="date">` + "Anwenden" / "Abbrechen" buttons. (In Slice D this becomes the slicer.)
+
+### 3.3 Symmetric chip layout
+
+The popover body — full ASCII sketch:
+
+```
+┌─────────────────────────────────────────────────────────────┐
+│  ╭ Vergangenheit ────────╮ ╭ ALLES ╮ ╭ Zukunft ───────────╮ │
+│  │ [Ganze Vergangenheit] │ │ [⌖]   │ │ [Ganze Zukunft]    │ │
+│  │ [Letzte 90 Tage]      │ │       │ │ [Nächste 7 Tage]   │ │
+│  │ [Letzte 30 Tage]      │ │       │ │ [Nächste 14 Tage]  │ │
+│  │ [Letzte 14 Tage]      │ │       │ │ [Nächste 30 Tage]  │ │
+│  │ [Letzte 7 Tage]       │ │       │ │ [Nächste 90 Tage]  │ │
+│  ╰───────────────────────╯ ╰───────╯ ╰────────────────────╯ │
+│                                                             │
+│  ── Anpassen ──────────────────────────────────────────     │
+│  Von [____.____.____]  Bis [____.____.____]   [Anwenden]    │
+└─────────────────────────────────────────────────────────────┘
+```
+
+Visual cues:
+
+- The currently-selected chip gets the **lime accent** (`--color-bg-lime-tint` background, `--color-text` text, `--color-accent` border) — matches existing `.agenda-chip-active` so we don't introduce a new active state.
+- The "ALLES" center button is **larger** than the fan chips (44px tall vs. 32px), drawn with a target-style glyph `⌖` (or `∞` — see Q3.B). Inventor pick: `⌖` plus the word "ALLES" beneath. Larger so it reads as "the no-filter affordance," not as one chip among many.
+- The two fans are visually **mirrored** — past on the left, future on the right. Both have a "Ganze …" terminal chip at the outer edge (left-most for past_all, right-most for next_all) and decreasing-magnitude chips fanning toward the center. The ordering matches the human intuition: "left = back in time, right = forward in time."
+- On viewports < 480px the popover stacks vertically (past fan above, ALL middle, future fan below). On viewports < 360px the popover becomes a modal-feeling slide-up sheet (existing inbox modal CSS pattern reusable).
+
+### 3.4 Sketch of the closed button states
+
+```
+default:    ┌─Zeitraum: Nächste 30 Tage ▾─┐
+custom:     ┌─Zeitraum: 15.03.2026 – 30.04.2026 ▾─┐
+any:        ┌─Zeitraum: Alles ▾─┐
+past_all:   ┌─Zeitraum: Ganze Vergangenheit ▾─┐
+hover/open: same + outline + bg-accent-tint
+```
+
+When the value is **not** the surface default, an additional small `●` dot appears between "Zeitraum:" and the value — the existing universal "filter is non-default" indicator used by the filter-bar.
+
+### 3.5 Keyboard
+
+- `Tab` lands on the button. `Enter`/`Space` opens the popover.
+- `Esc` from open state closes it. `Esc` from custom-editor returns to chip view (one level back).
+- Chips are focusable buttons in the natural left-to-right reading order: past_all → past_90 → past_30 → past_14 → past_7 → any (center) → next_7 → next_14 → next_30 → next_90 → next_all.
+- The custom date inputs are `<input type="date" lang="de">` — gets the OS-native picker on macOS / iOS / Android / Windows. No new custom calendar widget.
+
+### 3.6 Accessibility
+
+- The button has `aria-haspopup="dialog"` and `aria-expanded` toggled on open/close.
+- The popover has `role="dialog"` with `aria-label` = `t("date_range.dialog.label")` ("Zeitraum wählen" / "Choose date range").
+- Chips are `<button>` with `aria-pressed="true"` on the active one.
+- The two fan groups have `role="group"` + `aria-label="Vergangenheit"` / `aria-label="Zukunft"`.
+
+### 3.7 Module layout
+
+```
+frontend/src/
+├── components/
+│   └── DateRangePicker.tsx          ← TSX shell (markup only)
+├── client/
+│   ├── date-range-picker.ts         ← mount() + state machine + DOM event wiring
+│   └── date-range-picker-pure.ts    ← horizon-bounds math, label resolver, parse/serialize
+└── styles/
+    └── global.css                    ← .date-range-* classes
+```
+
+`-pure.ts` is the headless module — fully testable under `bun test`. The boot client in `-picker.ts` consumes it, mirroring the pattern used by `shape-timeline-chart.ts` + `shape-timeline-chart.test.ts` (see memory: t-paliad-173 / gauss).
+
+Pure module exports (preliminary):
+
+```ts
+export function horizonBounds(h: TimeHorizonExt, now: Date): { from?: Date; to?: Date }
+export function labelForHorizon(h: TimeHorizonExt, lang: "de"|"en"): string
+export function labelForCustom(from: string, to: string, lang: "de"|"en"): string
+export function parseURL(params: URLSearchParams): TimeSpec
+export function serializeURL(spec: TimeSpec, defaults: Partial<TimeSpec>): URLSearchParams
+export function isDefault(spec: TimeSpec, default_: TimeSpec): boolean
+```
+
+### 3.8 Go-side additions
+
+`internal/services/filter_spec.go`:
+
+```go
+// Add four new constants alongside the existing TimeHorizon block.
+HorizonNext14d  TimeHorizon = "next_14d"
+HorizonPast14d  TimeHorizon = "past_14d"
+HorizonNextAll  TimeHorizon = "next_all"
+HorizonPastAll  TimeHorizon = "past_all"
+```
+
+`internal/services/view_service.go:computeViewSpecBounds()`:
+
+```go
+case HorizonNext14d:
+    bounds.from = &startOfDay; t := startOfDay.AddDate(0, 0, 14);  bounds.to = &t
+case HorizonPast14d:
+    f := startOfDay.AddDate(0, 0, -14); bounds.from = &f;          bounds.to = &startOfTomorrow
+case HorizonNextAll:
+    bounds.from = &startOfDay
+    // bounds.to left nil  → "no upper bound"
+case HorizonPastAll:
+    bounds.to = &startOfTomorrow
+    // bounds.from left nil
+```
+
+`HorizonNextAll` and `HorizonPastAll` are **one-sided unbounded** — distinct from existing `HorizonAll` (bidirectional unbounded) and `HorizonAny` (no filter at all, same effect as `HorizonAll` for view-spec runtime but different in intent).
+
+`filter_spec.go:validate()` (line 280-292) gains the two new past/next constants in the switch.
+
+### 3.9 i18n keys
+
+Two-language matrix (DE primary, EN secondary):
+
+```
+date_range.button.label                 "Zeitraum"               / "Time range"
+date_range.button.label.custom          "Von … bis …"            / "From … to …"
+date_range.horizon.next_7d              "Nächste 7 Tage"         / "Next 7 days"
+date_range.horizon.next_14d             "Nächste 14 Tage"        / "Next 14 days"
+date_range.horizon.next_30d             "Nächste 30 Tage"        / "Next 30 days"
+date_range.horizon.next_90d             "Nächste 90 Tage"        / "Next 90 days"
+date_range.horizon.next_all             "Ganze Zukunft"          / "All future"
+date_range.horizon.past_7d              "Letzte 7 Tage"          / "Last 7 days"
+date_range.horizon.past_14d             "Letzte 14 Tage"         / "Last 14 days"
+date_range.horizon.past_30d             "Letzte 30 Tage"         / "Last 30 days"
+date_range.horizon.past_90d             "Letzte 90 Tage"         / "Last 90 days"
+date_range.horizon.past_all             "Ganze Vergangenheit"    / "All past"
+date_range.horizon.any                  "Alles"                  / "All"
+date_range.horizon.custom               "Benutzerdefiniert"      / "Custom"
+date_range.dialog.label                 "Zeitraum wählen"        / "Choose date range"
+date_range.fan.past.label               "Vergangenheit"          / "Past"
+date_range.fan.future.label             "Zukunft"                / "Future"
+date_range.center.label                 "Alles"                  / "All"
+date_range.custom.from                  "Von"                    / "From"
+date_range.custom.to                    "Bis"                    / "To"
+date_range.custom.apply                 "Anwenden"               / "Apply"
+date_range.custom.cancel                "Abbrechen"              / "Cancel"
+date_range.custom.invalid               "Bis-Datum muss nach Von-Datum liegen." / "End date must be after start date."
+```
+
+Total: 21 keys × 2 langs = 42 new entries in `i18n.ts`. Existing per-surface keys (`agenda.range.7`, `admin.audit.range.24h`, `views.bar.time.next_30d` etc.) stay until each surface migrates, then get retired.
+
+---
+
+## §4 URL / form serialization contract
+
+### 4.1 Canonical URL shape
+
+The picker writes (and reads) **canonical** params on the host's URL:
+
+```
+?horizon=next_30d
+?horizon=past_all
+?horizon=any           ← omitted if it matches the surface default
+?horizon=custom&from=2026-03-15&to=2026-04-30
+```
+
+The host page's URL-init code (`bootDateRangePicker(surface, opts)`) calls `parseURL(searchParams)` to derive the initial `TimeSpec`, then calls `serializeURL(spec, defaults)` on every change. Params equal to the surface default are **omitted** so the canonical URL stays short and dedupable — matches the existing `writeParamToURL` pattern in `projects-chart.ts:144-154`.
+
+### 4.2 Backwards-compat aliases
+
+Each migrating surface keeps its existing alias parser for the transition window:
+
+| Surface | Legacy URL | Canonical URL | Adapter |
+|---|---|---|---|
+| `/agenda` | `?range=30` | `?horizon=next_30d` | `range=N → horizon=next_${N}d` if `N ∈ {7,14,30,90}`, else `next_all` for `N>90`. Read both, write canonical. |
+| `/admin/audit-log` | `?range=7d` | `?horizon=past_7d` | `range=24h → horizon=past_1d` (new, see Q5) or kept as `past_7d` fallback. `range=all → horizon=any`. |
+| `/projects/:id/chart` | `?range=1y` | `?range=1y` (kept) | **NOT migrated to TimeHorizon** — projects-chart is symmetric-around-today. It uses DateRangePicker only for its **custom**-mode UI (the date-pair → slicer in Slice D). The 1y/2y/all presets stay surface-specific. |
+
+The Go side is unaffected by aliasing — handlers receive whatever shape they always have, and the URL alias adapter lives entirely client-side per surface. **No backend route signature changes** in Slice A.
+
+### 4.3 Custom Views (persisted JSON)
+
+`paliad.user_views.filter_spec` is a JSON column. The TimeSpec extension is additive (new enum values, no shape change). Existing rows continue to validate. Migration not needed.
+
+### 4.4 Form fields (Custom Views editor)
+
+`views-editor.tsx:102-109` migrates from `<select>` to the picker. The form submits the same FormData shape (just one extra key for custom from/to — already plumbed via TimeSpec.from / TimeSpec.to). The Go-side `parseViewForm()` (TBD by coder) gains 4 new acceptable horizon values; existing test cases continue to pass.
+
+---
+
+## §5 Migration plan
+
+### Slice A — substrate + filter-bar `time` axis
+
+**Backend** (single migration not needed — additive constants only):
+
+- `internal/services/filter_spec.go` — 4 new `TimeHorizon` constants + validate switch arms.
+- `internal/services/view_service.go` — `computeViewSpecBounds()` 4 new switch cases.
+- Pure unit tests for each new horizon (zero DB).
+
+**Frontend**:
+
+- New `frontend/src/components/DateRangePicker.tsx` + boot client + pure module.
+- New i18n keys (42 entries).
+- `frontend/src/client/filter-bar/axes.ts:renderTimeAxis()` — replace the disabled "Anpassen" stub with the picker. The chip cluster either becomes the picker's open-state (preferred) OR the chips stay flat and the picker only opens on "Anpassen" click (fallback if popover-in-bar is visually noisy). **Inventor pick (R): chips stay flat in the bar; "Anpassen" chip becomes the picker trigger. Picker emits TimeSpec back into the bar's state, same patch path.**
+
+**Surfaces lit up automatically**: Verlauf (`/projects/:id`), Custom Views (`/views`, `/views/:id`), InboxFilterBar (`/inbox`).
+
+**LoC estimate**: ~600 LoC (pure: 180 / boot: 180 / TSX: 100 / CSS: 80 / Go: 30 / tests: 240). Tests-first per `docs/design-paliad-test-strategy-2026-05-19.md`.
+
+### Slice B — `/agenda`
+
+- `agenda.tsx:51-69` — replace chip rows with `<DateRangePicker surface="agenda" presets={["next_7d","next_14d","next_30d","next_90d","next_all","custom"]} />`.
+- `client/agenda.ts:85-104` — replace `wireControls()` chip wiring with picker subscription.
+- URL alias adapter — accept `?range=N` for back-compat, emit `?horizon=…`.
+
+**LoC**: ~80 LoC delta, mostly deletion.
+
+### Slice C — `/admin/audit-log` + `/projects/:id/chart`
+
+- `admin-audit-log.tsx:50-65` — replace `<select>` + date-pair with `<DateRangePicker surface="audit-log" presets={["past_7d","past_14d","past_30d","past_90d","past_all","custom"]} />`.
+- `projects-chart.tsx:75-83` — **wrap** the existing 1y/2y/all presets in a custom-prop variant (a sibling component `<SymmetricRangePicker>` that shares the picker's popover scaffolding but emits the surface-specific `range_preset`). Or — if the head/m prefers — fold 1y/2y/all into TimeHorizon as `sym_1y` / `sym_2y` / `sym_all`. **Inventor pick (R): sibling component**, because symmetric-around-today is conceptually different from past/future fan. See §8 Q1.
+
+**LoC**: ~120 LoC for audit-log, ~80 LoC for projects-chart wrap.
+
+### Slice D *(optional, separate task)* — slicer
+
+- Add `<DateRangeSlicer>` for the custom-editor sub-pane. Built on `<input type="range">` × 2 with a custom anchor rail above, ported from `date-range-slider-pure.ts`.
+- Replaces inline date-pair when `horizon === "custom"` and `surface ∈ {agenda, audit-log, filter-bar}`. Projects-chart keeps inline date-pair OR also uses slicer — its choice.
+- No new dependency.
+- ~400 LoC including pure helpers + DOM scaffolding + tests.
+
+### Per-slice rollout
+
+| Slice | Risk | Surfaces affected | Coder profile |
+|---|---|---|---|
+| A | Low — additive only | 4 (filter-bar + 3 consumers) | Pattern-fluent Sonnet |
+| B | Low | 1 | Same coder |
+| C | Medium (projects-chart sibling) | 2 | Same coder |
+| D | Medium (new slicer) | 0 (additive on top of A) | Separate task |
+
+---
+
+## §6 Visual decisions
+
+### 6.1 Chip labels
+
+Final labels — bilingual (DE first):
+
+| Chip | DE | EN |
+|---|---|---|
+| past_all | Ganze Vergangenheit | All past |
+| past_90d | Letzte 90 Tage | Last 90 days |
+| past_30d | Letzte 30 Tage | Last 30 days |
+| past_14d | Letzte 14 Tage | Last 14 days |
+| past_7d | Letzte 7 Tage | Last 7 days |
+| any (center) | Alles | All |
+| next_7d | Nächste 7 Tage | Next 7 days |
+| next_14d | Nächste 14 Tage | Next 14 days |
+| next_30d | Nächste 30 Tage | Next 30 days |
+| next_90d | Nächste 90 Tage | Next 90 days |
+| next_all | Ganze Zukunft | All future |
+| custom | Anpassen | Customize |
+
+Rationale on "Anpassen" vs "Benutzerdefiniert":
+- "Anpassen" matches existing `views.bar.time.custom` key value in `i18n.ts`.
+- "Benutzerdefiniert" is used in admin-audit-log's dropdown — verbose, but more accurate.
+- (R): **Anpassen** (consistent with filter-bar; six chars vs. eighteen).
+
+### 6.2 Accent / active state
+
+Reuse the existing **lime accent** chip-active state (`--color-bg-lime-tint` background, `--color-accent` border, `--color-text` text). This is the established affordance for the `agenda-chip-active` class — same visual reused, no new accent token.
+
+### 6.3 The "ALLES" center button
+
+A larger, target-glyph button — visually distinct from the fan chips so the user reads it as the "no time filter" exit, not as one chip among many:
+
+```
+   ╭──────╮
+   │  ⌖   │
+   │ ALLES│
+   ╰──────╯
+```
+
+(R) glyph: `⌖` (Unicode U+2316 POSITION INDICATOR). Alternatives considered: `∞` (too math-y), `⊕` (too connect-y), `▣` (too checkbox-y), no glyph (chip then looks like every other chip). See §8 Q3.B.
+
+### 6.4 Custom-range entry
+
+In Slice A: **inline date-pair below the chip rows**, with an "Anwenden" button that commits + closes the picker. Plain `<input type="date" lang="de">` — gets the OS-native picker.
+
+In Slice D (later): same slot becomes the slicer. The chip rows remain; the slicer collapses under them so the user can switch back to a chip with one click.
+
+### 6.5 Hover / focus
+
+- Chip hover: existing `.agenda-chip:hover` (lighter background tint).
+- Chip focus-visible: 2px outline using `--color-accent`.
+- Button focus-visible: same.
+- Popover entry: 120ms fade-in via `transform: translateY(-4px) → 0` + opacity. Reduced-motion users (prefers-reduced-motion: reduce) get instant show.
+
+### 6.6 Indication that the filter is non-default
+
+The closed button shows a small `●` dot to the left of the label when the value is **not** the surface default. This matches the existing filter-bar non-default-indicator pattern (`frontend/src/client/filter-bar/index.ts` has a similar dot but on the whole bar; we adopt it per-control).
+
+---
+
+## §7 Edge cases
+
+### 7.1 Timezones
+
+All horizon math runs against **UTC `startOfDay`** of `new Date()` — same convention as `horizonBounds()` in `projects-detail.ts:393-406`. The user's browser may be in CEST in summer or CET in winter; the picker still treats "today" as a UTC date for filter purposes. The date-input localizes display (German locale → DD.MM.YYYY) but the underlying ISO is `YYYY-MM-DD` parsed as UTC midnight.
+
+Practical impact: a user in CEST clicking "Letzte 7 Tage" at 01:30 local on 2026-06-15 sees `from=2026-06-07T00:00Z, to=2026-06-15T00:00Z` even though their local clock shows the 15th. This matches every other date-filter in paliad and avoids "the same row vanishes at 01:00 vs. 23:00" surprises. Document the convention in the pure module's header comment.
+
+### 7.2 Far past truncation
+
+`past_all` materialises to `from: nil`. The Go side (view_service.go) treats nil as "no lower bound" — the SQL `WHERE due_date >= ?` clause is omitted. No truncation needed.
+
+For projects-chart's symmetric "all" mode, "all" still means **bounds derived from loaded events** (status quo) — the picker for projects-chart's surface uses the sibling `<SymmetricRangePicker>` which doesn't have `past_all`/`next_all` chips, only `1y/2y/all`.
+
+### 7.3 Overlapping selections — past_7 + next_7 simultaneously?
+
+The picker is **single-select** — one chip active at a time, OR custom mode. m's brief doesn't mention multi-select and the existing TimeSpec is single-valued. Multi-select would require a fundamental contract change. Don't.
+
+If a user genuinely wants "last 7 days OR next 7 days," they use the custom-range with `from=today-7d`, `to=today+7d` — which is what `±1w` would mean. The fact that this is two chip-clicks vs. one isn't a real ergonomic loss.
+
+### 7.4 Custom dates with from > to
+
+Validate client-side: when both inputs are filled and `from > to`, the "Anwenden" button is disabled and a hint appears: "Bis-Datum muss nach Von-Datum liegen" (i18n key `date_range.custom.invalid`). The picker does **not** auto-swap.
+
+### 7.5 Empty inputs in custom mode
+
+If the user clicks "Anpassen" then clicks elsewhere before filling inputs, the picker reverts to whatever horizon was active before (state cached on entry to custom-editor). No "half-custom" state persists.
+
+### 7.6 Surface-specific preset overrides
+
+Each surface declares its own presets via the `presets` prop. The picker hides chips not in the array. The default surface preset (read from `defaults` prop, or hardcoded if absent) is what `serializeURL()` omits from the URL.
+
+Important invariant: `defaults` must be a member of `presets`, OR be a special value like `any` that's always rendered. The component asserts this at boot and falls back to `any` if violated.
+
+### 7.7 Bilingual labels mid-session
+
+`labelForHorizon()` consults the live `i18n.ts` dictionary on every render, so a language toggle updates the picker immediately — including the closed-button label.
+
+### 7.8 Embedded picker inside a filter bar
+
+When the picker is mounted inside `filter-bar`, it should NOT use a full popover overlay — the filter bar already wraps controls. Instead the open-state's chip rows render **inline below the time chip cluster**, expanding the bar's height. This is `mode="inline"` (a third mode beyond popover/modal). Slice A picks this for filter-bar consumers; standalone surfaces (`/agenda`, `/admin/audit-log`) use popover mode.
+
+### 7.9 What happens if a saved Custom View references `past_14d` before Slice A ships?
+
+The JSON validator rejects it (`filter_spec.go:validate()` enum check). Saved views are migration-safe in one direction only — adding new enum values is fine; removing is not. Slice A adds, doesn't remove. No issue.
+
+### 7.10 Race: URL change while picker is open
+
+If the user has the picker open and a URL change happens via another control (e.g. they Cmd-Click a sidebar link), the picker is unmounted naturally with the page navigation. No state to preserve across navigations.
+
+---
+
+## §8 Open questions for m
+
+Per task brief: **no AskUserQuestion**. Material picks escalated via `mai instruct head`; everything else defaults to (R) below. The head decides whether to forward to m or rule on the spot.
+
+### Q1 [MATERIAL — escalate]: How to handle `/projects/:id/chart`?
+
+The chart's range presets are **symmetric around today** (1y / 2y / all = ±1y / ±2y / all-data-bounds), conceptually different from past/future fans. Options:
+
+- **(R) A — sibling component.** Keep a separate `<SymmetricRangePicker>` for the chart surface. Same popover scaffolding, different chip set. Chart's URL stays `?range=1y`. Doesn't add to TimeHorizon.
+- **B — fold into TimeHorizon.** Add `sym_1y`, `sym_2y`, `sym_all` constants. Picker prop selects which fan vs. symmetric. Saved views could then express "±1y" too.
+- **C — leave the chart as-is.** Don't migrate. Accept the visual inconsistency.
+
+(R) **A.** Symmetric vs fan is a real semantic difference; one component trying to be both is muddier than two components sharing scaffolding. The chart isn't a "filter" — it's a viewport, and viewports legitimately want symmetric panning.
+
+### Q2 [MATERIAL — escalate]: Modal vs popover for the standalone case?
+
+m's brief says "mini modal." Options:
+
+- **(R) A — popover always.** Anchored to the trigger button, click-outside dismiss. In-context, lightweight.
+- **B — modal for explicit "open date filter" intent.** Use a centered modal with scrim when the picker is the page's primary filter (e.g. `/admin/audit-log` where date is the most prominent control). Popover for embedded uses.
+- **C — modal everywhere.** Strong visual hierarchy, but interrupts the user.
+
+(R) **A.** Modal feels heavy for what is conceptually a chip cluster. The "mini" qualifier in m's wording suggests popover, not full modal. If a surface specifically needs the modal weight, the `mode="modal"` prop is available — but no default surface picks it.
+
+### Q3 [MATERIAL — escalate]: Slice priority — what migrates first?
+
+- **(R) A — filter-bar `time` axis first** (Slice A). Lights up 4 surfaces simultaneously (Verlauf, InboxFilterBar, views runtime, Custom Views editor) by replacing the existing Phase-2 disabled stub.
+- **B — `/agenda` first** (per task brief default). Highest-traffic standalone surface, simplest migration.
+- **C — both A and B in parallel** (head splits between two coders).
+
+(R) **A.** Filter-bar is the substrate everything else either uses or should use. Lighting it up first turns three downstream surfaces from "almost working" (the stubbed custom-range chip with "coming_soon" tooltip) to "fully working." Agenda then migrates as Slice B, on top of a proven component.
+
+### Q3.B [DEFAULT — no escalation needed]: ALL center button glyph?
+
+- **(R) `⌖`** (POSITION INDICATOR, U+2316). Implies "center / pin to here."
+- B `∞` (infinity). Mathy.
+- C `⊕` (circled plus). Looks like a button.
+- D No glyph, just "ALLES" in bold.
+
+(R) `⌖`. If the head/m doesn't like the unicode lookup, D is the safe fallback.
+
+### Q4 [DEFAULT — no escalation]: Custom-range entry in Slice A?
+
+- **(R)** Inline `<input type="date">` pair, OS-native picker. Slice D adds the slicer.
+
+### Q5 [DEFAULT — no escalation]: Past `24h` in audit-log?
+
+audit-log currently has a `24h` preset; the picker would express this as `past_1d`. Options:
+
+- **(R)** Map legacy `?range=24h` → `?horizon=past_1d`. Add a new `past_1d` constant.
+- B Drop `24h` — audit log defaults to `past_7d` like other surfaces. Users wanting "last 24h" use custom mode.
+
+(R) Add `past_1d`. It's a one-line addition and audit-log users genuinely use "last 24h" for incident triage.
+
+(Note: this means the picker actually has 5 past chips + 5 future chips + center + custom = 12 chips total, which fits comfortably in the popover.)
+
+### Q6 [DEFAULT — no escalation]: Slice D (slicer) — separate task or fold in?
+
+- **(R) Separate task.** Slice A-C are independently shippable. Slice D is meaningful design + ~400 LoC and shouldn't gate the main migration.
+
+### Q7 [DEFAULT — no escalation]: Per-surface defaults?
+
+Each migrating surface keeps its current default exactly:
+
+- `/agenda` → `next_30d` (was 30).
+- `/admin/audit-log` → `past_7d` (was 7d).
+- `/projects/:id` Verlauf → `past_30d` (was past_30d in `projects-detail.ts:2310`).
+- `/views/:id` runtime → whatever the saved view has (no change).
+- `/inbox` (InboxFilterBar) → whatever filter-bar's surface defines.
+
+### Q8 [DEFAULT — no escalation]: Should `past_14d` and `next_14d` retroactively appear in `views-editor.tsx`'s `<select>`?
+
+(R) **Yes** — once Slice A ships, the `<select>` in `views-editor.tsx` is replaced by the picker (part of Slice A, as filter-bar consumers all flip in one commit). All 12 preset values become available for new Custom Views.
+
+---
+
+## §9 Implementer notes (for the coder shift, if approved)
+
+### Lessons embedded
+
+- **TimeSpec extension is additive only** — Go enum + TS union + i18n keys + horizonBounds switch. No DB migration, no contract break.
+- **Pure module is testable under `bun test`** — no DOM needed for horizon math, label resolution, URL serialization. Aim for 95%+ coverage of the pure module before touching the boot client.
+- **Reuse `.agenda-chip` styling** — adds no new tokens, no new dark-mode contrast risk (cf. memory t-paliad-150 / fritz — fritz lost 90 minutes to a `var(--token, #hex)` fallback bug because the token wasn't defined in dark mode).
+- **`mode="inline"` for filter-bar consumers** — the bar already wraps its own popover-like layout; nesting popovers gets visually noisy.
+- **Surface defaults must be members of `presets`** — assert at boot, fail loud in dev, fall back to `any` in prod.
+
+### Recommended coder profile
+
+Pattern-fluent Sonnet. Substrate is well-trodden (TimeSpec/TimeHorizon already lives, chip-cluster CSS exists, URL-codec pattern documented in `projects-chart.ts`). The novel piece is the popover scaffolding — paliad doesn't have a generic Popover primitive today; the picker builds its own DOM-anchored overlay. ~80 LoC of plain JS, no dependency.
+
+### Build hygiene checklist
+
+- `go build ./...` clean
+- `go vet ./...` clean
+- `go test ./...` clean (existing tests must continue passing — additive constants change zero behaviour)
+- `bun run build` clean (i18n scan: 21 new keys added, all `data-i18n` attributes present)
+- bun:test covers the pure module (horizon math, label resolver, URL parser/serializer)
+- Playwright smoke (manual, not gated): on `/inbox` the time axis "Anpassen" chip is now functional; custom-from/to date pair commits a usable filter.
+
+### Out of scope for the coder
+
+- Slicer (Slice D) — separate task.
+- Per-language adjustments beyond DE/EN (per task brief, out of scope).
+- Time-of-day picking — separate concern.
+- Recurring-event windows — events feed handles separately.
+- A generic Popover primitive — extract only if a second consumer appears in the same slice.
+
+### Acceptance criteria for Slice A
+
+1. New `<DateRangePicker>` mounts on filter-bar's `time` axis, replacing the disabled "Anpassen" chip.
+2. The 4 new horizon values (`past_14d`, `next_14d`, `past_all`, `next_all`) are accepted by Go's `TimeSpec.validate()` and produce correct `(from, to)` bounds in `computeViewSpecBounds()`.
+3. The 4 new horizons round-trip through saved Custom Views (`paliad.user_views.filter_spec` JSON).
+4. URL serialization is canonical (`?horizon=…&from=…&to=…`) and surface-default values are omitted.
+5. Verlauf (`/projects/:id`), `/views`, `/views/:id`, and `/inbox` continue to function with their existing presets unchanged — they pick up the new picker but don't switch their preset list yet.
+6. Pure-module unit tests cover: 12 horizons × bound calculation; URL parse / serialize round-trip; default-omission rule; custom-mode date validation.
+7. `bun run build` reports the new i18n keys (no missing-key warnings).
+8. No regression in `go test ./internal/services/...` (existing TimeSpec tests stay green).
+
+---
+
+## §10 Material picks summary — escalation message
+
+To be sent via `mai instruct head` after this doc is pushed:
+
+> Three material picks for m on date-range-picker design:
+>
+> 1. **`/projects/:id/chart` migration** — keep symmetric (1y/2y/all) presets as a sibling component, NOT fold into TimeHorizon. Chart is a viewport, not a filter.
+> 2. **Popover vs modal** — popover by default. Modal is a `mode` prop available per surface but no surface picks it in Slice A.
+> 3. **Slice A first migrates filter-bar time axis** (lights up Verlauf + InboxFilterBar + Views + Custom-Views-editor simultaneously by un-stubbing the existing "Anpassen" chip), not `/agenda` as the task brief defaulted. `/agenda` is Slice B.
+>
+> Everything else (chip labels, accent, glyph, custom-mode entry, surface defaults, past_1d for audit, slicer-as-Slice-D, 42 i18n keys) defaults per (R) in §8. Doc at `docs/design-date-range-picker-2026-05-25.md`.
+
+---
+
+*Verified premises (live, before designing):*
+
+- `internal/services/filter_spec.go:107-126` — TimeHorizon enum at 9 values today.
+- `internal/services/view_service.go:156-187` — `computeViewSpecBounds()` switches on the same enum.
+- `frontend/src/client/views/types.ts:21-33` — TimeHorizon TS mirror; same 9 values.
+- `frontend/src/client/filter-bar/axes.ts:65-115` — chip cluster renderer; "Anpassen" stub at line 105-112 marked Phase 2, disabled, "coming_soon" tooltip.
+- `frontend/src/agenda.tsx:64-67` — chip row exact values `7|14|30|90`.
+- `frontend/src/admin-audit-log.tsx:50-65` — select exact values `24h|7d|30d|custom|all`.
+- `frontend/src/projects-chart.tsx:78-82` + `frontend/src/client/projects-chart.ts:73-118` — RangePreset `1y|2y|all|custom`, symmetric around today.
+- `frontend/src/views-editor.tsx:102-109` — select exact values `next_7d|next_30d|next_90d|past_30d|past_90d|any`.
+- `/home/m/dev/web/upc-kommentar/src/lib/components/DateRangeSlider.svelte` — 448 lines, wraps `svelte-range-slider-pips@4`, custom anchor rail above the lib's hidden pips, click-to-snap left/right halves, granularity year/month/day zoom.
+- `/home/m/dev/web/upc-kommentar/src/lib/modules/date-range-slider/date-range-slider-pure.ts` — 487 lines, fully testable pure helpers, dependency-free, portable to paliad's TS.
+
+*Not verified live:* upckommentar.de in a browser (requires author auth; the source code IS the source of truth and was read end-to-end).

docs/research-deadlines-completeness-2026-05-25.md

@@ -0,0 +1,956 @@
+# Bulletproof completeness audit — paliad.deadline_rules vs statutory sources
+
+**Author:** curie (researcher)
+**Date:** 2026-05-25
+**Task:** t-paliad-263 (m/paliad#94)
+**Mode:** read-only research, no DB writes
+**Branch:** `mai/curie/researcher-bulletproof`
+
+Scope confirmed by head (paliad/head → paliad/curie, 2026-05-25 15:13):
+**UPC Rules of Procedure + EPC + PatG / ZPO / GebrMG**, plus UPC Agreement /
+Statute where they create time-limits. No HLC-internal checklists exist in
+the current head's working tree.
+
+Companion / prior audits this report supersedes-and-extends:
+
+- `docs/audit-fristenrechner-completeness-2026-04-30.md` (curie, t-paliad-084) — youpc-vs-paliad gap analysis.
+- `docs/audit-upc-rop-deadlines-2026-05-08.md` (curie, t-paliad-159) — first UPC RoP gap list (52 rules / 2 duration bugs).
+- `docs/audit-fristen-logic-2026-05-13.md` (pauli, t-paliad-157) — schema audit; the codes used here (`upc.inf.cfi`, `de.inf.lg`, …) reflect the post-mig-096 rename.
+
+Migration baseline: migration ≤ `122_deadlines_custom_rule_text` (live as of 2026-05-25 14:00 UTC).
+
+---
+
+## §0. TL;DR
+
+- **20 active fristenrechner proceeding_types** (live, `is_active=true`,
+  `lifecycle_state='published'`) carry **132 active rules**. One extra
+  `_archived_litigation` row holds 40 retired Pipeline-A rules from
+  mig 093 — not surfaced anywhere, kept only for FK validity.
+
+| Jurisdiction | Active types | Active rules | Statute-bound rules audited |
+|---|---:|---:|---:|
+| UPC (CFI + CoA) | 9 (incl. upc.ccr.cfi alias) | 67 | 67 |
+| EPA | 3 | 23 | 23 |
+| DPMA | 3 | 13 | 13 |
+| DE (LG/OLG/BGH/BPatG) | 5 | 29 | 29 |
+| **Total** | **20** | **132** | **132** |
+
+- **5 high-impact bugs still live** that the prior May 8 audit
+  surfaced (2) plus 3 new ones identified here.
+  - 🔴 **`upc.rev.cfi.defence` 3 months, RoP.49.1 says 2 months.** Flagged
+    May 8; still live. ★★★ — every UPC_REV defendant.
+  - 🔴 **`upc.rev.cfi.rejoin` 2 months, RoP.52 says 1 month.** Flagged
+    May 8; still live. ★★★ — every UPC_REV proceeding.
+  - 🟠 **`upc.apl.merits.response` 2 months, RoP.235.1 says 3 months.**
+    New finding (May 8 audit recorded the rule as "3 months / present-wrong
+    rule_code only" — actually live data shows 2 months, so the audit
+    sample mis-recorded the duration too). ★★★ — every UPC main-track
+    appeal respondent.
+  - 🟠 **`de.inf.lg.beruf_begr` chains parent = berufung (1mo) + 2mo = 3mo
+    from urteil. ZPO §520(2) anchors the 2-month Begründungsfrist on
+    service of urteil, not on filing of Berufung.** New finding.
+    ★★★ — every DE-first-instance appellant.
+  - 🟠 **`de.inf.lg.replik` + `.duplik` have `parent_id=NULL` so they fire
+    on the trigger date (Klageerhebung) — sequence-order says 30/40 but
+    the compute engine reads parent_id first.** Reported as live UI bug
+    by m via head (2026-05-25 13:13); confirmed by SQL. ★★★ — every
+    DE-LG-Verletzung timeline.
+
+- **5 rule-code / citation drift bugs still live** from the May 8 audit
+  (`upc.apl.merits.notice`, `.grounds`, `.response`, `upc.rev.cfi.reply`,
+  `.rejoin`) — durations may or may not be right, but the cited
+  `legal_source` / `rule_code` points at the wrong rule. Pure
+  cosmetic on `.notice`/`.grounds` (durations are right); load-bearing on
+  `.rev.cfi.reply` / `.rejoin` because the cited rule is what tells
+  the lawyer where to look the rule up.
+
+- **4 DPMA / DE citation bugs** new in this audit, all citing PatG / ZPO
+  sections that don't contain the cited deadline:
+  - `de.null.bpatg.erwidg` cites `DE.PatG.82.1`; the 2-month Erwiderung
+    is actually `§82(3)` (§82(1) is the 1-month Erklärungsfrist).
+  - `dpma.opp.dpma.erwiderung` cites `DE.PatG.59.3`; §59(3) is about
+    hearings, not a 4-month proprietor response. The 4-month figure is
+    DPMA-internal practice, not statutory — should be court-set.
+  - `dpma.appeal.bpatg.begruendung` cites `DE.PatG.75.1`; §75 is about
+    *aufschiebende Wirkung* — there is no Begründungsfrist in PatG §73-§80
+    for the BPatG-Beschwerde. The 1-month figure is also non-statutory.
+  - `de.null.bgh.begruendung` cites `DE.PatG.111.1`; §111 is about the
+    grounds-of-appeal *content* (Verletzung des Bundesrechts), not the
+    Begründungsfrist. `de.null.bgh.erwiderung` cites `DE.PatG.111.3`;
+    §111(3) doesn't exist in the deadline sense.
+
+- **Wide UPC coverage gap inherited from May 8 audit, mostly un-closed:**
+  ~25 missing UPC RoP rules. Mig 095 (t-paliad-205) closed 4 of them
+  (R.19 Preliminary Objection on UPC_INF and UPC_REV, R.220.1(a)
+  merits-appeal spawn on both). The other ~21 (R.20.2, R.118.4,
+  R.197.3, R.198, R.207.6.a, R.207.9, R.213, R.109.1/.4/.5, R.118.5,
+  R.144, R.155, R.224.2(b), R.229.2, R.235.2, R.245.x, R.262.2,
+  R.321.3, R.333.2, R.353, plus the DNI family R.63-R.69) are
+  unchanged.
+
+- **EPC gaps:** EPA opposition + Beschwerde modelled at the
+  Article level only. Missing the entire Implementing Regulations
+  family that drives day-to-day deadlines — R.71(3) approval period
+  is half-modelled (the 4-month figure is there but the trigger
+  anchor is broken: parent_id=NULL), R.79(1) proprietor response
+  is modelled as a fixed 4-month period when it's actually
+  court-set, R.116 oral-proceedings cut-off is modelled as
+  duration-0/parent-NULL (works for some uses, not for others),
+  R.121 / R.135 Weiterbehandlung is missing entirely (concept
+  exists but no rule).
+
+- **DE/DPMA gaps:** the entire Wiedereinsetzung family (PatG §123)
+  is absent on the proceeding-tree side. `weiterbehandlung` and
+  `wiedereinsetzung` concept slugs exist in the cascade (Pathway B)
+  but no `paliad.deadline_rules` row computes them. Same for
+  `versaeumnisurteil-einspruch` (ZPO §339 — 2 weeks).
+
+- **15 ambiguities** that need m's judgement, not a coder's fix —
+  mostly around court-set vs statutory periods (e.g. richterliche
+  Fristen under ZPO §276(1) S.2, §283 Schriftsatznachreichung,
+  EPC R.79(1), §59(3) PatG) and around the "whichever is
+  longer / later" arithmetic primitives still missing
+  (R.198 / R.213 / R.245.2).
+
+- **Recommended fixes (§10) — total 41 items** prioritised in 4
+  tiers. Tier 0 (5 hard duration bugs + 1 sequencing bug + 9
+  citation/anchor bugs) should ship first. Tier 1 (12 rule-fill
+  gaps, ★★★ / ★★) next. Tier 2 + 3 are coverage breadth that
+  needs scoping by m (Wiedereinsetzung, R.198 working-day
+  arithmetic, full Implementing Regulations port).
+
+---
+
+## §1. Methodology
+
+For each of the 20 active proceeding_types I:
+
+1. **Pulled the live rule set** via `mcp__supabase__execute_sql` against
+   the youpc Postgres on 2026-05-25 14:00–15:00 UTC. Schema = `paliad`.
+   Filter: `is_active = true AND lifecycle_state = 'published'`.
+2. **Enumerated the statutory deadlines** in the relevant code for the
+   proceeding's scope.
+3. **Cross-referenced each statutory deadline against the live rule
+   set** on (a) duration + unit, (b) anchor / parent, (c) party,
+   (d) `rule_code` / `legal_source` citation, (e) sequencing.
+4. **Marked status**: `present-correct`, `present-wrong (duration)`,
+   `present-wrong (citation)`, `present-wrong (anchor)`,
+   `present-wrong (party)`, `partial`, `missing`, `n/a`.
+5. **Frequency tag** for prioritisation: ★★★ every case, ★★ common,
+   ★ specialist.
+
+### 1.1 Sources
+
+All citations carry a date stamp and a URL. Where the text was checked
+against more than one source, both are listed.
+
+| Source | URL | Verified on | Used for |
+|---|---|---|---|
+| UPC Rules of Procedure (consolidated 18.05.2023, in force 2023-06-01) | https://www.unifiedpatentcourt.org/sites/default/files/upc_documents/rop_application_-_consolidated_18_05_2023.pdf | 2026-05-25 | All UPC RoP citations |
+| UPC RoP verbatim text via `data.laws_contents` (youpc Postgres, law_type=`UPCRoP`, language=en) | youpc Supabase | 2026-05-25 | Cross-check on R.019.1, R.020.2, R.029.b/.c, R.049.1, R.051, R.051.p1, R.052, R.052.p1, R.220.1.a, R.224.1, R.224.1.a/.b, R.224.2, R.224.2.a/.b, R.235.1, R.235.2, R.237, R.238.1, R.238.2 |
+| European Patent Convention (EPC, 17th ed. 2020) — Articles | https://www.epo.org/en/legal/epc/2020/index.html (verbatim text per youpc `data.laws_contents`, law_type=`EPC`) | 2026-05-25 | EPC Articles 93, 99, 108, 112a, 116, 121, 123, 135 |
+| EPC Implementing Regulations — Rules (in force 2026 consolidated) | https://www.epo.org/en/legal/epc/2020/r71.html (and equivalents) | 2026-05-25 | EPC R.70(1), R.71(3), R.79(1)/(2), R.116(1), R.135 |
+| Patentgesetz (PatG) — gesetze-im-internet.de | https://www.gesetze-im-internet.de/patg/ | 2026-05-25 | §59, §73, §75, §82, §83, §99 ff., §100, §102, §110, §111 |
+| Zivilprozessordnung (ZPO) — gesetze-im-internet.de | https://www.gesetze-im-internet.de/zpo/ | 2026-05-25 | §253, §276, §277, §283, §296a, §339, §517, §520, §521, §524, §544, §548, §551, §554 |
+| Gebrauchsmustergesetz (GebrMG) — gesetze-im-internet.de | https://www.gesetze-im-internet.de/gebrmg/ | 2026-05-25 | §17 (Löschung), §18 (Verfahren) — referenced only to confirm out-of-scope: no GebrMG-rooted proceeding_type exists in paliad today |
+
+### 1.2 Conventions
+
+- A **rule** here means a row in `paliad.deadline_rules`. paliad's local
+  identifier is `submission_code` (post mig 098), e.g.
+  `upc.rev.cfi.defence`.
+- A **statutory deadline** means an obligation derived directly from the
+  text of a procedural code, with a fixed period.
+- "**Court-set**" / "richterliche Frist" means the statute authorises the
+  court / DPMA / EPO to set the period — there is no fixed statutory
+  duration. paliad models these with `is_court_set = true`
+  (post mig ~079) or, legacy-style, `duration_value = 0`.
+- "**Anchoring**" refers to which event the period runs from. paliad
+  models this via `parent_id` (chain anchor) or `anchor_alt` (e.g.
+  `priority_date`); a NULL parent_id with non-zero duration means the
+  deadline runs from the user-supplied trigger date.
+
+### 1.3 Hard constraint: "no fabricated provisions"
+
+Where I'm not 100% sure of a citation (because the youpc law DB only
+covers UPC + EPC, not PatG / ZPO, and my web-fetch coverage of
+PatG / ZPO is partial), I flag the finding as **"needs lawyer review"**
+in §9 rather than asserting a fix. Five PatG / ZPO findings carry that
+tag.
+
+---
+
+## §2. Current state inventory (per jurisdiction)
+
+### 2.1 UPC
+
+9 active types, 67 rules. `upc.ccr.cfi` is an alias proceeding that
+holds zero rules — it points at `upc.inf.cfi` rules under the
+`with_ccr` flag.
+
+| Code | Name | Rule count | Audited against |
+|---|---|---:|---|
+| `upc.inf.cfi` | Verletzungsverfahren | 15 | RoP 19, 23, 25, 29.a-e, 30, 32, 151, 220.1(a) |
+| `upc.rev.cfi` | Nichtigkeitsverfahren | 17 | RoP 19, 32, 42, 43.3, 49.1, 49.2.a, 49.2.b, 51, 52, 56.1/3/4, 220.1(a) |
+| `upc.pi.cfi` | Einstweilige Maßnahmen | 4 | RoP 205, 207, 211 |
+| `upc.disc.cfi` | Bucheinsicht | 4 | RoP 141, 142.2, 142.3 |
+| `upc.dmgs.cfi` | Schadensbemessung | 4 | RoP 131.2, 137.2, 139 |
+| `upc.apl.merits` | Berufung | 8 | RoP 220.1, 224.1.a, 224.2.a, 235.1, 237, 238.1 |
+| `upc.apl.order` | Berufung gegen Anordnungen | 5 | RoP 220.1(c), 220.2, 220.3, 237, 238.2 |
+| `upc.apl.cost` | Berufung gegen Kostenentscheidung | 2 | RoP 221.1 |
+| `upc.ccr.cfi` | Widerklage auf Nichtigkeit (alias) | 0 | — |
+
+### 2.2 EPA
+
+3 active types, 23 rules.
+
+| Code | Name | Rule count | Audited against |
+|---|---|---:|---|
+| `epa.grant.exa` | EP-Erteilung | 7 | EPC Art. 93, R.70(1), R.71(3) |
+| `epa.opp.opd` | EPA Einspruch | 8 | EPC Art. 99(1), 108, 116, 123; R.79(1), R.79(2), R.116(1) |
+| `epa.opp.boa` | EPA Beschwerde | 8 | EPC Art. 108, 112a; R.116(1); RPBA Art. 12 |
+
+### 2.3 DPMA
+
+3 active types, 13 rules.
+
+| Code | Name | Rule count | Audited against |
+|---|---|---:|---|
+| `dpma.opp.dpma` | DPMA Einspruch | 4 | PatG §59(1), §59(3) |
+| `dpma.appeal.bpatg` | BPatG-Beschwerde | 5 | PatG §73(2), §74 ff. |
+| `dpma.appeal.bgh` | BGH-Rechtsbeschwerde | 4 | PatG §100, §102 |
+
+### 2.4 DE (national patent / civil)
+
+5 active types, 29 rules.
+
+| Code | Name | Rule count | Audited against |
+|---|---|---:|---|
+| `de.inf.lg` | LG-Verletzungsklage | 8 | ZPO §253, §276, §283, §296a, §517, §520(2) |
+| `de.inf.olg` | OLG-Berufung Verletzung | 7 | ZPO §517, §520(2), §521(2), §524(2) |
+| `de.inf.bgh` | BGH-Revision Verletzung | 8 | ZPO §544, §548, §551, §554 |
+| `de.null.bpatg` | BPatG-Nichtigkeitsklage | 10 | PatG §81 ff., §82, §83 |
+| `de.null.bgh` | BGH-Nichtigkeitsberufung | 6 | PatG §110, §111 / ZPO ref via §117 PatG |
+
+### 2.5 Cross-cutting: cascade vs proceeding-tree coverage
+
+The cascade layer (`paliad.event_categories` + `…_concepts` +
+`paliad.deadline_concepts`) carries 56 concept "nouns" and ~153
+cascade-leaf → concept mappings. **9 concepts are orphans** (carry
+zero rules, so the cascade card dead-ends): `counterclaim-for-revocation`,
+`schriftsatznachreichung`, `versaeumnisurteil-einspruch`,
+`weiterbehandlung`, `wiedereinsetzung`, `notice-of-defence-intention`,
+plus 3 more. Inventory and recommendations live in
+`docs/audit-fristen-logic-2026-05-13.md` §3.4 — this audit covers only
+the proceeding-tree side.
+
+---
+
+## §3. Findings — Missing rules (statute defines, paliad doesn't)
+
+### 3.1 UPC RoP — 21 missing rules (out of ~25 flagged 2026-05-08, 4 closed by mig 095)
+
+Notation: ★★★ every case, ★★ common, ★ specialist. Verbatim RoP text
+sampled from youpc `data.laws_contents` (law_type=`UPCRoP`, lang=en).
+
+| RoP § | Period | Trigger | Freq | Notes |
+|---|---|---|---|---|
+| **R.20.2** | 14 days | Service of Preliminary Objection | ★ | Reply to PO. Companion to R.19 (which mig 095 added). Without R.20.2 the PO branch is half-modelled. |
+| **R.118.4** | 2 months | Final decision on validity served | ★★ | Application for orders consequential on validity. Common after central-division revocation. |
+| **R.118.5** | n/a UPC | n/a | n/a | UPC has no Versäumnisurteil-Einspruch; closest is R.355 (review of contumacy). |
+| **R.144** | 0 (anchor) | Final decision on damages quantum | ★ | UPC_DAMAGES tree end-row missing. |
+| **R.155** | 1mo / 14d | Cost-decision opposition chain | ★ | UPC_COST_APPEAL only has the leave-to-appeal step; no Defence-to-cost-app row. |
+| **R.197.3** | 30 days | Saisie order served on respondent | ★ | Review application. Trigger event 65 exists; no rule attached. |
+| **R.198** | 31 calendar days **OR 20 working days, whichever is longer** | Saisie executed | ★ | Start proceedings on the merits. Blocked on `working_days` + `combine='max'` primitives (see §7 + §9). |
+| **R.207.6.a** | 14 days | Notification of deficiency in PI application | ★★ | Registry correction. |
+| **R.207.9** | 6 months | PI filed | ★ | Renewal of protective letter. |
+| **R.213** | 31 days OR 20 working days | PI granted | ★★ | Same arithmetic gap as R.198. |
+| **R.109.1** | 1 month **before** | Oral hearing date | ★★ | Simultaneous translation request. `timing='before'` schema supported but no rule populates it (see §7 cross-cutting). |
+| **R.109.4** | 2 weeks **before** | Oral hearing date | ★★ | Interpreter cost notification. `timing='before'`. |
+| **R.109.5** | 2 weeks after | Order of judge-rapporteur to lodge translations | ★★ | trigger event 113 exists; no rule. |
+| **R.224.2.b** | 15 days | Order under R.220.1(c) or decision under R.220.2/221.3 served | ★★ | Grounds-on-orders track. `upc.apl.order` has appeal-itself but no separate grounds row. Verified verbatim against `UPCRoP.224.2.b` (youpc DB). |
+| **R.229.2** | 14 days | Notification of appeal-deficiency | ★ | Registry correction in appeal context. |
+| **R.235.2** | 15 days | Statement of grounds (orders track) served | ★★ | Verified verbatim against `UPCRoP.235.2` (youpc DB): *"Within 15 days of service of grounds of appeal pursuant to Rule 224.2(b), any other party … may lodge a Statement of response"*. `upc.apl.order` has no standalone response row. |
+| **R.245.1** | 2 months | Final decision served | ★ | Application for rehearing. |
+| **R.245.2.a** | 2 months | Discovery of fundamental defect (or final decision service, whichever is later) | ★ | Outer cap 12mo. Needs multi-anchor + `max-of-two-anchors` arithmetic. |
+| **R.245.2.b** | 2 months | Discovery of criminal offence (or final decision service, whichever is later) | ★ | Same shape as 245.2.a. |
+| **R.262.2** | 14 days | Receipt of opposing party's confidentiality application | ★★ | Daily occurrence in HLC infringement work. Trigger event 25 exists; no rule. |
+| **R.320** | 2 months (cap 12 mo) | Wegfall des Hindernisses (Wiedereinsetzung) | ★★ | Cascade card exists (mig 063) but no proceeding-tree rule computes the deadline. Bridges proceedings → no obvious home in any one tree. |
+| **R.321.3** | 10 days | Preliminary objection referral to central division | ★ | |
+| **R.333.2** | 15 days | Case-management order served | ★★ | Review-of-CMO. Routine in busy LDs. |
+| **R.353** | 1 month | Decision / order delivered | ★ | Rectification application. |
+| **DNI: R.63 / R.67.1 / R.69.1 / R.69.2** | 0 / 2mo / 1mo / 1mo | DNI cascade | ★ | No UPC_DNI proceeding_type exists. Fringe at HLC (zero published filings in 2026-Q1 per May 8 audit). |
+| **Registry-correction family: R.16.3.a, R.27.2, R.89.2, R.253.2** | 14 days each | Various deficiency notifications | ★ | All same 14-day duration; different trigger codes. Most natural home is cascade not proceeding-tree (see audit-fristenrechner-completeness-2026-04-30.md §3.1). |
+
+**Closed since May 8 audit (verified by SQL):**
+- ✅ R.19 Preliminary Objection on UPC_INF — `upc.inf.cfi.prelim`, 1mo, RoP.019.1, flag-gated `with_po` — mig 095.
+- ✅ R.19 Preliminary Objection on UPC_REV — `upc.rev.cfi.prelim`, 1mo, RoP.019.1, flag-gated `with_po` — mig 095 (cites R.19 i.V.m. R.46).
+- ✅ R.220.1(a) merits-appeal spawn on UPC_INF — `upc.inf.cfi.appeal_spawn`, 2mo, is_spawn=true → upc.apl.merits — mig 095.
+- ✅ R.220.1(a) merits-appeal spawn on UPC_REV — `upc.rev.cfi.appeal_spawn`, 2mo, is_spawn=true → upc.apl.merits — mig 095.
+
+### 3.2 EPC Implementing Regulations — 4 missing rules
+
+| EPC ref | Period | Trigger | Freq | Notes |
+|---|---|---|---|---|
+| **EPC R.135 (Weiterbehandlung)** | 2 months | Notification of loss of rights | ★★ | Concept `weiterbehandlung` exists in cascade (orphan); no rule. Applies broadly across `epa.grant.exa` and `epa.opp.opd`. |
+| **EPC R.99(2) / Art. 121** | 2 months | Loss-of-rights notification (further processing) | ★★ | Same family as R.135. |
+| **EPC Art. 112a(4)** | 2 months / 1 month | Discovery of grounds for review / decision served (whichever later) | ★ | paliad has `epa.opp.boa.r106` (2 months, parent=entsch2) — but the rule doesn't model the "whichever later" outer cap (12 months from decision per Art. 112a(4)). |
+| **EPC Art. 99(1) — opposition fee paid** | 9 months (no extension) | Mention of grant in Patentblatt | ★★★ | `epa.opp.opd.frist` IS modelled correctly at 9 months. **Note however:** the rule is on `epa.opp.opd` but the *trigger* is opposition-fee-paid (per Art. 99(1) S.2 — "Notice of opposition shall not be deemed to have been filed until the opposition fee has been paid"). Not a gap, but a documentation note. |
+
+### 3.3 PatG / ZPO — 5 missing rules
+
+| Citation | Period | Trigger | Freq | Notes |
+|---|---|---|---|---|
+| **PatG §123 (Wiedereinsetzung)** | 2 months | Wegfall des Hindernisses (cap 1 year) | ★★ | Cascade concept `wiedereinsetzung` exists; no rule on any DE/DPMA proceeding tree. Same modelling problem as UPC R.320 — bridges proceedings. |
+| **ZPO §339 (Versäumnisurteil-Einspruch)** | 2 weeks | Service of default judgment | ★ | Cascade concept `versaeumnisurteil-einspruch` orphan. |
+| **ZPO §544 — Nichtzulassungsbeschwerde-Begründung** | 2 months | Service of OLG-Urteil (NB: NOT from filing of NZB) | ★★ | `de.inf.bgh.nzb_begr` lists `DE.ZPO.544.4`, duration 2mo, parent=urteil_olg — **modelled correctly**. Listed here only to flag that the *parent anchoring* differs from `de.inf.lg.beruf_begr` which is wrong (see §7.1). |
+| **ZPO §283 (Schriftsatznachreichung) / §296a** | court-set | post-Verhandlung schriftsatzfrist | ★ | Cascade concept `schriftsatznachreichung` orphan. Court-set period — modelling as `is_court_set=true, duration=0` would suffice. |
+| **PatG §17(2) GebrMG / §18 GebrMG** | 1 month (Beschwerdefrist) | DPMA-Beschluss | ★ | Out of scope per head's confirmation (no GebrMG-rooted proceeding_type yet). Listed to confirm the deliberate gap. |
+
+### 3.4 DPMA — 0 missing rules
+
+DPMA coverage is shallow but not gappy. The 3 active types (opposition,
+BPatG-Beschwerde, BGH-Rechtsbeschwerde) cover the statutory steps. The
+problems here are **citation drift** (§4.4) and **anchor modeling**
+(§7.4) rather than missing rules.
+
+---
+
+## §4. Findings — Misattributed legal source
+
+### 4.1 UPC RoP citation drift (5 still live from May 8)
+
+| Rule | Live `rule_code` | Live `legal_source` | Should be | Source verified |
+|---|---|---|---|---|
+| `upc.apl.merits.notice` | `RoP.220.1` | `UPC.RoP.220.1` | `RoP.224.1.a` / `UPC.RoP.224.1.a` | `UPCRoP.224.1.a` youpc DB |
+| `upc.apl.merits.grounds` | `RoP.220.1` | `UPC.RoP.220.1` | `RoP.224.2.a` / `UPC.RoP.224.2.a` | `UPCRoP.224.2.a` |
+| `upc.apl.merits.response` | `null` | `null` | `RoP.235.1` / `UPC.RoP.235.1` | `UPCRoP.235.1` |
+| `upc.rev.cfi.reply` | `null` | `null` | `RoP.051` / `UPC.RoP.51.p1` | `UPCRoP.051.p1` |
+| `upc.rev.cfi.rejoin` | `null` | `null` | `RoP.052` / `UPC.RoP.52.p1` | `UPCRoP.052.p1` |
+
+Note on cascade vs proceeding-tree drift on R.220.3 anchoring is in
+`docs/audit-upc-rop-deadlines-2026-05-08.md` §5.4b — unchanged here.
+
+### 4.2 UPC RoP citation drift on Rule 49.1 format (1 still live)
+
+| Rule | Live `rule_code` | Should be |
+|---|---|---|
+| `upc.rev.cfi.defence` | `RoP.49.1` | `RoP.049.1` (canonical zero-padded form used by all other UPC rules) |
+
+### 4.3 DPMA — 3 mis-attributed citations
+
+| Rule | Live citation | Problem | Verified |
+|---|---|---|---|
+| `dpma.opp.dpma.erwiderung` | `§ 59 PatG` / `DE.PatG.59.3` | §59(3) PatG addresses *Anhörung*, not a 4-month response period. No statutory Erwiderungsfrist exists in §59. The 4-month figure is DPMA-internal practice. | WebFetch [gesetze-im-internet.de/patg/__59.html](https://www.gesetze-im-internet.de/patg/__59.html) 2026-05-25 |
+| `dpma.appeal.bpatg.begruendung` | `§ 75 PatG` / `DE.PatG.75.1` | §75 PatG is exclusively about *aufschiebende Wirkung* (suspensive effect). It does not establish any Begründungsfrist. No fixed Begründungsfrist for BPatG-Beschwerde exists in PatG §§73-80 — it is set by the BPatG in the individual case. | WebFetch [gesetze-im-internet.de/patg/__75.html](https://www.gesetze-im-internet.de/patg/__75.html) + [§73](https://www.gesetze-im-internet.de/patg/__73.html) 2026-05-25 |
+| `dpma.appeal.bpatg.beschwerde` | `§ 73 PatG` / `DE.PatG.73.2` | §73 contains the 1-month deadline correctly; the `.2` subscript however refers to §73(2) which is about Beschwerdebefugnis — the *Frist* is in §73(2) S.4 ("Die Beschwerdefrist beträgt einen Monat …"). Citation should be `DE.PatG.73.2.s4` or simply `DE.PatG.73.2`. **Borderline — flag, not a hard bug.** | gesetze-im-internet.de |
+
+### 4.4 DE patent / civil — 4 mis-attributed citations
+
+| Rule | Live citation | Problem | Verified |
+|---|---|---|---|
+| `de.null.bpatg.erwidg` | `§ 82 PatG` / `DE.PatG.82.1` | §82(1) is the 1-month *Erklärungsfrist* ("sich darüber zu erklären"); the 2-month full *Klageerwiderung* is in §82(3). Citation should be `DE.PatG.82.3`. Duration (2 months) is correct. | WebFetch [§82](https://www.gesetze-im-internet.de/patg/__82.html) 2026-05-25 |
+| `de.null.bpatg.replik_klaeger` | `§ 83 PatG` / `DE.PatG.83.2` | §83(2) is about the *Hinweisbeschluss* form; the Replik / Schriftsatz windows fall under §83(2) S.3 (Reaktion auf Hinweis). Citation OK at section level but ambiguous. **Borderline — flag, not a hard bug.** | gesetze-im-internet.de |
+| `de.null.bgh.begruendung` | `§ 111 PatG` / `DE.PatG.111.1` | §111 PatG defines the *Grounds* of Berufung (Verletzung des Bundesrechts), not a Begründungsfrist. The 3-month figure is supplied via §117 PatG → ZPO §520(2). Citation should be `DE.ZPO.520.2` (the actual time-limit source). | WebFetch [§111](https://www.gesetze-im-internet.de/patg/__111.html) 2026-05-25 |
+| `de.null.bgh.erwiderung` | `§ 111 PatG` / `DE.PatG.111.3` | §111 has no Erwiderungsfrist clause. The actual Erwiderungsfrist for BGH-Nichtigkeitsberufung is set by the court per §117 PatG → ZPO §521(2) (court-discretionary). Duration (2 months) is approximate — typical court-set period is 2 months but it's not fixed. **Should be modelled as court-set.** | WebFetch [§111](https://www.gesetze-im-internet.de/patg/__111.html) + ZPO §521 2026-05-25 |
+
+### 4.5 EPA — 1 mis-attributed citation
+
+| Rule | Live citation | Problem |
+|---|---|---|
+| `epa.opp.opd.erwidg` | `R. 79(1) EPÜ` / `EU.EPC-R.79.1` | Duration (4 months) is correct as the *typical* EPO-set period under the 2016 streamlined-opposition guidelines, but **R.79(1) does not specify a fixed period** — the Opposition Division sets it. The 4 months is administrative practice (EPO Guidelines D-IV, 5.2). Should be modelled as court-set with 4 months as the default-display value. |
+
+---
+
+## §5. Findings — Wrong period (statute says X, paliad says Y)
+
+| Rule | Live period | Statutory period | Source | Freq |
+|---|---|---|---|---|
+| **`upc.rev.cfi.defence`** | 3 months | **2 months** | RoP.049.1: *"The defendant shall lodge a Defence to revocation within two months of service of the Statement for revocation."* — verified verbatim from `UPCRoP.049.1` (youpc DB). Flagged 2026-05-08; still live. | ★★★ |
+| **`upc.rev.cfi.rejoin`** | 2 months | **1 month** | RoP.052: *"Within one month of the service of the Reply the defendant may lodge a Rejoinder to the Reply to the Defence to revocation"* — verified verbatim from `UPCRoP.052.p1`. Flagged 2026-05-08; still live. | ★★★ |
+| **`upc.apl.merits.response`** | 2 months | **3 months** | RoP.235.1: *"Within three months of service of the Statement of grounds of appeal pursuant to Rule 224.2(a), any other party … may lodge a Statement of response"* — verified verbatim from `UPCRoP.235.1`. New finding — May 8 audit recorded the duration as 3 months but the live row has always been 2 (migration 012:153 originally seeded 2). | ★★★ |
+| **`upc.pi.cfi.response`** | 0 / "court-set" (`is_court_set=false`, `duration=0`, `parent_id=NULL`) | court-set, judge-discretion under R.211.2 | RoP.211.2 — judge sets the inter-partes hearing date. Modelling is half-broken: `duration=0` with `parent_id=NULL` makes the calculator treat this as a root anchor rather than a court-set placeholder. Should set `is_court_set=true` and chain `parent_id=app`. | ★★ |
+
+(All other rules audited have correct durations.)
+
+---
+
+## §6. Findings — Wrong party
+
+No clear party mis-assignments found in the live data. Two notes worth
+recording, not bugs:
+
+- `upc.inf.cfi.app_to_amend` carries `primary_party='claimant'`. The
+  defendant in an INF case is the alleged infringer; the patent
+  proprietor (=claimant) is who would file an Application to Amend
+  the patent. **Correct.** Listed here only because R.30 reads "the
+  defendant" in some summaries — those refer to the claimant of the
+  CCR (= defendant of the INF), which loops back to the same person
+  who is the INF-claimant / patent-proprietor.
+- `dpma.opp.dpma.erwiderung` carries `primary_party='defendant'`. In an
+  EPA-style opposition, the patent proprietor is the "defendant" of the
+  opposition. Consistent with EPA convention. **Correct.**
+
+---
+
+## §7. Findings — Wrong sequencing / anchoring
+
+### 7.1 `de.inf.lg.beruf_begr` chains parent = `berufung`, should anchor on `urteil` directly
+
+| Live | Per ZPO §520(2) |
+|---|---|
+| `de.inf.lg.beruf_begr.parent_id = de.inf.lg.berufung`, `duration = 2 months` → effective end = trigger + 1mo (Berufung) + 2mo = **3 months** after Urteil service | "Die Frist für die Berufungsbegründung beträgt zwei Monate. Sie beginnt mit der Zustellung des in vollständiger Form abgefassten Urteils" → **2 months** after Urteil service |
+
+Verified verbatim via WebFetch
+[gesetze-im-internet.de/zpo/__520.html](https://www.gesetze-im-internet.de/zpo/__520.html)
+2026-05-25.
+
+The companion `de.inf.olg.begruendung` is **correct** — parent =
+`urteil_lg`, 2mo, so end = Urteil + 2mo. Same statute, two paliad
+rules, two different anchorings: this is a real bug in `de.inf.lg`.
+
+### 7.2 `de.inf.lg.replik` and `de.inf.lg.duplik` have `parent_id = NULL`
+
+This is the bug head flagged. Live data:
+
+| submission_code | name | duration | parent_id | sequence_order |
+|---|---|---|---|---|
+| `de.inf.lg.klage` | Klageerhebung | 0 mo | NULL | 0 |
+| `de.inf.lg.anzeige` | Anzeige Verteidigungsbereitschaft | 2 wk | `de.inf.lg.klage` | 10 |
+| `de.inf.lg.erwidg` | Klageerwiderung | 6 wk | `de.inf.lg.klage` (court-set=true post mig 095) | 20 |
+| **`de.inf.lg.replik`** | Replik | **4 wk** | **NULL** | 30 |
+| **`de.inf.lg.duplik`** | Duplik | **4 wk** | **NULL** | 40 |
+| `de.inf.lg.termin` | Haupttermin | 0 mo | NULL (court-set) | 50 |
+| `de.inf.lg.urteil` | Urteil | 0 mo | NULL (court-set) | 60 |
+| `de.inf.lg.berufung` | Berufungsfrist | 1 mo | NULL | 70 |
+| `de.inf.lg.beruf_begr` | Berufungsbegründung | 2 mo | `de.inf.lg.berufung` | 80 |
+
+With `parent_id = NULL` the calculator anchors Replik on the
+triggerDate (= Klageerhebung), and same for Duplik. So both render
+"4 Wochen ab Klageerhebung" — i.e. before the Klageerwiderung is
+even due. Correct chain should be:
+
+- `replik.parent_id = de.inf.lg.erwidg`, with `is_court_set = true` (richterliche Frist § 276(1) S.2 / § 283 ZPO — typ. 4 weeks default)
+- `duplik.parent_id = de.inf.lg.replik`, same shape
+
+Both rules lack `legal_source` and `rule_code`, which is consistent
+with them being court-set Schriftsatzfristen (no statutory clamp).
+Recommendation in §10.
+
+### 7.3 `upc.apl.merits.grounds` has `parent_id = NULL`
+
+This anchors Grounds on the user-supplied trigger date (=Entscheidung
+service). **Correct** behaviour per RoP.224.2.a: *"within four months
+of service of a decision referred to in Rule 220.1(a) and (b)"*.
+
+If `parent_id` were set to `upc.apl.merits.notice` (as the May 8 audit
+hypothesised), the chain would compound (1-day notice + 4mo grounds =
+~4mo + 1 day), accidentally landing near the right end-date for the
+common case but wrong by up to 2 months in the edge case (when notice
+is filed early). **No fix needed; document the intent.** (This is
+the change the May 8 audit recommended; it was applied in mig 097 or
+earlier.)
+
+### 7.4 DPMA Pathway-A anchors are partially modelled
+
+- `dpma.appeal.bgh.begruendung` chains parent = `rechtsbeschwerde`
+  (1mo + 1mo = 2mo from BPatG-Entscheidung). Per PatG §102 the
+  Rechtsbeschwerdebegründungsfrist is 1 month from filing of the
+  Rechtsbeschwerde — **correct**.
+- `dpma.appeal.bpatg.begruendung` chains parent = `beschwerde`
+  (1mo + 1mo = 2mo from DPMA-Entscheidung). **No statutory basis for
+  the 1-month figure** (see §4.3). Should be court-set.
+
+### 7.5 EPA grant timeline — `epa.grant.exa.r71_3` and `.approval` have `parent_id = NULL`
+
+Live:
+
+| Rule | Duration | parent_id | Issue |
+|---|---|---|---|
+| `epa.grant.exa.r71_3` | 0 mo | NULL | Should chain on `exam_req` (after examination request is granted, EPO issues R.71(3) communication). NULL parent + 0 duration = root anchor at trigger date — works only if user enters the R.71(3) date as trigger; doesn't compose with the rest of the tree. |
+| `epa.grant.exa.approval` | 4 mo | NULL | Per R.71(3) approval period: 4 months from notification. **Anchor should be `r71_3`**, not NULL. As-is, "Zustimmung + Übersetzung" appears as a free-standing 4-mo-from-trigger row that has nothing to do with the rest of the timeline. |
+
+### 7.6 Summary
+
+| # | Rule | Bug |
+|---|---|---|
+| 1 | `de.inf.lg.beruf_begr` | parent should be NULL (anchored on Urteil-trigger) not `berufung` — off by 1 month, ★★★ |
+| 2 | `de.inf.lg.replik` | parent should be `erwidg` not NULL, ★★★ |
+| 3 | `de.inf.lg.duplik` | parent should be `replik` not NULL, ★★★ |
+| 4 | `dpma.appeal.bpatg.begruendung` | should be court-set; current 1-month period has no statutory basis, ★★ |
+| 5 | `dpma.appeal.bpatg.beschwerde` parent is `entscheidung` — OK, just a citation issue (§4.3) | (citation only) |
+| 6 | `epa.grant.exa.r71_3` parent | should chain on `exam_req`, ★ |
+| 7 | `epa.grant.exa.approval` parent | should chain on `r71_3`, ★ |
+| 8 | `upc.pi.cfi.response` | court-set placeholder with `parent_id=NULL` and `is_court_set=false` — should chain on `app` with `is_court_set=true`, ★★ |
+
+---
+
+## §8. Findings — Duplicates
+
+No genuine duplicates. The closest cases:
+
+- `upc.inf.cfi.reply` + `upc.inf.cfi.def_to_ccr` both fire at 2mo after
+  `sod` under `with_ccr`. They cover different actions (Reply to SoD
+  vs. Defence to CCR + Reply to SoD combined) per RoP.029.a vs .b.
+  **Not a duplicate** — distinct rule codes.
+- `upc.rev.cfi.reply` (2mo, no rule_code) and the older `REV.rev_reply`
+  on the archived litigation type — the archived type is hidden
+  (`pt.is_active = false`) so this isn't a duplicate the user sees.
+  Recommendation in §10 to drop the archived corpus once mig 093's
+  audit window closes.
+- `epa.opp.boa.r106` (Art. 112a review) appears only on
+  `epa.opp.boa`, not on `epa.opp.opd` — correct, since Art. 112a
+  review is only available against a Boards-of-Appeal decision.
+
+---
+
+## §9. Ambiguities — decisions m needs to make
+
+These are not bugs the coder can fix. They are judgement calls about
+how to model the law.
+
+### 9.1 Court-set vs fixed-period for richterliche Fristen
+
+The cleanest source-of-truth for these is "no statutory duration —
+court sets the period in the individual case." Modelling them as a
+fixed period with a wrong citation is the bug pattern we keep finding:
+
+- `dpma.opp.dpma.erwiderung` (4 mo) — DPMA practice, not §59 PatG.
+- `dpma.appeal.bpatg.begruendung` (1 mo) — no statutory basis.
+- `de.inf.olg.erwiderung` (1 mo, §521(2)) — §521(2) is explicitly
+  discretionary ("Der Vorsitzende oder das Berufungsgericht **kann**
+  der Gegenpartei eine Frist … bestimmen"). Verified WebFetch
+  [gesetze-im-internet.de/zpo/__521.html](https://www.gesetze-im-internet.de/zpo/__521.html)
+  2026-05-25.
+- `de.null.bgh.erwiderung` (2 mo, "§111(3) PatG") — court-set per §117
+  PatG → ZPO §521(2).
+- `de.null.bpatg.duplik` (1 mo, §83 PatG) — court-set; the 1-month
+  default is BPatG practice.
+- `de.inf.lg.replik`, `.duplik` (4 wk each) — court-set per
+  §283 / §296a ZPO + §276(1) S.2.
+- `epa.opp.opd.erwidg` (4 mo, "R.79(1)") — EPO-set per Guidelines.
+
+**Question (Q1):** Should paliad continue to display these with a
+default duration but flag them as "richterliche Frist — vom Gericht
+festgesetzt", OR should they all flip to `is_court_set=true,
+duration=0` and force the user to enter the actual court-set date?
+
+Head's 2026-05-25 13:13 signal confirms: m's preference is that "Frist
+vom Gericht bestimmt" be flagged as needing case-by-case anchoring,
+not displayed as a fixed period. So default answer = flip to
+`is_court_set=true` and keep the typical period as the *Default*
+display value (the calculator already supports this since the
+mig 095 / `de.inf.lg.erwidg` patch). But the trade-off is a UX
+regression: most users will not enter the actual court-set date
+and the timeline will then show "vom Gericht bestimmt" everywhere.
+
+### 9.2 R.198 / R.213 "31 days OR 20 working days, whichever is longer"
+
+Two RoP rules need a primitive paliad doesn't have:
+- A `working_days` duration unit (counts business-day arithmetic via
+  the holiday service).
+- A `combine = 'max'` operator that compares two durations and picks
+  the later end-date.
+
+**Question (Q2):** Implement the primitive (~120 LoC migration + ~80 LoC
+Go), or document both rules as "manual calculation required, see RoP"
+in the UI? Real R.198 / R.213 cases are rare (saisie + PI). The May 8
+audit suggested deferring; pauli's 2026-05-13 audit §7.1 made the
+case for adding `combine_op` as part of a broader Pipeline A/C merge.
+
+### 9.3 R.245.2 rehearing "whichever is later" trigger
+
+R.245.2.a/b: deadline 2 months from final decision OR from defect
+discovery, whichever is *later*. Plus outer cap 12 months. Needs:
+
+- Multi-anchor trigger event (user supplies 2 dates).
+- `combine = 'max'` between anchors.
+- Outer-cap arithmetic (separate concept from duration).
+
+**Question (Q3):** Defer (specialist, vanishingly rare) or build the
+primitives?
+
+### 9.4 EPC Art. 112a review — outer cap
+
+Same shape as R.245.2: 2 months from defect discovery, outer cap 12
+months from decision. `epa.opp.boa.r106` models the 2-month period
+but not the cap.
+
+### 9.5 PatG §123 Wiedereinsetzung calendar arithmetic
+
+Cascade card (slug `wiedereinsetzung`) exists. The 2mo / 1-year
+arithmetic anchors on the *missed* deadline, not on a forward-looking
+event. paliad's `paliad.deadline_rules` schema has no natural shape
+for this — it would need either a special-case Go helper, or a
+"backward-from-missed-deadline" mode that no rule today uses.
+
+**Question (Q4):** Worth modelling? The cascade card already routes
+the user to the concept; computing the calendar deadline is an
+incremental win.
+
+### 9.6 ZPO §339 Versäumnisurteil-Einspruch
+
+Cascade card orphan. 2 weeks from service of the default judgment.
+Trivial to add as a `de.inf.lg.einspruch_vu` rule (court-decision
+anchor + 2wk fixed). **Question (Q5):** Add as a child of
+`de.inf.lg.urteil` (with `condition_expr={"flag":"with_vu"}`), or
+as a separate proceeding `de.inf.lg.vu`?
+
+### 9.7 Litigation-vs-fristenrechner archived corpus
+
+The 40 rules on `_archived_litigation` (mig 093 retirement holding pen)
+still occupy the rule table. They're invisible to all UIs.
+
+**Question (Q6):** Drop them now (data clean-up), or keep until the
+mig 093 audit window closes formally?
+
+### 9.8 R.79(2) further-party observations period
+
+EPC R.79(2) creates a separate notification window for additional
+opponents. paliad's `epa.opp.opd.r79_further` is modelled as
+`duration=0, is_bilateral=true`. **Question (Q7):** Is this even worth
+keeping? Real workflow: EPO sets a separate period in each
+intervention case. Hard to template.
+
+### 9.9 R.116(1) EPC oral-proceedings cut-off
+
+paliad has it as `duration=0, parent_id=entsch` (`epa.opp.opd.r116`) /
+`parent_id=oral` (`epa.opp.boa.r116`). R.116(1) actually says the
+EPO sets a "final date for making written submissions" when issuing
+the summons. So it's a court-set period, not zero-duration.
+**Question (Q8):** flip to `is_court_set=true` like the §276(1) ZPO
+fix in mig 095?
+
+### 9.10 R.131.2 indication of damages period
+
+paliad models `upc.dmgs.cfi.app` as a 0-duration root anchor (court
+sets when the damages-determination phase opens, per R.131.2). This
+is correct shape but means the entire damages tree is unanchored
+until the user provides the trigger date manually.
+
+**Question (Q9):** Wire `is_spawn` from `upc.inf.cfi.decision` to
+`upc.dmgs.cfi.app` (parallel to the mig-095 appeal-spawn)?
+
+### 9.11 PatG §17 GebrMG / §18 GebrMG
+
+No GebrMG-rooted proceeding_type exists in paliad. Head confirmed
+out-of-scope for this audit. **Question (Q10):** Add a `de.gm.lg`
+proceeding for GebrMG-Löschungsverfahren if HLC sees them?
+
+### 9.12 Proceeding-tree vs cascade parity
+
+paliad has 9 cascade-only concepts with `rule_count = 0` (the orphans
+listed in `audit-fristen-logic-2026-05-13.md` §3.4). The audit-fristen
+audit covers this; restating here only to note that the parity gap
+is the largest single source of "the cascade card promises a
+calculation but doesn't deliver one."
+
+**Question (Q11):** Same as the audit-fristen Q8 — priority order
+for the 9 orphan concepts? My ranking: wiedereinsetzung >
+schriftsatznachreichung > versäumnisurteil-einspruch >
+weiterbehandlung > rest.
+
+### 9.13 R.220.3 anchor
+
+See `audit-upc-rop-deadlines-2026-05-08.md` §5.4b. paliad anchors
+`upc.apl.order.discretion` on the original order (`order`), but
+the 15-day clock per RoP.220.3 runs from the refusal-of-leave
+date (or day-15 fall-back). Off by up to 15 days in the edge case.
+**Question (Q12):** add an explicit `app_ord.refusal` court-set
+intermediate node?
+
+### 9.14 EP_GRANT publish date — priority vs filing
+
+`epa.grant.exa.publish` correctly has `anchor_alt='priority_date'`.
+This was open in the May 8 audit and is now closed. **No question —
+listed to confirm.**
+
+### 9.15 Cross-proceeding spawn execution
+
+mig 095 added two `is_spawn=true` rules (`inf.appeal_spawn`,
+`rev.appeal_spawn` → `upc.apl.merits`). The May 13 audit §1.6 +
+§6.8 noted spawn execution is half-wired in `projection_service.go`.
+**Question (Q13):** wire end-to-end now (so the spawned appeal
+timeline appears in SmartTimeline), or accept the half-wired state?
+
+---
+
+## §10. Recommended fixes (prioritised)
+
+### Tier 0 — hard duration / sequencing / anchor bugs (ship first)
+
+| # | Rule | Fix | Reason / source | Freq |
+|---|---|---|---|---|
+| T0.1 | `upc.rev.cfi.defence` | `duration_value = 2` (was 3), `rule_code = 'RoP.049.1'`, `legal_source = 'UPC.RoP.49.1'` | §5 — every UPC_REV tracked in paliad today computes Defence at wrong month for the last ~3 months | ★★★ |
+| T0.2 | `upc.rev.cfi.rejoin` | `duration_value = 1` (was 2), `rule_code = 'RoP.052'`, `legal_source = 'UPC.RoP.52.p1'` | §5 — same as T0.1 | ★★★ |
+| T0.3 | `upc.apl.merits.response` | `duration_value = 3` (was 2), `rule_code = 'RoP.235.1'`, `legal_source = 'UPC.RoP.235.1'` | §5 — every main-track appellate respondent | ★★★ |
+| T0.4 | `de.inf.lg.beruf_begr` | `parent_id = NULL` (was `de.inf.lg.berufung`) — runs 2 months from triggerDate (Urteil-service) per ZPO §520(2) | §7.1 — every DE-LG-Verletzung appeal | ★★★ |
+| T0.5 | `de.inf.lg.replik` | `parent_id = de.inf.lg.erwidg`, `is_court_set = true` (richterliche Frist § 276(1) S.2 / § 283 ZPO), keep 4-week default | §7.2 — bug head flagged | ★★★ |
+| T0.6 | `de.inf.lg.duplik` | `parent_id = de.inf.lg.replik`, `is_court_set = true` | §7.2 | ★★★ |
+| T0.7 | `upc.rev.cfi.reply` | `rule_code = 'RoP.051'`, `legal_source = 'UPC.RoP.51.p1'` (duration 2mo unchanged) | §4.1 | ★★★ |
+| T0.8 | `upc.rev.cfi.rejoin` (citation only) | covered in T0.2 | — | — |
+| T0.9 | `upc.apl.merits.notice` | `rule_code = 'RoP.224.1.a'`, `legal_source = 'UPC.RoP.224.1.a'` (duration unchanged) | §4.1 | ★★ |
+| T0.10 | `upc.apl.merits.grounds` | `rule_code = 'RoP.224.2.a'`, `legal_source = 'UPC.RoP.224.2.a'` (duration unchanged) | §4.1 | ★★ |
+| T0.11 | `upc.rev.cfi.defence` rule_code zero-pad | covered in T0.1 | — | — |
+| T0.12 | `dpma.opp.dpma.erwiderung` | flip to `is_court_set = true`, keep 4-month default-display value, drop the misleading `DE.PatG.59.3` citation (or replace with "DPMA-Richtlinien D-IV 5.2") | §4.3 + §9.1 | ★★ |
+| T0.13 | `dpma.appeal.bpatg.begruendung` | flip to `is_court_set = true`, drop the `DE.PatG.75.1` citation, keep 1-month default | §4.3 + §9.1 | ★★ |
+| T0.14 | `de.null.bpatg.erwidg` | citation `DE.PatG.82.3` (was 82.1); duration (2mo) correct | §4.4 | ★★ |
+| T0.15 | `de.null.bgh.begruendung` | citation `DE.ZPO.520.2` via PatG §117 (was DE.PatG.111.1); duration (3mo) correct | §4.4 | ★★ |
+| T0.16 | `de.null.bgh.erwiderung` | flip to `is_court_set = true`; citation `DE.ZPO.521.2 via PatG §117` (was DE.PatG.111.3); duration (2mo) becomes default-display | §4.4 + §9.1 | ★★ |
+| T0.17 | `epa.opp.opd.erwidg` | flip to `is_court_set = true`, keep 4-month default | §4.5 + §9.1 | ★★ |
+
+**16 hard fixes.** All within the existing schema (no new columns).
+Each is a single-row UPDATE plus an audit-log entry.
+
+### Tier 1 — high-value missing rules (★★ / ★★★)
+
+| # | Rule | Add | Freq |
+|---|---|---|---|
+| T1.1 | `upc.inf.cfi.cmo_review` | 15 days from CMO service (R.333.2) | ★★ |
+| T1.2 | `upc.inf.cfi.confidentiality_response` | 14 days from opp. confidentiality app (R.262.2) | ★★ |
+| T1.3 | `upc.apl.order.grounds_orders` | 15 days from order service (R.224.2(b)) | ★★ |
+| T1.4 | `upc.apl.order.response_orders` | 15 days from grounds service (R.235.2) | ★★ |
+| T1.5 | `upc.inf.cfi.cons_orders` | 2 months from validity decision (R.118.4) | ★★ |
+| T1.6 | `upc.inf.cfi.rectification` | 1 month from decision (R.353) | ★ |
+| T1.7 | `upc.pi.cfi.deficiency` | 14 days from PI deficiency notification (R.207.6.a) | ★★ |
+| T1.8 | `upc.pi.cfi.merits_start` | 31d OR 20wd from PI grant (R.213) — **blocked on Q2** | ★★ |
+| T1.9 | `upc.inf.cfi.translation_request` | 1 month **before** oral hearing (R.109.1) | ★★ |
+| T1.10 | `upc.inf.cfi.interpreter_cost` | 2 weeks **before** oral hearing (R.109.4) | ★★ |
+| T1.11 | `upc.inf.cfi.translations_lodge` | 2 weeks after summons (R.109.5) | ★★ |
+| T1.12 | `upc.pi.cfi.response` re-anchor | court-set, parent=`app` (currently a broken root) | ★★ |
+
+**12 rule-adds.** T1.9/.10 are the only `timing='before'` rules in the
+entire UPC corpus; schema already supports `before` but no rule
+populates it. Verify the backward-snap-to-working-day logic in
+`internal/services/deadline_calculator.go` before merging
+(2026-04-30 audit §5.4 raised the concern).
+
+### Tier 2 — broader coverage (★ specialist + Wiedereinsetzung family)
+
+| # | Rule | Add | Notes |
+|---|---|---|---|
+| T2.1 | `de.inf.lg.einspruch_vu` | 2 weeks from service of Versäumnisurteil (ZPO §339) | Q5 — proceeding shape decision |
+| T2.2 | `upc.inf.cfi.wiedereinsetzung` | 2 mo / 1-year-cap from Wegfall des Hindernisses (R.320) | Q4 — needs special arithmetic |
+| T2.3 | `de.inf.lg.wiedereinsetzung` | 2 mo / 1-year-cap (PatG §123 / ZPO §233 ff.) | Q4 |
+| T2.4 | `epa.grant.exa.weiterbehandlung` | 2 mo from loss-of-rights notification (EPC R.135) | — |
+| T2.5 | `upc.inf.cfi.prelim_reply` | 14 days from PO service (R.20.2) | Companion to R.19 (mig 095 added it) |
+| T2.6 | `upc.apl.order.discretion_anchor` | add explicit `refusal` intermediate node so R.220.3 anchors correctly (Q12) | |
+| T2.7 | `upc.dmgs.cfi.app` spawn | `is_spawn=true` from `upc.inf.cfi.decision` (Q9) | |
+| T2.8 | `upc.disc.cfi.app` spawn | same shape as T2.7 | |
+| T2.9 | `epa.grant.exa.r71_3` re-anchor | parent = `exam_req` (§7.5) | |
+| T2.10 | `epa.grant.exa.approval` re-anchor | parent = `r71_3` (§7.5) | |
+| T2.11 | `upc.inf.cfi.appeal_spawn` cross-proc wiring | finish the half-wired spawn execution (Q13) | |
+
+### Tier 3 — tooling primitives (block multiple rules)
+
+| # | Primitive | Blocks | Notes |
+|---|---|---|---|
+| T3.1 | `duration_unit = 'working_days'` | R.198, R.213 | Schema already accepts the string; add to calculator + UI |
+| T3.2 | `combine_op = 'max'` | R.198, R.213, R.245.2 | Column already exists per pauli's 2026-05-13 audit |
+| T3.3 | Multi-anchor "whichever later" trigger | R.245.2.a/b | UI + service work |
+| T3.4 | Outer-cap modelling (`outer_cap_value` + `outer_cap_unit`) | R.245.2 (12mo), R.320 (12mo), EPC Art.112a(4) (12mo) | Schema add |
+| T3.5 | "Before"-mode backward snap to working day | R.109.1, R.109.4 | Calculator change (audit-fristenrechner-completeness-2026-04-30.md §5.4) |
+| T3.6 | Cross-proceeding spawn end-to-end (`is_spawn`) | T2.7, T2.8, T2.11 | Pauli's §6.8 |
+
+### Tier 4 — out-of-scope until separate prioritisation
+
+- DNI family (R.63 / R.67.1 / R.69.1 / R.69.2). Zero published filings 2026-Q1.
+- Registry-correction family (R.16.3.a, R.27.2, R.89.2, R.253.2). Most natural in cascade, not proceeding-tree.
+- GebrMG (no proceeding_type today).
+- R.245 rehearing family (specialist).
+- R.155 cost-decision opposition chain (specialist).
+- R.144 UPC_DAMAGES tree-end row (cosmetic).
+- R.79(2) EPC further-parties period (modelling unclear — Q7).
+
+---
+
+## §11. Next-step proposals (suggested fix-task slicing)
+
+The audit identifies **41 distinct actionable items.** Below is a
+suggested decomposition into fix-tasks that can be assigned
+independently. Sequence reflects "Wave 0 must precede Wave 1" only
+where there's a real dependency (most slices are independent).
+
+### Wave 0 — Tier 0 duration / sequencing / anchor fixes (single fix-task)
+
+**Proposed task:** `t-paliad-264 — Tier 0 deadline-rule corrections
+(duration, anchor, citation) from t-paliad-263 audit`
+
+- 16 row UPDATEs (T0.1–T0.17, deduplicated to 16 distinct rows since
+  T0.8 is covered by T0.2 and T0.11 by T0.1).
+- One migration file (~120 LoC SQL).
+- All within existing schema. No new columns.
+- Idempotent guards on every UPDATE (only fire when the row still has
+  the old value, per the mig 095 convention).
+- Adds 16 entries to `paliad.deadline_rule_audit` (per the mig 079
+  trigger).
+- Verification block: `DO $$ … RAISE EXCEPTION …` per mig 095.
+- **Branch:** `mai/<coder>/t-paliad-264-tier0-deadline-fixes`.
+- **Owner:** coder.
+- **Why first:** all 16 affect either calendar correctness (5 hard
+  duration/anchor bugs) or citation correctness (the 11 metadata
+  fixes are what a lawyer would cite-check against). T0.1–T0.6 are
+  user-visible silent wrongs; ship them.
+
+### Wave 1 — Tier 1 rule additions (single fix-task)
+
+**Proposed task:** `t-paliad-265 — Tier 1 deadline-rule additions
+(12 high-frequency rules)`
+
+- 11 INSERTs + 1 UPDATE re-anchor (T1.12 `upc.pi.cfi.response`).
+- T1.8 (`upc.pi.cfi.merits_start`) **excluded** — blocked on T3.1/T3.2.
+- One migration file (~250 LoC SQL).
+- Add cascade leaves + concepts where needed (each rule should be
+  reachable from Pathway B too).
+- **Branch:** `mai/<coder>/t-paliad-265-tier1-rule-additions`.
+- **Owner:** coder. **Legal review:** m must verify each rule before
+  merge (single round of grilling).
+
+### Wave 2 — Q1 court-set audit decision (separate spike)
+
+**Proposed task:** `t-paliad-266 — Decide court-set vs fixed-period
+modelling for richterliche Fristen (Q1 in t-paliad-263 audit)`
+
+- Inventor / pauli reviews §9.1 with m.
+- Decision artefact: list of rules to flip vs keep, plus UX guideline
+  for what the timeline displays for `is_court_set=true` rules.
+- **Owner:** pauli. **m signs off.**
+
+### Wave 3 — Tier 3 tooling primitives (multi-task)
+
+Each Tier 3 row is its own task because each touches schema + service +
+calculator + UI:
+
+- `t-paliad-267 — working_days unit + combine_op='max' (R.198, R.213)`
+- `t-paliad-268 — Outer-cap modelling (R.245.2, R.320, Art.112a)`
+- `t-paliad-269 — Multi-anchor "whichever later" triggers (R.245.2)`
+- `t-paliad-270 — Backward-snap for `before`-mode rules (R.109.1/.4)`
+- `t-paliad-271 — Cross-proceeding spawn end-to-end execution`
+
+Each is foundational for multiple Tier 2 rules; can ship independently.
+
+### Wave 4 — Tier 2 specialist rules (multi-task, after their primitives land)
+
+Each Tier 2 row is its own task or batched into 2-3 tasks by topical
+area:
+
+- `t-paliad-272 — Wiedereinsetzung / Weiterbehandlung family (T2.2, T2.3, T2.4)` — depends on T3.4 (outer cap).
+- `t-paliad-273 — UPC follow-on spawns (T2.7, T2.8, T2.11)` — depends on T3.6.
+- `t-paliad-274 — UPC tail rules (T2.5, T2.6, R.353, etc.)`
+- `t-paliad-275 — EPA grant timeline re-anchoring (T2.9, T2.10)`.
+
+### Wave 5 — Concept-layer parity (separate audit)
+
+The 9 orphan concepts (`audit-fristen-logic-2026-05-13.md` §3.4 + Q11
+here) need a parallel audit pass to map cascade → rule. Recommend
+spinning a `t-paliad-276 — Cascade-rule parity audit` task once the
+above land.
+
+### Wave 6 — Documentation + retire
+
+- `t-paliad-277 — Drop `_archived_litigation` proceeding_type` once
+  mig 093's audit window closes (Q6).
+- `t-paliad-278 — Document Tier 4 deferrals in
+  `docs/feature-roadmap.md`` so the gap-list isn't lost.
+
+---
+
+## Appendix A — file references
+
+**Live state queried via Supabase MCP, 2026-05-25 14:00–15:00 UTC:**
+
+- `paliad.proceeding_types` — 21 active rows (20 fristenrechner + 1
+  archived).
+- `paliad.deadline_rules` — 132 active + 40 archived rows
+  (`lifecycle_state='published'`).
+- `paliad.deadline_rule_audit` — diff history.
+- `data.laws_contents` (youpc) — UPC RoP + EPC verbatim text
+  (`law_type IN ('UPCRoP','EPC')`).
+
+**paliad migrations consulted:**
+
+- `internal/db/migrations/012_fristenrechner_rules.up.sql` — original
+  seed.
+- `internal/db/migrations/043_de_instance_split_proceedings.up.sql`
+  — DE_INF_OLG / DE_INF_BGH split.
+- `internal/db/migrations/052_event_categories_rop_audit.up.sql`
+  — first RoP audit fix-pass.
+- `internal/db/migrations/079_*` — `paliad.deadline_rule_audit`
+  trigger.
+- `internal/db/migrations/091_drop_legacy_rule_columns.up.sql` —
+  cleanup.
+- `internal/db/migrations/093_retire_litigation_category.up.sql` —
+  archived 40 rules.
+- `internal/db/migrations/095_fristen_gap_fill.up.sql` — t-paliad-205
+  R.19 + R.220.1(a) gap fill.
+- `internal/db/migrations/096_proceeding_code_rename.up.sql` — code
+  rename to `<jurisdiction>.<proceeding>.<instance>` form.
+- `internal/db/migrations/097_legal_citation_backfill.up.sql` —
+  legal_source / rule_code backfill.
+- `internal/db/migrations/100_ccr_visible_rule.up.sql` —
+  `upc.ccr.cfi` alias.
+- `internal/db/migrations/104_einspruch_name_and_ccr_priority.up.sql`
+  — Einspruch rename.
+
+**Companion audits:**
+
+- `docs/audit-fristenrechner-completeness-2026-04-30.md` — curie /
+  t-paliad-084.
+- `docs/audit-upc-rop-deadlines-2026-05-08.md` — curie / t-paliad-159.
+- `docs/audit-fristen-logic-2026-05-13.md` — pauli / t-paliad-157
+  (schema audit, ground-truth on column semantics).
+- `docs/proposals/fristen-gap-fill-2026-05-18.md` — m's 0.3 decisions
+  that shipped as mig 095.
+
+**Authoritative source URLs (all verified 2026-05-25):**
+
+- UPC RoP consolidated 18.05.2023: https://www.unifiedpatentcourt.org/sites/default/files/upc_documents/rop_application_-_consolidated_18_05_2023.pdf
+- EPC 17th ed.: https://www.epo.org/en/legal/epc/2020/index.html
+- EPC R.71 (and other Implementing Reg Rules): https://www.epo.org/en/legal/epc/2020/r71.html
+- PatG: https://www.gesetze-im-internet.de/patg/
+  - §59 https://www.gesetze-im-internet.de/patg/__59.html
+  - §73 https://www.gesetze-im-internet.de/patg/__73.html
+  - §75 https://www.gesetze-im-internet.de/patg/__75.html
+  - §82 https://www.gesetze-im-internet.de/patg/__82.html
+  - §110 https://www.gesetze-im-internet.de/patg/__110.html
+  - §111 https://www.gesetze-im-internet.de/patg/__111.html
+- ZPO: https://www.gesetze-im-internet.de/zpo/
+  - §520 https://www.gesetze-im-internet.de/zpo/__520.html
+  - §521 https://www.gesetze-im-internet.de/zpo/__521.html
+- GebrMG: https://www.gesetze-im-internet.de/gebrmg/
+
+---
+
+## Appendix B — coverage tally
+
+| Status | Count | Share |
+|---|---:|---:|
+| present-correct | 78 | 59 % |
+| present-wrong (DURATION) | 3 | 2 % |
+| present-wrong (anchor/sequence) | 5 | 4 % |
+| present-wrong (citation only) | 11 | 8 % |
+| court-set-mismodelled-as-fixed | 6 | 5 % |
+| **subtotal: still actionable** | **25** | **19 %** |
+| missing (statute defines, paliad doesn't) | 30 | (gap, vs 132 baseline) |
+| n/a (RoP / EPC / PatG section creates no time-limit) | 8 | 6 % |
+| present-correct, no fix needed | (78 above) | |
+
+**Headline figures for m:**
+
+- Of the 132 statutory deadlines paliad currently models, **25 carry
+  an actionable bug** (19%). Of those, **5 are user-visible
+  calendar-correctness bugs** (the 3 duration bugs + the 2
+  sequencing/anchor bugs head flagged + me). The other 20 are
+  citation drift or court-set mismodelling — fix-them-quietly
+  category.
+- An additional **30 statutory deadlines are not modelled at all**
+  (the missing list in §3). Of those, **~12 are ★★★ / ★★ frequency**
+  (Tier 1 in §10); the remaining ~18 are ★ specialist.
+- The 5 duration / sequencing bugs alone are **the most important
+  takeaway**: every UPC_REV proceeding, every UPC main-track appeal
+  respondent, and every DE-LG-Verletzung timeline tracked in paliad
+  today computes wrong dates.
+
+End of audit. Awaiting m's review of §9 Q1–Q13 + Tier 0 sign-off
+before fix-tasks (Wave 0) get cut.

frontend/src/client/date-range-picker-pure.test.ts

@@ -0,0 +1,289 @@
+// Unit tests for the date-range picker's pure helpers (t-paliad-248).
+// Run with `bun test`.
+
+import { test, expect, describe } from "bun:test";
+import {
+  horizonBounds,
+  isValidHorizon,
+  isValidISODate,
+  validateCustomRange,
+  parseURL,
+  serializeURL,
+  isDefault,
+  ALL_HORIZONS,
+  PAST_HORIZONS,
+  NEXT_HORIZONS,
+  type TimeHorizon,
+  type TimeSpec,
+} from "./date-range-picker-pure";
+
+// Anchor the clock so day-arithmetic assertions don't drift with the
+// wall clock. 2026-05-25 00:00 UTC matches the Go-side bounds test.
+const NOW = new Date(Date.UTC(2026, 4, 25));
+const DAY = (offsetDays: number): Date =>
+  new Date(NOW.getTime() + offsetDays * 86_400_000);
+
+describe("ALL_HORIZONS / PAST / NEXT registries", () => {
+  test("registries sum to a known total without overlap", () => {
+    // 6 past + 6 next + any + custom = 14 fan chips (custom is the
+    // trailing entry in ALL_HORIZONS; `all` is intentionally absent —
+    // surfaces don't render the legacy bidirectional-unbounded chip).
+    expect(ALL_HORIZONS.length).toBe(14);
+    expect(PAST_HORIZONS.length).toBe(6);
+    expect(NEXT_HORIZONS.length).toBe(6);
+    expect(new Set(ALL_HORIZONS).size).toBe(ALL_HORIZONS.length);
+  });
+
+  test("PAST_HORIZONS are all past_*", () => {
+    for (const h of PAST_HORIZONS) {
+      expect(h.startsWith("past_")).toBe(true);
+    }
+  });
+
+  test("NEXT_HORIZONS are all next_*", () => {
+    for (const h of NEXT_HORIZONS) {
+      expect(h.startsWith("next_")).toBe(true);
+    }
+  });
+
+  test("ALL_HORIZONS ends with custom and contains any in the middle", () => {
+    expect(ALL_HORIZONS.at(-1)).toBe("custom");
+    expect(ALL_HORIZONS).toContain("any");
+  });
+});
+
+describe("horizonBounds", () => {
+  test("future fan: bounds anchor at today, extend forward", () => {
+    expect(horizonBounds("next_1d", NOW)).toEqual({ from: DAY(0),  to: DAY(1) });
+    expect(horizonBounds("next_7d", NOW)).toEqual({ from: DAY(0),  to: DAY(7) });
+    expect(horizonBounds("next_14d", NOW)).toEqual({ from: DAY(0), to: DAY(14) });
+    expect(horizonBounds("next_30d", NOW)).toEqual({ from: DAY(0), to: DAY(30) });
+    expect(horizonBounds("next_90d", NOW)).toEqual({ from: DAY(0), to: DAY(90) });
+  });
+
+  test("past fan: bounds extend back, upper bound is tomorrow (exclusive end-of-today)", () => {
+    expect(horizonBounds("past_1d",  NOW)).toEqual({ from: DAY(-1),  to: DAY(1) });
+    expect(horizonBounds("past_7d",  NOW)).toEqual({ from: DAY(-7),  to: DAY(1) });
+    expect(horizonBounds("past_14d", NOW)).toEqual({ from: DAY(-14), to: DAY(1) });
+    expect(horizonBounds("past_30d", NOW)).toEqual({ from: DAY(-30), to: DAY(1) });
+    expect(horizonBounds("past_90d", NOW)).toEqual({ from: DAY(-90), to: DAY(1) });
+  });
+
+  test("next_all is one-sided: from=today, to undefined", () => {
+    const b = horizonBounds("next_all", NOW);
+    expect(b.from).toEqual(DAY(0));
+    expect(b.to).toBeUndefined();
+  });
+
+  test("past_all is one-sided: from undefined, to=tomorrow", () => {
+    const b = horizonBounds("past_all", NOW);
+    expect(b.from).toBeUndefined();
+    expect(b.to).toEqual(DAY(1));
+  });
+
+  test("any / all / custom: both bounds undefined", () => {
+    expect(horizonBounds("any",    NOW)).toEqual({});
+    expect(horizonBounds("all",    NOW)).toEqual({});
+    expect(horizonBounds("custom", NOW)).toEqual({});
+  });
+
+  test("bounds anchor on UTC start-of-day regardless of input clock time", () => {
+    const nowAfternoon = new Date(Date.UTC(2026, 4, 25, 14, 37, 0));
+    const nowMidnight = new Date(Date.UTC(2026, 4, 25, 0, 0, 0));
+    expect(horizonBounds("past_7d", nowAfternoon)).toEqual(horizonBounds("past_7d", nowMidnight));
+  });
+});
+
+describe("isValidHorizon", () => {
+  test("accepts every entry in ALL_HORIZONS plus 'all' (legacy)", () => {
+    for (const h of ALL_HORIZONS) {
+      expect(isValidHorizon(h)).toBe(true);
+    }
+    expect(isValidHorizon("all")).toBe(true);
+  });
+
+  test("rejects unknown strings, numbers, undefined, null", () => {
+    expect(isValidHorizon("next_5d")).toBe(false);
+    expect(isValidHorizon("past_100d")).toBe(false);
+    expect(isValidHorizon("")).toBe(false);
+    expect(isValidHorizon(7)).toBe(false);
+    expect(isValidHorizon(undefined)).toBe(false);
+    expect(isValidHorizon(null)).toBe(false);
+  });
+});
+
+describe("isValidISODate", () => {
+  test("accepts valid YYYY-MM-DD", () => {
+    expect(isValidISODate("2026-05-25")).toBe(true);
+    expect(isValidISODate("2026-12-31")).toBe(true);
+    expect(isValidISODate("2024-02-29")).toBe(true);
+  });
+
+  test("rejects shape mismatches", () => {
+    expect(isValidISODate("2026/05/25")).toBe(false);
+    expect(isValidISODate("25.05.2026")).toBe(false);
+    expect(isValidISODate("2026-5-25")).toBe(false);
+    expect(isValidISODate("")).toBe(false);
+    expect(isValidISODate(undefined)).toBe(false);
+  });
+
+  test("rejects calendar-impossible dates (Date.parse silently rolls over)", () => {
+    expect(isValidISODate("2026-02-30")).toBe(false);
+    expect(isValidISODate("2026-13-01")).toBe(false);
+    expect(isValidISODate("2026-04-31")).toBe(false);
+  });
+
+  test("rejects 2025-02-29 (non-leap February)", () => {
+    expect(isValidISODate("2025-02-29")).toBe(false);
+  });
+});
+
+describe("validateCustomRange", () => {
+  test("requires both bounds present and valid", () => {
+    expect(validateCustomRange(undefined, undefined)).toBe("date_range.custom.invalid_missing");
+    expect(validateCustomRange("2026-05-25", undefined)).toBe("date_range.custom.invalid_missing");
+    expect(validateCustomRange(undefined, "2026-05-25")).toBe("date_range.custom.invalid_missing");
+  });
+
+  test("rejects malformed dates with format error", () => {
+    expect(validateCustomRange("bogus", "2026-05-25")).toBe("date_range.custom.invalid_format");
+    expect(validateCustomRange("2026-13-01", "2026-12-31")).toBe("date_range.custom.invalid_format");
+  });
+
+  test("rejects to <= from with invalid error", () => {
+    expect(validateCustomRange("2026-05-25", "2026-05-25")).toBe("date_range.custom.invalid");
+    expect(validateCustomRange("2026-05-25", "2026-05-24")).toBe("date_range.custom.invalid");
+  });
+
+  test("accepts strictly-ordered valid pair", () => {
+    expect(validateCustomRange("2026-05-25", "2026-05-26")).toBeNull();
+    expect(validateCustomRange("2026-01-01", "2026-12-31")).toBeNull();
+  });
+});
+
+describe("parseURL", () => {
+  test("missing horizon yields contract default", () => {
+    expect(parseURL(new URLSearchParams(""))).toEqual({ horizon: "any" });
+    expect(parseURL(new URLSearchParams(""), { default: "next_30d" })).toEqual({ horizon: "next_30d" });
+  });
+
+  test("unknown horizon falls back to default, doesn't throw", () => {
+    expect(parseURL(new URLSearchParams("horizon=mystery"), { default: "next_7d" }))
+      .toEqual({ horizon: "next_7d" });
+  });
+
+  test("every fan horizon round-trips on a fresh URLSearchParams", () => {
+    for (const h of ALL_HORIZONS) {
+      if (h === "custom") continue;
+      const params = new URLSearchParams(`horizon=${h}`);
+      expect(parseURL(params)).toEqual({ horizon: h });
+    }
+  });
+
+  test("custom horizon reads from+to", () => {
+    const params = new URLSearchParams("horizon=custom&horizon_from=2026-03-15&horizon_to=2026-04-30");
+    expect(parseURL(params)).toEqual({
+      horizon: "custom",
+      from: "2026-03-15",
+      to: "2026-04-30",
+    });
+  });
+
+  test("custom with malformed dates falls back to default rather than half-state", () => {
+    const params = new URLSearchParams("horizon=custom&horizon_from=2026-99-99&horizon_to=2026-04-30");
+    expect(parseURL(params, { default: "next_30d" })).toEqual({ horizon: "next_30d" });
+  });
+
+  test("custom with from>=to falls back", () => {
+    const params = new URLSearchParams("horizon=custom&horizon_from=2026-05-25&horizon_to=2026-05-25");
+    expect(parseURL(params)).toEqual({ horizon: "any" });
+  });
+
+  test("custom URL key override", () => {
+    const params = new URLSearchParams("range=past_30d");
+    expect(parseURL(params, { key: "range" })).toEqual({ horizon: "past_30d" });
+    expect(parseURL(params)).toEqual({ horizon: "any" }); // default `horizon` key absent
+  });
+});
+
+describe("serializeURL", () => {
+  test("default horizon is omitted (canonical URL stays short)", () => {
+    const params = new URLSearchParams();
+    serializeURL({ horizon: "any" }, params);
+    expect(params.toString()).toBe("");
+  });
+
+  test("explicit default param removed when value matches default", () => {
+    const params = new URLSearchParams("horizon=past_30d&other=keep");
+    serializeURL({ horizon: "past_30d" }, params, { default: "past_30d" });
+    expect(params.toString()).toBe("other=keep");
+  });
+
+  test("non-default horizon is written", () => {
+    const params = new URLSearchParams("other=keep");
+    serializeURL({ horizon: "next_7d" }, params);
+    expect(params.toString()).toBe("other=keep&horizon=next_7d");
+  });
+
+  test("custom writes horizon+from+to", () => {
+    const params = new URLSearchParams();
+    serializeURL({ horizon: "custom", from: "2026-03-15", to: "2026-04-30" }, params);
+    expect(params.toString()).toBe("horizon=custom&horizon_from=2026-03-15&horizon_to=2026-04-30");
+  });
+
+  test("custom partial bounds: from/to are written individually", () => {
+    const params = new URLSearchParams();
+    serializeURL({ horizon: "custom", from: "2026-03-15" }, params);
+    expect(params.toString()).toBe("horizon=custom&horizon_from=2026-03-15");
+  });
+
+  test("stale params cleared on re-serialize", () => {
+    const params = new URLSearchParams("horizon=custom&horizon_from=2026-03-15&horizon_to=2026-04-30&other=keep");
+    serializeURL({ horizon: "past_30d" }, params);
+    expect(params.toString()).toBe("other=keep&horizon=past_30d");
+    // Stale from/to must be gone.
+    expect(params.has("horizon_from")).toBe(false);
+    expect(params.has("horizon_to")).toBe(false);
+  });
+
+  test("key override propagates to from/to", () => {
+    const params = new URLSearchParams();
+    serializeURL({ horizon: "custom", from: "2026-03-15", to: "2026-04-30" }, params, { key: "range" });
+    expect(params.toString()).toBe("range=custom&range_from=2026-03-15&range_to=2026-04-30");
+  });
+
+  test("URL round-trips through parse → serialize → parse", () => {
+    const specs: TimeSpec[] = [
+      { horizon: "any" },
+      { horizon: "next_7d" },
+      { horizon: "past_all" },
+      { horizon: "next_all" },
+      { horizon: "custom", from: "2026-03-15", to: "2026-04-30" },
+    ];
+    for (const spec of specs) {
+      const params = new URLSearchParams();
+      serializeURL(spec, params);
+      expect(parseURL(params)).toEqual(spec);
+    }
+  });
+});
+
+describe("isDefault", () => {
+  test("true when horizon matches default exactly", () => {
+    expect(isDefault({ horizon: "any" }, "any")).toBe(true);
+    expect(isDefault({ horizon: "next_30d" }, "next_30d")).toBe(true);
+  });
+
+  test("false when horizon differs", () => {
+    expect(isDefault({ horizon: "past_7d" }, "any")).toBe(false);
+    expect(isDefault({ horizon: "next_30d" }, "next_7d")).toBe(false);
+  });
+
+  test("custom is never default — even when bounds match", () => {
+    // No surface treats "custom" as the natural default, so any custom
+    // selection IS user-driven and the closed button must surface
+    // the non-default indicator.
+    expect(isDefault({ horizon: "custom", from: "2026-01-01", to: "2026-12-31" }, "custom" as TimeHorizon))
+      .toBe(false);
+  });
+});

frontend/src/client/date-range-picker-pure.ts

@@ -0,0 +1,292 @@
+// date-range-picker-pure.ts — pure helpers for the symmetric date-range
+// picker (t-paliad-248). No DOM access; runnable under `bun test`. The
+// picker's boot client (date-range-picker.ts) drives the popover, but
+// every interesting decision — what does "Letzte 7 Tage" mean today,
+// what URL params should land, when is a custom range valid — lives
+// here so it can be tested without a browser.
+//
+// The Go side (internal/services/view_service.go:computeViewSpecBounds)
+// is the canonical materializer; horizonBounds() below MUST stay in
+// step with it. The bounds test in pure-tests pins the shape so a
+// divergent change to one side breaks the assertions on the other.
+
+import type { I18nKey } from "../i18n-keys";
+
+/**
+ * TimeHorizon — the full 14-value union the symmetric picker can emit.
+ * Mirrors `internal/services/filter_spec.go` TimeHorizon.
+ *
+ * The fan chips: 6 past + 6 next + the ALLES centre (`any`) + custom.
+ * `all` is the legacy bidirectional-unbounded value, gated to
+ * scope=explicit by the validator (Q26); the picker doesn't surface it
+ * but parseURL accepts it for back-compat with saved Custom Views.
+ */
+export type TimeHorizon =
+  | "next_1d" | "next_7d" | "next_14d" | "next_30d" | "next_90d" | "next_all"
+  | "past_1d" | "past_7d" | "past_14d" | "past_30d" | "past_90d" | "past_all"
+  | "any" | "all" | "custom";
+
+/**
+ * TimeSpec — the wire shape mirrored from the Go FilterSpec.TimeSpec.
+ * `from`/`to` are ISO YYYY-MM-DD strings — UTC dates, not timestamps.
+ * Times-of-day intentionally absent from the picker's contract.
+ */
+export interface TimeSpec {
+  horizon: TimeHorizon;
+  from?: string;
+  to?: string;
+}
+
+/**
+ * The full list of horizon values the picker is willing to render
+ * as chips. Order is the picker's reading order — past edge → past
+ * → ALLES → next → next edge, with `custom` last because it lives
+ * below the chip rows in the popover, not in the row itself.
+ */
+export const ALL_HORIZONS: readonly TimeHorizon[] = [
+  "past_all",
+  "past_90d",
+  "past_30d",
+  "past_14d",
+  "past_7d",
+  "past_1d",
+  "any",
+  "next_1d",
+  "next_7d",
+  "next_14d",
+  "next_30d",
+  "next_90d",
+  "next_all",
+  "custom",
+];
+
+// Strict-validity set. Includes the legacy bidirectional-unbounded `all`
+// horizon so a saved Custom View JSON ({"horizon":"all", …}) deserializes
+// without falling back to the surface default. The picker UI itself
+// doesn't surface a chip for `all` — it's read in, kept as state, but
+// the chip the user sees light up is `any` (the centre ALLES button).
+const ALL_HORIZONS_SET: ReadonlySet<string> = new Set([...ALL_HORIZONS, "all"]);
+
+/**
+ * Past chips, in reading order (outermost → innermost). The picker
+ * renders this left-to-right in the popover's past fan.
+ */
+export const PAST_HORIZONS: readonly TimeHorizon[] = [
+  "past_all",
+  "past_90d",
+  "past_30d",
+  "past_14d",
+  "past_7d",
+  "past_1d",
+];
+
+/**
+ * Future chips, in reading order (innermost → outermost). The picker
+ * renders this left-to-right in the popover's future fan.
+ */
+export const NEXT_HORIZONS: readonly TimeHorizon[] = [
+  "next_1d",
+  "next_7d",
+  "next_14d",
+  "next_30d",
+  "next_90d",
+  "next_all",
+];
+
+/**
+ * The i18n key for the closed-button label and chip text of every
+ * horizon. Lives here (not in the TSX) so a single dictionary lookup
+ * sites can hand back a translated string at any point.
+ */
+export const HORIZON_LABEL_KEY: Record<TimeHorizon, I18nKey> = {
+  past_all: "date_range.horizon.past_all",
+  past_90d: "date_range.horizon.past_90d",
+  past_30d: "date_range.horizon.past_30d",
+  past_14d: "date_range.horizon.past_14d",
+  past_7d:  "date_range.horizon.past_7d",
+  past_1d:  "date_range.horizon.past_1d",
+  any:      "date_range.horizon.any",
+  next_1d:  "date_range.horizon.next_1d",
+  next_7d:  "date_range.horizon.next_7d",
+  next_14d: "date_range.horizon.next_14d",
+  next_30d: "date_range.horizon.next_30d",
+  next_90d: "date_range.horizon.next_90d",
+  next_all: "date_range.horizon.next_all",
+  all:      "date_range.horizon.any", // legacy alias — surfaces "Alles" in the closed label
+  custom:   "date_range.horizon.custom",
+};
+
+/**
+ * Bounds for a given horizon, anchored at `now`. Pure function: the
+ * caller passes the clock so tests can pin a specific day without
+ * mocking Date. Bounds are UTC dates; the `to` bound is exclusive
+ * (start-of-day-after) so "past 7d" includes today.
+ *
+ * Returns `{}` for `any` / `all` / `custom` — the picker's surface
+ * lifts the from/to out of TimeSpec directly when horizon === custom,
+ * and treats unbounded values as "no narrowing in that direction".
+ */
+export function horizonBounds(
+  horizon: TimeHorizon,
+  now: Date,
+): { from?: Date; to?: Date } {
+  const day = new Date(Date.UTC(
+    now.getUTCFullYear(),
+    now.getUTCMonth(),
+    now.getUTCDate(),
+  ));
+  const offset = (days: number): Date =>
+    new Date(day.getTime() + days * 86_400_000);
+
+  switch (horizon) {
+    case "past_1d":  return { from: offset(-1),  to: offset(1) };
+    case "past_7d":  return { from: offset(-7),  to: offset(1) };
+    case "past_14d": return { from: offset(-14), to: offset(1) };
+    case "past_30d": return { from: offset(-30), to: offset(1) };
+    case "past_90d": return { from: offset(-90), to: offset(1) };
+    case "past_all": return {                    to: offset(1) };
+    case "next_1d":  return { from: day,         to: offset(1) };
+    case "next_7d":  return { from: day,         to: offset(7) };
+    case "next_14d": return { from: day,         to: offset(14) };
+    case "next_30d": return { from: day,         to: offset(30) };
+    case "next_90d": return { from: day,         to: offset(90) };
+    case "next_all": return { from: day                       };
+    case "any":
+    case "all":
+    case "custom":
+      return {};
+  }
+}
+
+/**
+ * isValidHorizon — narrows an unknown string to a TimeHorizon, used
+ * by parseURL and by surface-side URL alias adapters.
+ */
+export function isValidHorizon(s: unknown): s is TimeHorizon {
+  return typeof s === "string" && ALL_HORIZONS_SET.has(s);
+}
+
+const ISO_DATE_RE = /^\d{4}-\d{2}-\d{2}$/;
+
+/**
+ * isValidISODate — `YYYY-MM-DD` shape check plus a real-date validity
+ * check (rejects 2026-02-30). Doesn't enforce timezone or floor at any
+ * particular date.
+ */
+export function isValidISODate(s: unknown): s is string {
+  if (typeof s !== "string" || !ISO_DATE_RE.test(s)) return false;
+  const ms = Date.parse(`${s}T00:00:00Z`);
+  if (Number.isNaN(ms)) return false;
+  // Reject 2026-02-30 etc. — Date.parse accepts those by rolling over.
+  return new Date(ms).toISOString().slice(0, 10) === s;
+}
+
+/**
+ * Validate a custom range. Returns null on success, an i18n key
+ * pointing at the error message on failure.
+ *
+ * Rules:
+ *   - Both `from` and `to` must be valid ISO YYYY-MM-DD.
+ *   - `to` must be strictly after `from` (single-day ranges use
+ *     `from=2026-05-25&to=2026-05-26`, NOT `from=to=2026-05-25`).
+ */
+export function validateCustomRange(
+  from: string | undefined,
+  to: string | undefined,
+): I18nKey | null {
+  if (!from || !to) return "date_range.custom.invalid_missing";
+  if (!isValidISODate(from) || !isValidISODate(to)) return "date_range.custom.invalid_format";
+  if (Date.parse(`${from}T00:00:00Z`) >= Date.parse(`${to}T00:00:00Z`)) {
+    return "date_range.custom.invalid";
+  }
+  return null;
+}
+
+/**
+ * URLContract — the picker's stable URL serialization. Surfaces can
+ * override the param name via `key` so two pickers on the same page
+ * (rare) don't collide.
+ */
+export interface URLContract {
+  /** Base param name, defaults to "horizon". */
+  key?: string;
+  /** Default value omitted from URL (matches surface's natural default). */
+  default?: TimeHorizon;
+}
+
+/**
+ * parseURL — reads a URL search-params object into a TimeSpec.
+ *
+ *   ?horizon=past_30d                       → {horizon:"past_30d"}
+ *   ?horizon=custom&from=2026-03-15&to=…    → {horizon:"custom",from,to}
+ *   (no params)                             → {horizon: contract.default ?? "any"}
+ *
+ * Unknown / malformed values fall back to the default. Out-of-shape
+ * custom dates clamp to {horizon: default} — the picker never lands
+ * in a half-custom state from a URL.
+ */
+export function parseURL(
+  params: URLSearchParams,
+  contract: URLContract = {},
+): TimeSpec {
+  const key = contract.key ?? "horizon";
+  const fallback: TimeHorizon = contract.default ?? "any";
+
+  const raw = params.get(key);
+  if (raw === null) return { horizon: fallback };
+  if (!isValidHorizon(raw)) return { horizon: fallback };
+  if (raw !== "custom") return { horizon: raw };
+
+  const from = params.get(`${key}_from`) ?? undefined;
+  const to = params.get(`${key}_to`) ?? undefined;
+  if (validateCustomRange(from, to) !== null) {
+    return { horizon: fallback };
+  }
+  return { horizon: "custom", from, to };
+}
+
+/**
+ * serializeURL — writes a TimeSpec into the URL search-params object,
+ * mutating the passed-in instance. Values equal to the surface
+ * default are OMITTED — the canonical URL stays short.
+ *
+ * Always deletes `horizon`, `<key>_from`, `<key>_to` first so a
+ * re-serialise after the picker reverts to default cleans up rather
+ * than accumulating stale entries.
+ */
+export function serializeURL(
+  spec: TimeSpec,
+  params: URLSearchParams,
+  contract: URLContract = {},
+): void {
+  const key = contract.key ?? "horizon";
+  const fromKey = `${key}_from`;
+  const toKey = `${key}_to`;
+
+  params.delete(key);
+  params.delete(fromKey);
+  params.delete(toKey);
+
+  if (spec.horizon === (contract.default ?? "any") && spec.horizon !== "custom") {
+    return;
+  }
+
+  if (spec.horizon === "custom") {
+    params.set(key, "custom");
+    if (spec.from) params.set(fromKey, spec.from);
+    if (spec.to) params.set(toKey, spec.to);
+    return;
+  }
+
+  params.set(key, spec.horizon);
+}
+
+/**
+ * isDefault — used by surfaces to decide whether to render the
+ * "value is non-default" dot on the closed button.
+ */
+export function isDefault(spec: TimeSpec, defaultHorizon: TimeHorizon): boolean {
+  if (spec.horizon !== defaultHorizon) return false;
+  if (spec.horizon === "custom") return false;
+  return true;
+}

frontend/src/client/date-range-picker.ts

@@ -0,0 +1,470 @@
+// date-range-picker.ts — boot client + DOM mount for the symmetric
+// date-range picker (t-paliad-248). The picker is a controlled
+// component: callers pass `value` + `onChange`, the component renders
+// the trigger button + popover scaffold, the popover materialises a
+// chip row and (when "Anpassen" is picked) an inline date-pair editor.
+//
+// The picker reuses the existing `.agenda-chip` styling for chips and
+// the `.multi-panel` popover pattern (auto-positioned under a
+// `.multi-anchor` wrapper). Both patterns are battle-tested by the
+// filter-bar + multi-select widgets — no new design tokens, no new
+// dark-mode contrast risk.
+
+import { t } from "./i18n";
+import {
+  ALL_HORIZONS,
+  HORIZON_LABEL_KEY,
+  NEXT_HORIZONS,
+  PAST_HORIZONS,
+  isDefault,
+  isValidISODate,
+  validateCustomRange,
+  type TimeHorizon,
+  type TimeSpec,
+} from "./date-range-picker-pure";
+
+export interface MountOpts {
+  /** Current value. The picker is fully controlled. */
+  value: TimeSpec;
+  /** Fired on every committed change (chip click or Anwenden). */
+  onChange(next: TimeSpec): void;
+  /**
+   * Which horizon constitutes the "default" for this surface. Used
+   * for the non-default indicator dot. Defaults to `"any"`.
+   */
+  defaultHorizon?: TimeHorizon;
+  /**
+   * Which chips to render. Order is preserved. Defaults to the full
+   * 14-chip fan from ALL_HORIZONS.
+   */
+  presets?: readonly TimeHorizon[];
+  /**
+   * Stable surface tag — feeds into the `data-testid` on every DOM
+   * node the picker creates so tests can scope. Example: "agenda",
+   * "filter-bar.time", "audit-log".
+   */
+  surface: string;
+  /**
+   * Optional prefix for the closed-button label. The label always
+   * starts with the resolved horizon name (e.g. "Letzte 30 Tage").
+   * Surfaces that want a heading prefix ("Zeitraum: Letzte 30 Tage")
+   * pass it here.
+   */
+  labelPrefix?: string;
+}
+
+export interface PickerHandle {
+  /** Root element — append to the host container. */
+  element: HTMLElement;
+  /** Read the current value (may have been edited via Anpassen). */
+  getValue(): TimeSpec;
+  /** Update the value from the host (e.g. after URL change). */
+  setValue(next: TimeSpec): void;
+  /** Force-close the popover. Safe to call when already closed. */
+  close(): void;
+  /** Detach event listeners + remove from DOM. */
+  destroy(): void;
+}
+
+/**
+ * Mount a date-range picker. The returned `element` is a single
+ * inline node containing both the trigger button and the popover
+ * (absolutely positioned via `.multi-anchor` + `.multi-panel`).
+ *
+ * The popover stays in the DOM permanently; opening/closing toggles
+ * the `[hidden]` attribute. This keeps the chip's tab-order stable
+ * and matches the multi-select widget's behaviour.
+ */
+export function mountDateRangePicker(opts: MountOpts): PickerHandle {
+  const presets = opts.presets ?? ALL_HORIZONS;
+  const defaultHorizon = opts.defaultHorizon ?? "any";
+  let value: TimeSpec = normalize(opts.value);
+
+  // Cached drafts for the "Anpassen" editor — preserved across
+  // open/close so the user doesn't lose their typing if they peek
+  // away. Seeded from the live value when the editor opens.
+  let customFromDraft = value.horizon === "custom" ? (value.from ?? "") : "";
+  let customToDraft = value.horizon === "custom" ? (value.to ?? "") : "";
+  let customEditorOpen = value.horizon === "custom";
+
+  const root = document.createElement("div");
+  root.className = "date-range-anchor multi-anchor";
+  root.dataset.testid = `${opts.surface}.date-range-picker`;
+
+  const trigger = document.createElement("button");
+  trigger.type = "button";
+  trigger.className = "date-range-trigger";
+  trigger.setAttribute("aria-haspopup", "dialog");
+  trigger.setAttribute("aria-expanded", "false");
+  trigger.dataset.testid = `${opts.surface}.date-range-trigger`;
+
+  const panel = document.createElement("div");
+  panel.className = "date-range-panel multi-panel";
+  panel.setAttribute("role", "dialog");
+  panel.setAttribute("aria-label", t("date_range.dialog.label"));
+  panel.hidden = true;
+  panel.dataset.testid = `${opts.surface}.date-range-panel`;
+
+  root.appendChild(trigger);
+  root.appendChild(panel);
+
+  renderTrigger();
+  renderPanel();
+
+  // Open/close wiring. Click outside the root collapses the popover;
+  // Esc inside it bubbles up to the same handler via keydown delegate.
+  const onDocClick = (e: MouseEvent) => {
+    if (panel.hidden) return;
+    if (e.target instanceof Node && root.contains(e.target)) return;
+    closePopover();
+  };
+  const onKeydown = (e: KeyboardEvent) => {
+    if (panel.hidden) return;
+    if (e.key === "Escape") {
+      e.stopPropagation();
+      closePopover();
+      trigger.focus();
+    }
+  };
+
+  trigger.addEventListener("click", () => {
+    if (panel.hidden) openPopover();
+    else closePopover();
+  });
+
+  document.addEventListener("mousedown", onDocClick);
+  document.addEventListener("keydown", onKeydown);
+
+  function openPopover(): void {
+    panel.hidden = false;
+    trigger.setAttribute("aria-expanded", "true");
+    // Re-render to reflect the very latest value (host may have
+    // patched via setValue between open/close).
+    renderPanel();
+    // Move keyboard focus into the panel so Esc works without a
+    // prior click. The first chip is the natural landing spot.
+    const firstChip = panel.querySelector<HTMLButtonElement>(".date-range-chip");
+    firstChip?.focus({ preventScroll: true });
+  }
+
+  function closePopover(): void {
+    panel.hidden = true;
+    trigger.setAttribute("aria-expanded", "false");
+  }
+
+  function commit(next: TimeSpec, closeAfter: boolean): void {
+    value = normalize(next);
+    customEditorOpen = value.horizon === "custom";
+    if (value.horizon === "custom") {
+      customFromDraft = value.from ?? "";
+      customToDraft = value.to ?? "";
+    }
+    renderTrigger();
+    renderPanel();
+    opts.onChange(value);
+    if (closeAfter) {
+      closePopover();
+      trigger.focus({ preventScroll: true });
+    }
+  }
+
+  function renderTrigger(): void {
+    trigger.replaceChildren();
+    if (!isDefault(value, defaultHorizon)) {
+      const dot = document.createElement("span");
+      dot.className = "date-range-trigger-dot";
+      dot.setAttribute("aria-hidden", "true");
+      trigger.appendChild(dot);
+    }
+    const labelSpan = document.createElement("span");
+    labelSpan.className = "date-range-trigger-label";
+    labelSpan.textContent = labelFor(value, opts.labelPrefix);
+    trigger.appendChild(labelSpan);
+
+    const chev = document.createElement("span");
+    chev.className = "date-range-trigger-chev";
+    chev.setAttribute("aria-hidden", "true");
+    chev.textContent = "▾";
+    trigger.appendChild(chev);
+  }
+
+  function renderPanel(): void {
+    panel.replaceChildren();
+
+    // Three groups in a single row: past fan / ALLES centre / next fan.
+    const row = document.createElement("div");
+    row.className = "date-range-row";
+
+    const pastGroup = renderFan(
+      PAST_HORIZONS.filter((h) => presets.includes(h)),
+      "past",
+    );
+    const centerGroup = renderCenter();
+    const nextGroup = renderFan(
+      NEXT_HORIZONS.filter((h) => presets.includes(h)),
+      "next",
+    );
+
+    if (pastGroup) row.appendChild(pastGroup);
+    if (centerGroup) row.appendChild(centerGroup);
+    if (nextGroup) row.appendChild(nextGroup);
+
+    panel.appendChild(row);
+
+    // Custom-range section ("Anpassen"). Toggle button + collapsible
+    // date-pair editor below.
+    if (presets.includes("custom")) {
+      panel.appendChild(renderCustomSection());
+    }
+  }
+
+  function renderFan(horizons: readonly TimeHorizon[], side: "past" | "next"): HTMLElement | null {
+    if (horizons.length === 0) return null;
+    const group = document.createElement("div");
+    group.className = `date-range-fan date-range-fan--${side}`;
+    group.setAttribute("role", "group");
+    group.setAttribute("aria-label", side === "past"
+      ? t("date_range.fan.past.label")
+      : t("date_range.fan.future.label"));
+    for (const h of horizons) {
+      group.appendChild(makeChip(h));
+    }
+    return group;
+  }
+
+  function renderCenter(): HTMLElement | null {
+    if (!presets.includes("any")) return null;
+    const wrap = document.createElement("div");
+    wrap.className = "date-range-center";
+    const btn = document.createElement("button");
+    btn.type = "button";
+    btn.className = "date-range-center-btn";
+    if (value.horizon === "any" || value.horizon === "all") {
+      btn.classList.add("date-range-center-btn--active");
+    }
+    btn.setAttribute("aria-pressed", String(value.horizon === "any" || value.horizon === "all"));
+    btn.dataset.testid = `${opts.surface}.date-range-chip.any`;
+
+    const glyph = document.createElement("span");
+    glyph.className = "date-range-center-glyph";
+    glyph.setAttribute("aria-hidden", "true");
+    glyph.textContent = "⌖"; // ⌖ POSITION INDICATOR
+    const label = document.createElement("span");
+    label.className = "date-range-center-label";
+    label.textContent = t("date_range.center.label");
+    btn.appendChild(glyph);
+    btn.appendChild(label);
+
+    btn.addEventListener("click", () => {
+      commit({ horizon: "any" }, /*closeAfter*/ true);
+    });
+
+    wrap.appendChild(btn);
+    return wrap;
+  }
+
+  function makeChip(h: TimeHorizon): HTMLButtonElement {
+    const chip = document.createElement("button");
+    chip.type = "button";
+    chip.className = "agenda-chip date-range-chip";
+    if (value.horizon === h) chip.classList.add("agenda-chip-active");
+    chip.setAttribute("aria-pressed", String(value.horizon === h));
+    chip.textContent = t(HORIZON_LABEL_KEY[h]);
+    chip.dataset.testid = `${opts.surface}.date-range-chip.${h}`;
+    chip.addEventListener("click", () => {
+      commit({ horizon: h }, /*closeAfter*/ true);
+    });
+    return chip;
+  }
+
+  function renderCustomSection(): HTMLElement {
+    const section = document.createElement("div");
+    section.className = "date-range-custom";
+
+    const toggleBtn = document.createElement("button");
+    toggleBtn.type = "button";
+    toggleBtn.className = "agenda-chip date-range-chip date-range-chip--custom";
+    if (value.horizon === "custom") toggleBtn.classList.add("agenda-chip-active");
+    toggleBtn.setAttribute("aria-expanded", String(customEditorOpen));
+    toggleBtn.dataset.testid = `${opts.surface}.date-range-chip.custom`;
+    toggleBtn.textContent = t("date_range.horizon.custom");
+    toggleBtn.addEventListener("click", () => {
+      customEditorOpen = !customEditorOpen;
+      renderPanel();
+      if (customEditorOpen) {
+        // Focus the first input on expand.
+        panel.querySelector<HTMLInputElement>(".date-range-custom-from")?.focus();
+      }
+    });
+    section.appendChild(toggleBtn);
+
+    if (!customEditorOpen) return section;
+
+    const editor = document.createElement("div");
+    editor.className = "date-range-custom-editor";
+
+    const fromWrap = document.createElement("label");
+    fromWrap.className = "date-range-custom-field";
+    const fromLbl = document.createElement("span");
+    fromLbl.className = "date-range-custom-label";
+    fromLbl.textContent = t("date_range.custom.from");
+    const fromInput = document.createElement("input");
+    fromInput.type = "date";
+    fromInput.lang = "de";
+    fromInput.className = "date-range-custom-from";
+    fromInput.value = customFromDraft;
+    fromInput.dataset.testid = `${opts.surface}.date-range-custom-from`;
+    fromInput.addEventListener("input", () => {
+      customFromDraft = fromInput.value;
+      refreshValidity();
+    });
+    fromWrap.appendChild(fromLbl);
+    fromWrap.appendChild(fromInput);
+
+    const toWrap = document.createElement("label");
+    toWrap.className = "date-range-custom-field";
+    const toLbl = document.createElement("span");
+    toLbl.className = "date-range-custom-label";
+    toLbl.textContent = t("date_range.custom.to");
+    const toInput = document.createElement("input");
+    toInput.type = "date";
+    toInput.lang = "de";
+    toInput.className = "date-range-custom-to";
+    toInput.value = customToDraft;
+    toInput.dataset.testid = `${opts.surface}.date-range-custom-to`;
+    toInput.addEventListener("input", () => {
+      customToDraft = toInput.value;
+      refreshValidity();
+    });
+    toWrap.appendChild(toLbl);
+    toWrap.appendChild(toInput);
+
+    const applyBtn = document.createElement("button");
+    applyBtn.type = "button";
+    applyBtn.className = "date-range-custom-apply";
+    applyBtn.textContent = t("date_range.custom.apply");
+    applyBtn.dataset.testid = `${opts.surface}.date-range-custom-apply`;
+    applyBtn.addEventListener("click", () => {
+      const err = validateCustomRange(customFromDraft, customToDraft);
+      if (err !== null) {
+        showError(err);
+        return;
+      }
+      commit(
+        { horizon: "custom", from: customFromDraft, to: customToDraft },
+        /*closeAfter*/ true,
+      );
+    });
+
+    const cancelBtn = document.createElement("button");
+    cancelBtn.type = "button";
+    cancelBtn.className = "date-range-custom-cancel";
+    cancelBtn.textContent = t("date_range.custom.cancel");
+    cancelBtn.addEventListener("click", () => {
+      customEditorOpen = false;
+      // Restore drafts from live value so a re-open shows the
+      // committed state rather than the abandoned typing.
+      customFromDraft = value.horizon === "custom" ? (value.from ?? "") : "";
+      customToDraft = value.horizon === "custom" ? (value.to ?? "") : "";
+      renderPanel();
+    });
+
+    const errEl = document.createElement("div");
+    errEl.className = "date-range-custom-error";
+    errEl.hidden = true;
+    errEl.dataset.testid = `${opts.surface}.date-range-custom-error`;
+
+    editor.appendChild(fromWrap);
+    editor.appendChild(toWrap);
+    editor.appendChild(applyBtn);
+    editor.appendChild(cancelBtn);
+    editor.appendChild(errEl);
+    section.appendChild(editor);
+
+    refreshValidity();
+
+    function refreshValidity(): void {
+      const err = validateCustomRange(customFromDraft, customToDraft);
+      if (err === null) {
+        applyBtn.disabled = false;
+        errEl.hidden = true;
+        errEl.textContent = "";
+        return;
+      }
+      applyBtn.disabled = true;
+      // Only surface the *content* error (`invalid` = inverted range)
+      // while the user is typing. Empty / format errors are visible
+      // through the disabled-Anwenden state alone — surfacing them on
+      // every keystroke would be noisy.
+      if (err === "date_range.custom.invalid") {
+        showError(err);
+      } else {
+        errEl.hidden = true;
+      }
+    }
+
+    function showError(key: Parameters<typeof t>[0]): void {
+      errEl.textContent = t(key);
+      errEl.hidden = false;
+    }
+
+    return section;
+  }
+
+  return {
+    element: root,
+    getValue: () => normalize(value),
+    setValue(next: TimeSpec) {
+      value = normalize(next);
+      customEditorOpen = value.horizon === "custom";
+      if (value.horizon === "custom") {
+        customFromDraft = value.from ?? "";
+        customToDraft = value.to ?? "";
+      }
+      renderTrigger();
+      renderPanel();
+    },
+    close: closePopover,
+    destroy() {
+      document.removeEventListener("mousedown", onDocClick);
+      document.removeEventListener("keydown", onKeydown);
+      root.remove();
+    },
+  };
+}
+
+function normalize(spec: TimeSpec): TimeSpec {
+  if (spec.horizon === "custom") {
+    return {
+      horizon: "custom",
+      from: spec.from && isValidISODate(spec.from) ? spec.from : undefined,
+      to: spec.to && isValidISODate(spec.to) ? spec.to : undefined,
+    };
+  }
+  return { horizon: spec.horizon };
+}
+
+function labelFor(spec: TimeSpec, prefix?: string): string {
+  let body: string;
+  if (spec.horizon === "custom") {
+    if (spec.from && spec.to) {
+      body = t("date_range.button.label.custom_range")
+        .replace("{from}", formatISO(spec.from))
+        .replace("{to}", formatISO(spec.to));
+    } else {
+      body = t("date_range.horizon.custom");
+    }
+  } else {
+    body = t(HORIZON_LABEL_KEY[spec.horizon]);
+  }
+  return prefix ? `${prefix}: ${body}` : body;
+}
+
+function formatISO(iso: string): string {
+  if (!isValidISODate(iso)) return iso;
+  // DE locale: DD.MM.YYYY. The picker is German-first; surfaces in EN
+  // can override via labelPrefix or by formatting before commit if
+  // they want a different shape.
+  const [y, m, d] = iso.split("-");
+  return `${d}.${m}.${y}`;
+}

frontend/src/client/filter-bar/axes.ts

@@ -12,6 +12,12 @@
 // New classes are scoped under .filter-bar-* so they don't bleed.
 
 import { t, tDyn, type I18nKey } from "../i18n";
+import { mountDateRangePicker } from "../date-range-picker";
+import {
+  ALL_HORIZONS as DRP_ALL_HORIZONS,
+  type TimeHorizon as DRPTimeHorizon,
+  type TimeSpec as DRPTimeSpec,
+} from "../date-range-picker-pure";
 import type { BarState, AxisKey } from "./types";
 
 export interface AxisCtx {
@@ -57,60 +63,63 @@ export function renderAxis(axis: AxisKey, ctx: AxisCtx, opts?: RenderAxisOpts):
 }
 
 // ----------------------------------------------------------------------
-// time — chip cluster (presets + Anpassen)
+// time — symmetric date-range picker (t-paliad-248, replaces the t-163
+// chip-cluster + disabled Anpassen stub). The picker emits a TimeSpec
+// (horizon + optional custom from/to); the bar patches that onto
+// BarState.time directly.
 // ----------------------------------------------------------------------
 
 type TimeHorizonValue = NonNullable<BarState["time"]>["horizon"];
 
-const TIME_PRESET_LABELS: Record<TimeHorizonValue, I18nKey> = {
-  next_7d:  "views.bar.time.next_7d",
-  next_30d: "views.bar.time.next_30d",
-  next_90d: "views.bar.time.next_90d",
-  past_7d:  "views.bar.time.past_7d",
-  past_30d: "views.bar.time.past_30d",
-  past_90d: "views.bar.time.past_90d",
-  any:      "views.bar.time.any",
-  all:      "views.bar.time.all",
-  custom:   "views.bar.time.custom",
-};
-
+// Default chip set when the surface doesn't override. Matches the
+// forward-leaning bias of the legacy filter-bar default (the universal
+// substrate is more often used for "what's coming up" than "what just
+// happened") but now covers the full symmetric fan plus past_30d for
+// quick recent-history lookups.
 const DEFAULT_TIME_PRESETS: TimeHorizonValue[] = [
-  "next_7d", "next_30d", "next_90d", "past_30d", "any",
+  "past_30d", "past_7d", "any", "next_7d", "next_30d", "next_90d", "custom",
 ];
 
 function renderTimeAxis(ctx: AxisCtx, presetOverride?: TimeHorizonValue[]): HTMLElement {
   const wrap = group("views.bar.label.time");
-  const row = chipRow();
-  const presets = presetOverride && presetOverride.length ? presetOverride : DEFAULT_TIME_PRESETS;
-  // "any" / "all" are both unbounded — clearing state is the cleanest
-  // representation, so each maps to "no overlay" rather than a stored
-  // horizon. The chip's active state then keys off "no time set".
-  const current = ctx.get("time")?.horizon ?? "any";
-  for (const preset of presets) {
-    if (preset === "custom") continue; // custom rendered separately below
-    const isUnbounded = preset === "any" || preset === "all";
-    const isActive = isUnbounded
-      ? !ctx.get("time")
-      : preset === current;
-    const chip = chipBtn(t(TIME_PRESET_LABELS[preset]), isActive);
-    chip.addEventListener("click", () => {
-      if (isUnbounded) {
+  const presetSource = presetOverride && presetOverride.length ? presetOverride : DEFAULT_TIME_PRESETS;
+  // The picker's pure module owns the complete chip set; we narrow it
+  // here to whatever this surface declares (preserving the surface's
+  // chip order so timePresets remains the override knob it always was).
+  const presets: DRPTimeHorizon[] = presetSource.flatMap((p) =>
+    DRP_ALL_HORIZONS.includes(p as DRPTimeHorizon) ? [p as DRPTimeHorizon] : [],
+  );
+
+  const current = ctx.get("time");
+  const initialValue: DRPTimeSpec = current
+    ? { horizon: current.horizon as DRPTimeHorizon, from: current.from, to: current.to }
+    : { horizon: "any" };
+
+  const picker = mountDateRangePicker({
+    value: initialValue,
+    onChange(next) {
+      // The bar treats `any` as "no time overlay" (matches the legacy
+      // chip-cluster's behaviour) so the BarState stays minimal when
+      // the user lands on the centre ALLES button.
+      if (next.horizon === "any") {
         ctx.patch({ time: undefined });
-      } else {
-        ctx.patch({ time: { horizon: preset } });
+        return;
       }
-    });
-    row.appendChild(chip);
-  }
-  // Custom range — placeholder chip; opens a small popover with two
-  // <input type="date"> in Phase 2. For Phase 1 we render the chip
-  // disabled with a tooltip so the affordance is discoverable.
-  const customChip = chipBtn(t("views.bar.time.custom"), current === "custom");
-  customChip.classList.add("filter-bar-chip-pending");
-  customChip.title = t("views.bar.time.custom.coming_soon");
-  customChip.disabled = true;
-  row.appendChild(customChip);
-  wrap.appendChild(row);
+      ctx.patch({
+        time: {
+          horizon: next.horizon as TimeHorizonValue,
+          from: next.horizon === "custom" ? next.from : undefined,
+          to:   next.horizon === "custom" ? next.to   : undefined,
+        },
+      });
+    },
+    defaultHorizon: "any",
+    presets,
+    surface: "filter-bar.time",
+    labelPrefix: t("views.bar.label.time"),
+  });
+
+  wrap.appendChild(picker.element);
   return wrap;
 }
 

frontend/src/client/filter-bar/types.ts

@@ -65,7 +65,13 @@ export interface BarState {
 }
 
 export interface TimeOverlay {
-  horizon: "next_7d" | "next_30d" | "next_90d" | "past_7d" | "past_30d" | "past_90d" | "any" | "all" | "custom";
+  // Mirrors internal/services/filter_spec.go TimeHorizon. t-paliad-248
+  // added the symmetric 1d / 14d / all chips on each side; the union
+  // here is the wire-shape the URL codec parses and the picker emits.
+  horizon:
+    | "next_1d" | "next_7d" | "next_14d" | "next_30d" | "next_90d" | "next_all"
+    | "past_1d" | "past_7d" | "past_14d" | "past_30d" | "past_90d" | "past_all"
+    | "any" | "all" | "custom";
   from?: string; // ISO 8601 — only when horizon === "custom"
   to?: string;
 }

frontend/src/client/filter-bar/url-codec.test.ts

@@ -18,7 +18,12 @@ describe("filter-bar/url-codec", () => {
   });
 
   test("time horizon round-trips", () => {
-    for (const h of ["next_7d", "next_30d", "next_90d", "past_30d", "past_90d", "any", "all"] as const) {
+    // Includes the t-paliad-248 symmetric additions (1d / 14d / all on each side).
+    for (const h of [
+      "next_1d", "next_7d", "next_14d", "next_30d", "next_90d", "next_all",
+      "past_1d", "past_7d", "past_14d", "past_30d", "past_90d", "past_all",
+      "any", "all",
+    ] as const) {
       expect(roundTrip({ time: { horizon: h } })).toEqual({ time: { horizon: h } });
     }
   });

frontend/src/client/filter-bar/url-codec.ts

@@ -172,12 +172,18 @@ export function encodeBar(state: BarState, params: URLSearchParams, ns?: string)
 
 function parseHorizon(s: string): TimeOverlay["horizon"] | null {
   switch (s) {
+    case "next_1d":
     case "next_7d":
+    case "next_14d":
     case "next_30d":
     case "next_90d":
+    case "next_all":
+    case "past_1d":
     case "past_7d":
+    case "past_14d":
     case "past_30d":
     case "past_90d":
+    case "past_all":
     case "any":
     case "all":
     case "custom":

frontend/src/client/i18n.ts

@@ -2689,11 +2689,18 @@ const translations: Record<Lang, Record<string, string>> = {
     "views.scope.my_subtree": "Mein Teilbaum",
     "views.scope.explicit": "Bestimmte Projekte",
     "views.scope.personal_only": "Nur persönliche",
+    "views.horizon.next_1d": "Morgen",
     "views.horizon.next_7d": "Nächste 7 Tage",
+    "views.horizon.next_14d": "Nächste 14 Tage",
     "views.horizon.next_30d": "Nächste 30 Tage",
     "views.horizon.next_90d": "Nächste 90 Tage",
+    "views.horizon.next_all": "Ganze Zukunft",
+    "views.horizon.past_1d": "Letzter Tag",
+    "views.horizon.past_7d": "Letzte 7 Tage",
+    "views.horizon.past_14d": "Letzte 14 Tage",
     "views.horizon.past_30d": "Letzte 30 Tage",
     "views.horizon.past_90d": "Letzte 90 Tage",
+    "views.horizon.past_all": "Ganze Vergangenheit",
     "views.horizon.any": "Beliebig",
     "views.horizon.all": "Komplett (alle Daten)",
     "views.horizon.custom": "Benutzerdefiniert",
@@ -2777,16 +2784,10 @@ const translations: Record<Lang, Record<string, string>> = {
     "views.bar.label.density": "Dichte",
     "views.bar.label.sort": "Sortierung",
     "views.bar.common.all": "Alle",
-    "views.bar.time.next_7d": "7 Tage",
-    "views.bar.time.next_30d": "30 Tage",
-    "views.bar.time.next_90d": "90 Tage",
-    "views.bar.time.past_7d": "Letzte 7 T.",
-    "views.bar.time.past_30d": "Letzte 30 T.",
-    "views.bar.time.past_90d": "Letzte 90 T.",
-    "views.bar.time.any": "Beliebig",
-    "views.bar.time.all": "Alle Zeit",
-    "views.bar.time.custom": "Anpassen",
-    "views.bar.time.custom.coming_soon": "Benutzerdefinierter Zeitraum folgt in einer der nächsten Iterationen.",
+    // views.bar.time.* keys retired in t-paliad-248 — the filter-bar time
+    // axis now mounts the symmetric date-range picker, whose labels live
+    // under date_range.horizon.* (see end of this dict). The picker reuses
+    // views.bar.label.time as the closed-button prefix.
     "views.bar.personal.on": "Nur eigene",
     "views.bar.approval_role.approver_eligible": "Zur Genehmigung",
     "views.bar.approval_role.self_requested": "Eigene Anfragen",
@@ -3013,6 +3014,38 @@ const translations: Record<Lang, Record<string, string>> = {
     "admin.rules.export.ok": "{n} Audit-Zeilen exportiert.",
     "admin.rules.export.error": "Export fehlgeschlagen.",
     "admin.rules.export.no_pending": "Keine offenen Audit-Zeilen zum Export.",
+
+    // Date-range picker (t-paliad-248). Symmetric past/future chip fan
+    // around an ALLES centre. Used by the filter-bar 'time' axis from
+    // Slice A onwards; future slices will migrate /agenda and
+    // /admin/audit-log to the same component.
+    "date_range.button.label": "Zeitraum",
+    "date_range.button.label.custom_range": "Von {from} bis {to}",
+    "date_range.horizon.next_1d":  "Morgen",
+    "date_range.horizon.next_7d":  "Nächste 7 Tage",
+    "date_range.horizon.next_14d": "Nächste 14 Tage",
+    "date_range.horizon.next_30d": "Nächste 30 Tage",
+    "date_range.horizon.next_90d": "Nächste 90 Tage",
+    "date_range.horizon.next_all": "Ganze Zukunft",
+    "date_range.horizon.past_1d":  "Letzter Tag",
+    "date_range.horizon.past_7d":  "Letzte 7 Tage",
+    "date_range.horizon.past_14d": "Letzte 14 Tage",
+    "date_range.horizon.past_30d": "Letzte 30 Tage",
+    "date_range.horizon.past_90d": "Letzte 90 Tage",
+    "date_range.horizon.past_all": "Ganze Vergangenheit",
+    "date_range.horizon.any":      "Alles",
+    "date_range.horizon.custom":   "Anpassen",
+    "date_range.dialog.label":     "Zeitraum wählen",
+    "date_range.fan.past.label":   "Vergangenheit",
+    "date_range.fan.future.label": "Zukunft",
+    "date_range.center.label":     "Alles",
+    "date_range.custom.from":      "Von",
+    "date_range.custom.to":        "Bis",
+    "date_range.custom.apply":     "Anwenden",
+    "date_range.custom.cancel":    "Abbrechen",
+    "date_range.custom.invalid":            "Bis-Datum muss nach Von-Datum liegen.",
+    "date_range.custom.invalid_format":     "Datum nicht erkannt (Format JJJJ-MM-TT).",
+    "date_range.custom.invalid_missing":    "Bitte beide Datumsfelder ausfüllen.",
   },
 
   en: {
@@ -5657,11 +5690,18 @@ const translations: Record<Lang, Record<string, string>> = {
     "views.scope.my_subtree": "My subtree",
     "views.scope.explicit": "Specific projects",
     "views.scope.personal_only": "Personal only",
+    "views.horizon.next_1d": "Tomorrow",
     "views.horizon.next_7d": "Next 7 days",
+    "views.horizon.next_14d": "Next 14 days",
     "views.horizon.next_30d": "Next 30 days",
     "views.horizon.next_90d": "Next 90 days",
+    "views.horizon.next_all": "All future",
+    "views.horizon.past_1d": "Last day",
+    "views.horizon.past_7d": "Last 7 days",
+    "views.horizon.past_14d": "Last 14 days",
     "views.horizon.past_30d": "Last 30 days",
     "views.horizon.past_90d": "Last 90 days",
+    "views.horizon.past_all": "All past",
     "views.horizon.any": "Any",
     "views.horizon.all": "All-time",
     "views.horizon.custom": "Custom",
@@ -5744,16 +5784,9 @@ const translations: Record<Lang, Record<string, string>> = {
     "views.bar.label.density": "Density",
     "views.bar.label.sort": "Sort",
     "views.bar.common.all": "All",
-    "views.bar.time.next_7d": "7 days",
-    "views.bar.time.next_30d": "30 days",
-    "views.bar.time.next_90d": "90 days",
-    "views.bar.time.past_7d": "Past 7d",
-    "views.bar.time.past_30d": "Past 30 d.",
-    "views.bar.time.past_90d": "Past 90 d.",
-    "views.bar.time.any": "Any",
-    "views.bar.time.all": "All time",
-    "views.bar.time.custom": "Custom",
-    "views.bar.time.custom.coming_soon": "Custom date range arrives in a follow-up iteration.",
+    // views.bar.time.* keys retired in t-paliad-248 — see the DE block
+    // for context. The filter-bar time axis now mounts the symmetric
+    // date-range picker whose labels live under date_range.horizon.*.
     "views.bar.personal.on": "Mine only",
     "views.bar.approval_role.approver_eligible": "To approve",
     "views.bar.approval_role.self_requested": "My requests",
@@ -5980,6 +6013,35 @@ const translations: Record<Lang, Record<string, string>> = {
     "admin.rules.export.ok": "{n} audit rows exported.",
     "admin.rules.export.error": "Export failed.",
     "admin.rules.export.no_pending": "No pending audit rows to export.",
+
+    // Date-range picker (t-paliad-248). See DE block above for details.
+    "date_range.button.label": "Time range",
+    "date_range.button.label.custom_range": "From {from} to {to}",
+    "date_range.horizon.next_1d":  "Tomorrow",
+    "date_range.horizon.next_7d":  "Next 7 days",
+    "date_range.horizon.next_14d": "Next 14 days",
+    "date_range.horizon.next_30d": "Next 30 days",
+    "date_range.horizon.next_90d": "Next 90 days",
+    "date_range.horizon.next_all": "All future",
+    "date_range.horizon.past_1d":  "Last day",
+    "date_range.horizon.past_7d":  "Last 7 days",
+    "date_range.horizon.past_14d": "Last 14 days",
+    "date_range.horizon.past_30d": "Last 30 days",
+    "date_range.horizon.past_90d": "Last 90 days",
+    "date_range.horizon.past_all": "All past",
+    "date_range.horizon.any":      "All",
+    "date_range.horizon.custom":   "Customize",
+    "date_range.dialog.label":     "Choose time range",
+    "date_range.fan.past.label":   "Past",
+    "date_range.fan.future.label": "Future",
+    "date_range.center.label":     "All",
+    "date_range.custom.from":      "From",
+    "date_range.custom.to":        "To",
+    "date_range.custom.apply":     "Apply",
+    "date_range.custom.cancel":    "Cancel",
+    "date_range.custom.invalid":            "End date must be strictly after start date.",
+    "date_range.custom.invalid_format":     "Date not recognised (format YYYY-MM-DD).",
+    "date_range.custom.invalid_missing":    "Please fill in both date fields.",
   },
 };
 

frontend/src/client/projects-detail.ts

@@ -397,18 +397,26 @@ function applyVerlaufFilters(rows: ProjectEvent[]): ProjectEvent[] {
 // horizons that show up on the Verlauf bar. Forward-looking horizons
 // (next_*) are absent on this surface — the timePresets override hides
 // them — but the function tolerates them for forward-compatibility with
-// the SmartTimeline redesign.
+// the SmartTimeline redesign. Open-ended ranges (next_all / past_all)
+// leave the matching bound undefined; the upstream filter treats that
+// as "no narrowing in that direction".
 function horizonBounds(horizon: string): { from?: Date; to?: Date } {
   const now = new Date();
   const day = new Date(Date.UTC(now.getUTCFullYear(), now.getUTCMonth(), now.getUTCDate()));
   const offset = (days: number) => new Date(day.getTime() + days * 86400000);
   switch (horizon) {
+    case "past_1d":  return { from: offset(-1),  to: offset(1) };
     case "past_7d":  return { from: offset(-7),  to: offset(1) };
+    case "past_14d": return { from: offset(-14), to: offset(1) };
     case "past_30d": return { from: offset(-30), to: offset(1) };
     case "past_90d": return { from: offset(-90), to: offset(1) };
+    case "past_all": return {                    to: offset(1) };
+    case "next_1d":  return { from: day,         to: offset(1) };
     case "next_7d":  return { from: day,         to: offset(7) };
+    case "next_14d": return { from: day,         to: offset(14) };
     case "next_30d": return { from: day,         to: offset(30) };
     case "next_90d": return { from: day,         to: offset(90) };
+    case "next_all": return { from: day                       };
     default:         return {};
   }
 }

frontend/src/client/submission-draft.ts

@@ -605,6 +605,90 @@ function paintPreview(): void {
   const host = document.getElementById("submission-draft-preview");
   if (!host || !state.view) return;
   host.innerHTML = state.view.preview_html ?? "";
+  wireDraftVars(host);
+}
+
+// t-paliad-261 (B) — click a substituted variable in the preview to
+// jump to the matching sidebar input. Re-wires on every paintPreview
+// since the preview HTML is replaced wholesale. The server side wraps
+// each substituted placeholder (resolved OR missing marker) in
+// <span class="draft-var" data-var="<key>">…</span>; clicks here scroll
+// the corresponding input into view, focus + select, and flash the row.
+// If the key has no matching sidebar input (derived variables not
+// exposed in VARIABLE_GROUPS), the click is a silent no-op — the span
+// is still rendered so the user gets the visible hint that this is a
+// resolved variable.
+function wireDraftVars(previewHost: HTMLElement): void {
+  previewHost.querySelectorAll<HTMLElement>(".draft-var").forEach((el) => {
+    const key = el.dataset.var;
+    if (!key) return;
+    if (findVarInput(key)) {
+      el.classList.add("draft-var--has-input");
+      el.setAttribute("role", "button");
+      el.setAttribute("tabindex", "0");
+      el.setAttribute(
+        "aria-label",
+        (isEN() ? "Edit variable " : "Variable bearbeiten: ") + labelFor(key),
+      );
+    }
+    el.addEventListener("click", (ev) => onDraftVarClick(key, ev));
+    el.addEventListener("keydown", (ev) => {
+      if (ev.key === "Enter" || ev.key === " ") {
+        ev.preventDefault();
+        onDraftVarClick(key, ev);
+      }
+    });
+  });
+}
+
+function findVarInput(key: string): HTMLInputElement | null {
+  const host = document.getElementById("submission-draft-variables");
+  if (!host) return null;
+  return host.querySelector<HTMLInputElement>(
+    `.submission-draft-var-input[data-var="${cssEscape(key)}"]`,
+  );
+}
+
+function cssEscape(s: string): string {
+  // CSS.escape covers our placeholder keys ([A-Za-z][A-Za-z0-9_.]*) but
+  // older browsers may lack it; defensive fallback escapes characters
+  // CSS treats as special. Placeholder keys never carry whitespace or
+  // quotes so escaping is straightforward.
+  if (typeof CSS !== "undefined" && typeof CSS.escape === "function") {
+    return CSS.escape(s);
+  }
+  return s.replace(/([!"#$%&'()*+,./:;<=>?@[\\\]^`{|}~])/g, "\\$1");
+}
+
+function onDraftVarClick(key: string, ev: Event): void {
+  const input = findVarInput(key);
+  if (!input) return;
+  ev.preventDefault();
+  ev.stopPropagation();
+  // Smooth-scroll the input into view, then focus on the next tick so
+  // the scroll animation has started and the focus call doesn't trigger
+  // a second jarring jump.
+  input.scrollIntoView({ behavior: "smooth", block: "center" });
+  window.setTimeout(() => {
+    input.focus();
+    try {
+      input.select();
+    } catch {
+      /* select() throws on number/email inputs; safe to ignore */
+    }
+  }, 50);
+  flashVarRow(input);
+}
+
+function flashVarRow(input: HTMLElement): void {
+  const row = input.closest<HTMLElement>(".submission-draft-var-row");
+  if (!row) return;
+  row.classList.remove("submission-draft-var-row--flash");
+  // Force reflow so removing+re-adding the class restarts the animation
+  // even on rapid successive clicks.
+  void row.offsetWidth;
+  row.classList.add("submission-draft-var-row--flash");
+  window.setTimeout(() => row.classList.remove("submission-draft-var-row--flash"), 1200);
 }
 
 // ─────────────────────────────────────────────────────────────────────
@@ -643,11 +727,18 @@ async function flushAutosave(): Promise<void> {
   if (!state.pendingOverrides) return;
   const payload = { variables: state.pendingOverrides };
   state.pendingOverrides = null;
+  // t-paliad-261 (A) — paintVariables() below replaces every input in
+  // the sidebar via innerHTML, which blows away the active-element
+  // reference. Capture the focused input's key + selection range before
+  // the repaint and restore on the new element after, so the user can
+  // keep typing without clicking back into the field.
+  const focusSnap = captureVarFocus();
   try {
     const view = await patchDraft(payload);
     state.view = view;
     paintVariables();
     paintPreview();
+    restoreVarFocus(focusSnap);
     setSaveStatus(isEN() ? "Saved" : "Gespeichert");
   } catch (err) {
     if ((err as Error).name === "AbortError") return;
@@ -656,6 +747,64 @@ async function flushAutosave(): Promise<void> {
   }
 }
 
+// captureVarFocus / restoreVarFocus — focus-preservation across the
+// paintVariables() innerHTML-replace cycle (t-paliad-261 part A).
+// Tracks selection start/end/direction so the cursor lands exactly
+// where it was before the repaint, including any active selection
+// range. Handles both <input> and <textarea> via the shared
+// HTMLInputElement|HTMLTextAreaElement contract for selectionStart /
+// selectionEnd / selectionDirection / setSelectionRange.
+
+interface VarFocusSnapshot {
+  key: string;
+  start: number | null;
+  end: number | null;
+  dir: "forward" | "backward" | "none";
+}
+
+type SelectableEl = HTMLInputElement | HTMLTextAreaElement;
+
+function isVarField(el: Element | null): el is SelectableEl {
+  if (!el) return false;
+  if (!(el instanceof HTMLInputElement) && !(el instanceof HTMLTextAreaElement)) {
+    return false;
+  }
+  return el.classList.contains("submission-draft-var-input");
+}
+
+function captureVarFocus(): VarFocusSnapshot | null {
+  const active = document.activeElement;
+  if (!isVarField(active)) return null;
+  const key = active.dataset.var;
+  if (!key) return null;
+  return {
+    key,
+    start: active.selectionStart,
+    end: active.selectionEnd,
+    dir: (active.selectionDirection as "forward" | "backward" | "none" | null) ?? "forward",
+  };
+}
+
+function restoreVarFocus(snap: VarFocusSnapshot | null): void {
+  if (!snap) return;
+  const host = document.getElementById("submission-draft-variables");
+  if (!host) return;
+  const next = host.querySelector<SelectableEl>(
+    `.submission-draft-var-input[data-var="${cssEscape(snap.key)}"]`,
+  );
+  if (!next) return;
+  next.focus();
+  if (snap.start !== null && snap.end !== null) {
+    try {
+      next.setSelectionRange(snap.start, snap.end, snap.dir);
+    } catch {
+      /* setSelectionRange throws on inputs whose type doesn't support
+         selection ranges (number, email, etc.); safe to ignore — the
+         focus() call above is enough for those. */
+    }
+  }
+}
+
 async function renameDraft(newName: string): Promise<void> {
   setSaveStatus(isEN() ? "Saving…" : "Speichert…");
   try {

frontend/src/client/views/types.ts

@@ -19,8 +19,8 @@ export interface ScopeSpec {
 }
 
 export type TimeHorizon =
-  | "next_7d" | "next_30d" | "next_90d"
-  | "past_7d" | "past_30d" | "past_90d"
+  | "next_1d" | "next_7d" | "next_14d" | "next_30d" | "next_90d" | "next_all"
+  | "past_1d" | "past_7d" | "past_14d" | "past_30d" | "past_90d" | "past_all"
   | "any" | "all" | "custom";
 
 export type TimeField = "auto" | "created_at";

frontend/src/i18n-keys.ts

@@ -1137,6 +1137,33 @@ export type I18nKey =
   | "dashboard.urgency.urgent"
   | "dashboard.when.today"
   | "dashboard.when.tomorrow"
+  | "date_range.button.label"
+  | "date_range.button.label.custom_range"
+  | "date_range.center.label"
+  | "date_range.custom.apply"
+  | "date_range.custom.cancel"
+  | "date_range.custom.from"
+  | "date_range.custom.invalid"
+  | "date_range.custom.invalid_format"
+  | "date_range.custom.invalid_missing"
+  | "date_range.custom.to"
+  | "date_range.dialog.label"
+  | "date_range.fan.future.label"
+  | "date_range.fan.past.label"
+  | "date_range.horizon.any"
+  | "date_range.horizon.custom"
+  | "date_range.horizon.next_14d"
+  | "date_range.horizon.next_1d"
+  | "date_range.horizon.next_30d"
+  | "date_range.horizon.next_7d"
+  | "date_range.horizon.next_90d"
+  | "date_range.horizon.next_all"
+  | "date_range.horizon.past_14d"
+  | "date_range.horizon.past_1d"
+  | "date_range.horizon.past_30d"
+  | "date_range.horizon.past_7d"
+  | "date_range.horizon.past_90d"
+  | "date_range.horizon.past_all"
   | "deadlines.action.reopen"
   | "deadlines.adjusted"
   | "deadlines.adjusted.holiday"
@@ -2714,16 +2741,6 @@ export type I18nKey =
   | "views.bar.shape.list"
   | "views.bar.sort.date_asc"
   | "views.bar.sort.date_desc"
-  | "views.bar.time.all"
-  | "views.bar.time.any"
-  | "views.bar.time.custom"
-  | "views.bar.time.custom.coming_soon"
-  | "views.bar.time.next_30d"
-  | "views.bar.time.next_7d"
-  | "views.bar.time.next_90d"
-  | "views.bar.time.past_30d"
-  | "views.bar.time.past_7d"
-  | "views.bar.time.past_90d"
   | "views.bar.timeline_status.court_set"
   | "views.bar.timeline_status.done"
   | "views.bar.timeline_status.macro.future"
@@ -2796,11 +2813,18 @@ export type I18nKey =
   | "views.horizon.all"
   | "views.horizon.any"
   | "views.horizon.custom"
+  | "views.horizon.next_14d"
+  | "views.horizon.next_1d"
   | "views.horizon.next_30d"
   | "views.horizon.next_7d"
   | "views.horizon.next_90d"
+  | "views.horizon.next_all"
+  | "views.horizon.past_14d"
+  | "views.horizon.past_1d"
   | "views.horizon.past_30d"
+  | "views.horizon.past_7d"
   | "views.horizon.past_90d"
+  | "views.horizon.past_all"
   | "views.kind.appointment"
   | "views.kind.approval_request"
   | "views.kind.deadline"

frontend/src/styles/global.css

@@ -5880,6 +5880,66 @@ dialog.modal::backdrop {
     font-style: italic;
 }
 
+/* t-paliad-261 (B) — substituted variables in the preview are wrapped
+   in <span class="draft-var" data-var="…"> by the Go HTML renderer.
+   .draft-var by itself shows a subtle dotted underline so the lawyer
+   can SEE which text was filled in from a variable. .draft-var--has-input
+   (added client-side when a matching sidebar input exists) layers on
+   the clickable affordance — pointer cursor + brighter hover background.
+   Non-matching draft-vars (derived variables not exposed in the
+   sidebar) stay visually distinct but non-interactive. */
+.draft-var {
+    background-color: rgba(198, 244, 28, 0.12);
+    border-radius: 2px;
+    padding: 0 2px;
+    box-decoration-break: clone;
+    -webkit-box-decoration-break: clone;
+    transition: background-color 0.15s ease;
+}
+
+.draft-var--has-input {
+    cursor: pointer;
+}
+
+.draft-var--has-input:hover,
+.draft-var--has-input:focus-visible {
+    background-color: rgba(198, 244, 28, 0.45);
+    outline: none;
+}
+
+/* t-paliad-261 (B) — brief lime flash on the sidebar row after a
+   click-jump from the preview, so the user's eye lands on the right
+   input even after the smooth-scroll motion. Animation restarts on
+   each click via class-remove + reflow + class-add. */
+.submission-draft-var-row--flash {
+    animation: paliad-var-flash 1.2s ease;
+    border-radius: 4px;
+}
+
+@keyframes paliad-var-flash {
+    0% {
+        background-color: rgba(198, 244, 28, 0.55);
+        box-shadow: 0 0 0 4px rgba(198, 244, 28, 0.25);
+    }
+    100% {
+        background-color: transparent;
+        box-shadow: 0 0 0 4px transparent;
+    }
+}
+
+@media (prefers-reduced-motion: reduce) {
+    .submission-draft-var-row--flash {
+        animation: paliad-var-flash-still 1.2s steps(1, end);
+    }
+    @keyframes paliad-var-flash-still {
+        0%, 99% { background-color: rgba(198, 244, 28, 0.55); }
+        100% { background-color: transparent; }
+    }
+    .draft-var {
+        transition: none;
+    }
+}
+
 .submission-edit-btn {
     margin-right: 0.4rem;
 }
@@ -17465,3 +17525,258 @@ dialog.quick-add-sheet::backdrop {
   white-space: pre;
   margin: 0;
 }
+
+/* Date-range picker (t-paliad-248) ------------------------------------
+   Symmetric past/future chip fan around an ALLES centre, in a popover
+   anchored under a closed-state trigger button. Reuses .agenda-chip /
+   .agenda-chip-active for the fan chips so the active state lights up
+   with the same lime accent as every other paliad filter-chip. The
+   popover scaffold reuses .multi-panel for shadow + border + z-index,
+   and .multi-anchor for the top:100% / left:0 positioning anchor. */
+
+.date-range-anchor {
+  position: relative;
+  display: inline-flex;
+  align-items: center;
+}
+
+.date-range-trigger {
+  appearance: none;
+  display: inline-flex;
+  align-items: center;
+  gap: 0.4rem;
+  background: var(--color-surface-muted);
+  border: 1px solid var(--color-border);
+  border-radius: 999px;
+  padding: 0.35rem 0.85rem;
+  font-size: 0.85rem;
+  font-weight: 500;
+  color: var(--color-text);
+  cursor: pointer;
+  transition: background 0.15s, border-color 0.15s, color 0.15s;
+}
+.date-range-trigger:hover {
+  background: var(--color-overlay-subtle);
+  border-color: var(--color-accent-light);
+}
+.date-range-trigger:focus-visible {
+  outline: 2px solid var(--color-accent);
+  outline-offset: 2px;
+}
+.date-range-trigger[aria-expanded="true"] {
+  background: var(--color-bg-lime-tint);
+  border-color: var(--color-accent);
+}
+
+.date-range-trigger-dot {
+  display: inline-block;
+  width: 0.5rem;
+  height: 0.5rem;
+  border-radius: 50%;
+  background: var(--color-accent);
+  flex-shrink: 0;
+}
+
+.date-range-trigger-label {
+  white-space: nowrap;
+}
+
+.date-range-trigger-chev {
+  font-size: 0.75rem;
+  color: var(--color-text-muted, #71717a);
+  margin-left: 0.1rem;
+}
+
+.date-range-panel {
+  /* Inherits .multi-panel positioning + border + shadow. Widen it so
+     the symmetric fan + the custom editor have room to breathe. */
+  width: 32rem;
+  max-width: calc(100vw - 1rem);
+  top: 100%;
+  left: 0;
+  padding: 0.75rem;
+  gap: 0.75rem;
+}
+
+.date-range-row {
+  display: flex;
+  flex-wrap: wrap;
+  gap: 0.5rem;
+  align-items: stretch;
+}
+
+.date-range-fan {
+  display: flex;
+  flex-wrap: wrap;
+  gap: 0.3rem;
+  align-content: flex-start;
+  flex: 1 1 12rem;
+  min-width: 0;
+}
+
+.date-range-fan--past {
+  /* Past fan: outermost chip (Ganze Vergangenheit) leftmost. */
+  justify-content: flex-end;
+}
+
+.date-range-fan--next {
+  /* Future fan: innermost chip (Morgen / next_1d) leftmost. */
+  justify-content: flex-start;
+}
+
+.date-range-center {
+  display: flex;
+  align-items: center;
+  justify-content: center;
+  flex: 0 0 auto;
+  padding: 0 0.25rem;
+}
+
+.date-range-center-btn {
+  appearance: none;
+  display: inline-flex;
+  flex-direction: column;
+  align-items: center;
+  justify-content: center;
+  gap: 0.1rem;
+  background: var(--color-surface-muted);
+  border: 1px solid var(--color-border);
+  border-radius: 0.6rem;
+  min-width: 4.5rem;
+  padding: 0.55rem 0.75rem;
+  font-size: 0.75rem;
+  font-weight: 600;
+  color: var(--color-text);
+  cursor: pointer;
+  transition: background 0.15s, border-color 0.15s, color 0.15s;
+}
+.date-range-center-btn:hover {
+  background: var(--color-overlay-subtle);
+  border-color: var(--color-accent-light);
+}
+.date-range-center-btn:focus-visible {
+  outline: 2px solid var(--color-accent);
+  outline-offset: 2px;
+}
+.date-range-center-btn--active {
+  background: var(--color-accent);
+  border-color: var(--color-accent);
+  color: var(--color-accent-dark);
+}
+
+.date-range-center-glyph {
+  font-size: 1.4rem;
+  line-height: 1;
+}
+
+.date-range-center-label {
+  font-size: 0.7rem;
+  text-transform: uppercase;
+  letter-spacing: 0.04em;
+}
+
+.date-range-chip {
+  /* .agenda-chip provides bg/border/radius/typography; this modifier
+     only tightens horizontal padding so more chips fit per row. */
+  padding: 0.3rem 0.65rem;
+  font-size: 0.8rem;
+}
+
+.date-range-chip--custom {
+  margin-top: 0.25rem;
+}
+
+.date-range-custom {
+  border-top: 1px solid var(--color-border);
+  padding-top: 0.6rem;
+  display: flex;
+  flex-direction: column;
+  gap: 0.5rem;
+}
+
+.date-range-custom-editor {
+  display: flex;
+  flex-wrap: wrap;
+  align-items: end;
+  gap: 0.5rem;
+}
+
+.date-range-custom-field {
+  display: flex;
+  flex-direction: column;
+  gap: 0.2rem;
+  font-size: 0.8rem;
+  color: var(--color-text);
+}
+
+.date-range-custom-label {
+  font-weight: 500;
+  color: var(--color-text-muted, #71717a);
+}
+
+.date-range-custom-from,
+.date-range-custom-to {
+  appearance: none;
+  background: var(--color-bg);
+  border: 1px solid var(--color-border);
+  border-radius: 0.375rem;
+  padding: 0.3rem 0.4rem;
+  font-size: 0.85rem;
+  color: var(--color-text);
+  color-scheme: light dark;
+}
+.date-range-custom-from:focus-visible,
+.date-range-custom-to:focus-visible {
+  outline: 2px solid var(--color-accent);
+  outline-offset: 1px;
+}
+
+.date-range-custom-apply,
+.date-range-custom-cancel {
+  appearance: none;
+  background: var(--color-surface-muted);
+  border: 1px solid var(--color-border);
+  border-radius: 999px;
+  padding: 0.35rem 0.85rem;
+  font-size: 0.8rem;
+  font-weight: 500;
+  color: var(--color-text);
+  cursor: pointer;
+  transition: background 0.15s, border-color 0.15s, color 0.15s;
+}
+.date-range-custom-apply {
+  background: var(--color-accent);
+  border-color: var(--color-accent);
+  color: var(--color-accent-dark);
+}
+.date-range-custom-apply:disabled {
+  opacity: 0.45;
+  cursor: not-allowed;
+}
+.date-range-custom-apply:hover:not(:disabled) {
+  background: var(--color-accent-light);
+}
+.date-range-custom-cancel:hover {
+  background: var(--color-overlay-subtle);
+}
+
+.date-range-custom-error {
+  width: 100%;
+  font-size: 0.75rem;
+  color: var(--status-red-fg, #b91c1c);
+}
+
+/* Mobile: stack past / centre / next vertically so each fan gets
+   the full popover width. */
+@media (max-width: 540px) {
+  .date-range-panel {
+    width: calc(100vw - 1rem);
+  }
+  .date-range-row {
+    flex-direction: column;
+  }
+  .date-range-fan--past,
+  .date-range-fan--next {
+    justify-content: flex-start;
+  }
+}

internal/services/filter_spec.go

@@ -114,12 +114,18 @@ type TimeSpec struct {
 type TimeHorizon string
 
 const (
+	HorizonNext1d  TimeHorizon = "next_1d"
 	HorizonNext7d  TimeHorizon = "next_7d"
+	HorizonNext14d TimeHorizon = "next_14d"
 	HorizonNext30d TimeHorizon = "next_30d"
 	HorizonNext90d TimeHorizon = "next_90d"
+	HorizonNextAll TimeHorizon = "next_all"
+	HorizonPast1d  TimeHorizon = "past_1d"
 	HorizonPast7d  TimeHorizon = "past_7d"
+	HorizonPast14d TimeHorizon = "past_14d"
 	HorizonPast30d TimeHorizon = "past_30d"
 	HorizonPast90d TimeHorizon = "past_90d"
+	HorizonPastAll TimeHorizon = "past_all"
 	HorizonAny     TimeHorizon = "any"
 	HorizonAll     TimeHorizon = "all"
 	HorizonCustom  TimeHorizon = "custom"
@@ -279,8 +285,9 @@ func (s *ScopeSpec) validate() error {
 
 func (t *TimeSpec) validate(scope ScopeSpec) error {
 	switch t.Horizon {
-	case HorizonNext7d, HorizonNext30d, HorizonNext90d,
-		HorizonPast7d, HorizonPast30d, HorizonPast90d, HorizonAny:
+	case HorizonNext1d, HorizonNext7d, HorizonNext14d, HorizonNext30d, HorizonNext90d, HorizonNextAll,
+		HorizonPast1d, HorizonPast7d, HorizonPast14d, HorizonPast30d, HorizonPast90d, HorizonPastAll,
+		HorizonAny:
 		// fine
 	case HorizonAll:
 		// Q26: reject "all" unless scope.projects is explicit. Performance

internal/services/filter_spec_test.go

@@ -160,6 +160,23 @@ func TestFilterSpec_HorizonCustomAcceptsValidRange(t *testing.T) {
 	}
 }
 
+// t-paliad-248: the symmetric date-range picker adds six new horizons —
+// 1d/14d/all on each side. They must round-trip through validate without
+// requiring scope.explicit (unlike HorizonAll which is a bidirectional-
+// unbounded substrate scan and stays gated to ScopeExplicit per Q26).
+func TestFilterSpec_NewSymmetricHorizonsValidate(t *testing.T) {
+	for _, h := range []TimeHorizon{
+		HorizonNext1d, HorizonNext14d, HorizonNextAll,
+		HorizonPast1d, HorizonPast14d, HorizonPastAll,
+	} {
+		s := validBaseSpec()
+		s.Time.Horizon = h
+		if err := s.Validate(); err != nil {
+			t.Fatalf("horizon %q must validate against a default scope: %v", h, err)
+		}
+	}
+}
+
 func TestFilterSpec_PredicatesRequireSourceSelected(t *testing.T) {
 	s := validBaseSpec()
 	s.Sources = []DataSource{SourceDeadline}

internal/services/submission_merge.go

@@ -47,6 +47,33 @@ type PlaceholderMap map[string]string
 // "[KEIN WERT: <key>]" / "[NO VALUE: <key>]" depending on lang.
 type MissingPlaceholderFn func(key string) string
 
+// valueWrapperFn wraps a substituted value with a marker the HTML
+// preview emitter can recognise — used by RenderHTML to turn each
+// substituted value into a clickable <span class="draft-var" …>
+// (t-paliad-261, click-variable-in-preview → jump-to-field). nil means
+// no wrapping; the .docx export path uses nil so its output is
+// byte-identical to the wrapper-free build. The wrapper is invoked for
+// both resolved values and missing-marker text so clicking a missing
+// placeholder still jumps to the corresponding sidebar input.
+type valueWrapperFn func(key, value string) string
+
+// Private-Use-Area sentinels for the HTML preview wrap. PUA characters
+// are valid in XML 1.0 content, never appear in legitimate template
+// text, pass unchanged through xmlEncode/xmlDecode/htmlEscape, and are
+// stripped by emitTextWithDraftVars when the preview HTML is assembled.
+const (
+	previewVarBegin = ""
+	previewVarMid   = ""
+	previewVarEnd   = ""
+)
+
+// htmlPreviewWrapper wraps a substituted value with the PUA sentinels
+// emitTextWithDraftVars recognises. Used only by RenderHTML; the .docx
+// Render path uses nil so its output is identical to the pre-261 build.
+func htmlPreviewWrapper(key, value string) string {
+	return previewVarBegin + key + previewVarMid + value + previewVarEnd
+}
+
 // DefaultMissingMarker returns the standard missing-value marker for
 // the given UI language.
 func DefaultMissingMarker(lang string) MissingPlaceholderFn {
@@ -107,7 +134,7 @@ func (r *SubmissionRenderer) Render(templateBytes []byte, vars PlaceholderMap, m
 			return nil, fmt.Errorf("submission render: read %s: %w", entry.Name, err)
 		}
 		if isWordXMLEntry(entry.Name) {
-			body = substituteInDocumentXML(body, vars, missing)
+			body = substituteInDocumentXML(body, vars, missing, nil)
 		}
 		w, err := zw.CreateHeader(&zip.FileHeader{
 			Name:     entry.Name,
@@ -165,7 +192,7 @@ func (r *SubmissionRenderer) RenderHTML(templateBytes []byte, vars PlaceholderMa
 	if docXML == nil {
 		return "", fmt.Errorf("submission render html: word/document.xml missing")
 	}
-	merged := substituteInDocumentXML(docXML, vars, missing)
+	merged := substituteInDocumentXML(docXML, vars, missing, htmlPreviewWrapper)
 	return docXMLToHTML(merged), nil
 }
 
@@ -214,12 +241,12 @@ func readMergeZipEntry(f *zip.File) ([]byte, error) {
 //     paragraph, run the replacement on the merged text, and rewrite
 //     the paragraph's runs as a single <w:r><w:t>…</w:t></w:r> using
 //     the formatting properties of the first run.
-func substituteInDocumentXML(body []byte, vars PlaceholderMap, missing MissingPlaceholderFn) []byte {
-	replaced := substituteInTextNodes(body, vars, missing)
+func substituteInDocumentXML(body []byte, vars PlaceholderMap, missing MissingPlaceholderFn, wrap valueWrapperFn) []byte {
+	replaced := substituteInTextNodes(body, vars, missing, wrap)
 	if !needsCrossRunMerge(replaced) {
 		return replaced
 	}
-	return substituteAcrossRuns(replaced, vars, missing)
+	return substituteAcrossRuns(replaced, vars, missing, wrap)
 }
 
 // wTextNodeRegex matches one <w:t …>contents</w:t> element, capturing
@@ -229,12 +256,12 @@ var wTextNodeRegex = regexp.MustCompile(`<w:t(\s[^>]*)?>([^<]*)</w:t>`)
 // substituteInTextNodes runs the placeholder replacement inside each
 // <w:t> text node independently. Format-preserving for single-run
 // placeholders.
-func substituteInTextNodes(body []byte, vars PlaceholderMap, missing MissingPlaceholderFn) []byte {
+func substituteInTextNodes(body []byte, vars PlaceholderMap, missing MissingPlaceholderFn, wrap valueWrapperFn) []byte {
 	return wTextNodeRegex.ReplaceAllFunc(body, func(match []byte) []byte {
 		sub := wTextNodeRegex.FindSubmatch(match)
 		attrs := string(sub[1])
 		contents := xmlDecode(string(sub[2]))
-		replaced := replacePlaceholders(contents, vars, missing)
+		replaced := replacePlaceholders(contents, vars, missing, wrap)
 		if replaced == contents {
 			return match
 		}
@@ -270,7 +297,7 @@ var wParagraphPropsRegex = regexp.MustCompile(`(?s)<w:pPr>.*?</w:pPr>`)
 
 // substituteAcrossRuns is pass 2: concatenate every text node in a
 // fragmented-placeholder paragraph, run replacement, rewrite as one run.
-func substituteAcrossRuns(body []byte, vars PlaceholderMap, missing MissingPlaceholderFn) []byte {
+func substituteAcrossRuns(body []byte, vars PlaceholderMap, missing MissingPlaceholderFn, wrap valueWrapperFn) []byte {
 	return wParagraphRegex.ReplaceAllFunc(body, func(para []byte) []byte {
 		textNodes := wTextNodeRegex.FindAllSubmatch(para, -1)
 		if len(textNodes) == 0 {
@@ -284,7 +311,7 @@ func substituteAcrossRuns(body []byte, vars PlaceholderMap, missing MissingPlace
 		if !strings.Contains(original, "{{") {
 			return para
 		}
-		replaced := replacePlaceholders(original, vars, missing)
+		replaced := replacePlaceholders(original, vars, missing, wrap)
 		if replaced == original {
 			return para
 		}
@@ -307,18 +334,29 @@ func substituteAcrossRuns(body []byte, vars PlaceholderMap, missing MissingPlace
 }
 
 // replacePlaceholders performs the actual substitution on a plain
-// string. Unbound placeholders render the missing marker.
-func replacePlaceholders(s string, vars PlaceholderMap, missing MissingPlaceholderFn) string {
+// string. Unbound placeholders render the missing marker. When wrap is
+// non-nil, both the resolved value AND the missing-marker text are
+// passed through wrap(key, value) — the HTML preview path uses this to
+// emit clickable spans around every substituted placeholder, including
+// missing ones (clicking a missing marker jumps to the corresponding
+// sidebar input).
+func replacePlaceholders(s string, vars PlaceholderMap, missing MissingPlaceholderFn, wrap valueWrapperFn) string {
 	return placeholderRegex.ReplaceAllStringFunc(s, func(match string) string {
 		sub := placeholderRegex.FindStringSubmatch(match)
 		if len(sub) < 2 {
 			return match
 		}
 		key := sub[1]
-		if value, ok := vars[key]; ok {
-			return value
+		var value string
+		if v, ok := vars[key]; ok {
+			value = v
+		} else {
+			value = missing(key)
 		}
-		return missing(key)
+		if wrap != nil {
+			return wrap(key, value)
+		}
+		return value
 	})
 }
 
@@ -401,7 +439,7 @@ func paragraphToHTML(para []byte) string {
 		if italic {
 			out.WriteString("<em>")
 		}
-		out.WriteString(htmlEscape(text))
+		out.WriteString(emitTextWithDraftVars(text))
 		if italic {
 			out.WriteString("</em>")
 		}
@@ -412,6 +450,52 @@ func paragraphToHTML(para []byte) string {
 	return out.String()
 }
 
+// emitTextWithDraftVars HTML-escapes run text while converting any
+// preview-only sentinels emitted by htmlPreviewWrapper into
+// <span class="draft-var" data-var="<key>">…</span>. The key is
+// restricted to [A-Za-z][A-Za-z0-9_.]* by placeholderRegex, so no
+// attribute-escaping is needed on the key; the value is HTML-escaped
+// normally. Sentinel-free text (the Render path output, or template
+// text outside placeholders) is passed straight through htmlEscape, so
+// callers that never invoked wrap see byte-identical HTML.
+//
+// t-paliad-261: makes substituted variables clickable in the preview
+// pane so the user can jump to the matching input in the sidebar.
+func emitTextWithDraftVars(text string) string {
+	if !strings.Contains(text, previewVarBegin) {
+		return htmlEscape(text)
+	}
+	var out strings.Builder
+	rest := text
+	for {
+		i := strings.Index(rest, previewVarBegin)
+		if i < 0 {
+			out.WriteString(htmlEscape(rest))
+			return out.String()
+		}
+		out.WriteString(htmlEscape(rest[:i]))
+		body := rest[i+len(previewVarBegin):]
+		mid := strings.Index(body, previewVarMid)
+		end := strings.Index(body, previewVarEnd)
+		if mid < 0 || end < 0 || mid > end {
+			// Malformed sentinel — emit the marker as plain escaped
+			// text and continue past it so the rest of the run still
+			// renders.
+			out.WriteString(htmlEscape(previewVarBegin))
+			rest = body
+			continue
+		}
+		key := body[:mid]
+		value := body[mid+len(previewVarMid) : end]
+		out.WriteString(`<span class="draft-var" data-var="`)
+		out.WriteString(key)
+		out.WriteString(`">`)
+		out.WriteString(htmlEscape(value))
+		out.WriteString(`</span>`)
+		rest = body[end+len(previewVarEnd):]
+	}
+}
+
 // extractRunText concatenates every <w:t> inside a run, XML-decoding
 // the content as it goes.
 func extractRunText(run []byte) string {

internal/services/submission_merge_test.go

@@ -265,7 +265,9 @@ func TestPatentNumberUPC(t *testing.T) {
 
 // TestRenderHTML_ExtractsParagraphsAndFormatting verifies the preview
 // HTML emitter walks <w:p> / <w:r> / <w:t> correctly and carries
-// bold/italic through to <strong>/<em>.
+// bold/italic through to <strong>/<em>. Substituted placeholders are
+// wrapped in <span class="draft-var" data-var="…"> so the client can
+// make them clickable (t-paliad-261).
 func TestRenderHTML_ExtractsParagraphsAndFormatting(t *testing.T) {
 	doc := `<w:document><w:body>` +
 		`<w:p><w:r><w:t>Hello {{firm.name}}</w:t></w:r></w:p>` +
@@ -278,8 +280,8 @@ func TestRenderHTML_ExtractsParagraphsAndFormatting(t *testing.T) {
 	if err != nil {
 		t.Fatalf("render html: %v", err)
 	}
-	if !strings.Contains(html, "<p>Hello HLC</p>") {
-		t.Errorf("expected merged paragraph, got %q", html)
+	if !strings.Contains(html, `<p>Hello <span class="draft-var" data-var="firm.name">HLC</span></p>`) {
+		t.Errorf("expected merged paragraph with draft-var span, got %q", html)
 	}
 	if !strings.Contains(html, "<strong>Bold line</strong>") {
 		t.Errorf("expected bold span, got %q", html)
@@ -290,7 +292,8 @@ func TestRenderHTML_ExtractsParagraphsAndFormatting(t *testing.T) {
 }
 
 // TestRenderHTML_EscapesContent confirms the preview emitter HTML-escapes
-// special characters in placeholder values.
+// special characters in placeholder values even inside the draft-var
+// span wrapper.
 func TestRenderHTML_EscapesContent(t *testing.T) {
 	doc := `<w:document><w:body><w:p><w:r><w:t>{{user.display_name}}</w:t></w:r></w:p></w:body></w:document>`
 	tmpl := minimalMergeDOCX(t, doc)
@@ -301,7 +304,50 @@ func TestRenderHTML_EscapesContent(t *testing.T) {
 	if err != nil {
 		t.Fatalf("render html: %v", err)
 	}
-	if !strings.Contains(html, "M&amp;S &lt;Inc&gt; &quot;X&quot;") {
-		t.Errorf("expected escaped value in HTML, got %q", html)
+	want := `<span class="draft-var" data-var="user.display_name">M&amp;S &lt;Inc&gt; &quot;X&quot;</span>`
+	if !strings.Contains(html, want) {
+		t.Errorf("expected escaped value inside draft-var span, got %q", html)
+	}
+}
+
+// TestRenderHTML_WrapsMissingMarker confirms that an unbound placeholder
+// is still rendered as a clickable draft-var span so the user can click
+// the [KEIN WERT: …] marker in the preview and jump to the field.
+func TestRenderHTML_WrapsMissingMarker(t *testing.T) {
+	doc := `<w:document><w:body><w:p><w:r><w:t>{{project.case_number}}</w:t></w:r></w:p></w:body></w:document>`
+	tmpl := minimalMergeDOCX(t, doc)
+	r := NewSubmissionRenderer()
+	html, err := r.RenderHTML(tmpl, PlaceholderMap{}, nil)
+	if err != nil {
+		t.Fatalf("render html: %v", err)
+	}
+	want := `<span class="draft-var" data-var="project.case_number">[KEIN WERT: project.case_number]</span>`
+	if !strings.Contains(html, want) {
+		t.Errorf("expected missing marker wrapped in draft-var span, got %q", html)
+	}
+}
+
+// TestRender_DocxOutputUnchangedByPreviewWrap asserts the hard rule from
+// t-paliad-261: the .docx export path must NOT carry the preview-only
+// draft-var sentinels or any draft-var span markup. Renders the same
+// template through Render (.docx) and asserts the merged document.xml
+// has only the resolved value, not a wrapped one.
+func TestRender_DocxOutputUnchangedByPreviewWrap(t *testing.T) {
+	doc := `<w:document><w:body><w:p><w:r><w:t>{{firm.name}}</w:t></w:r></w:p></w:body></w:document>`
+	tmpl := minimalMergeDOCX(t, doc)
+	r := NewSubmissionRenderer()
+	out, err := r.Render(tmpl, PlaceholderMap{"firm.name": "HLC"}, nil)
+	if err != nil {
+		t.Fatalf("render docx: %v", err)
+	}
+	body := readMergeDocumentXML(t, out)
+	if !strings.Contains(body, `<w:t>HLC</w:t>`) {
+		t.Errorf("expected raw resolved value in .docx, got %q", body)
+	}
+	// PUA sentinels and any span markup must NOT appear in the .docx.
+	for _, forbidden := range []string{"draft-var", "data-var", previewVarBegin, previewVarMid, previewVarEnd} {
+		if strings.Contains(body, forbidden) {
+			t.Errorf("docx output unexpectedly contains %q: %q", forbidden, body)
+		}
 	}
 }

internal/services/view_service.go

@@ -156,11 +156,20 @@ type viewSpecBounds struct {
 func computeViewSpecBounds(now time.Time, ts TimeSpec) viewSpecBounds {
 	now = now.UTC()
 	day := time.Date(now.Year(), now.Month(), now.Day(), 0, 0, 0, 0, time.UTC)
+	tomorrow := day.AddDate(0, 0, 1)
 	switch ts.Horizon {
+	case HorizonNext1d:
+		from := day
+		to := day.AddDate(0, 0, 1)
+		return viewSpecBounds{from: &from, to: &to}
 	case HorizonNext7d:
 		from := day
 		to := day.AddDate(0, 0, 7)
 		return viewSpecBounds{from: &from, to: &to}
+	case HorizonNext14d:
+		from := day
+		to := day.AddDate(0, 0, 14)
+		return viewSpecBounds{from: &from, to: &to}
 	case HorizonNext30d:
 		from := day
 		to := day.AddDate(0, 0, 30)
@@ -169,18 +178,30 @@ func computeViewSpecBounds(now time.Time, ts TimeSpec) viewSpecBounds {
 		from := day
 		to := day.AddDate(0, 0, 90)
 		return viewSpecBounds{from: &from, to: &to}
+	case HorizonNextAll:
+		// One-sided unbounded — from today onwards, no upper bound.
+		// Distinct from HorizonAll (bidirectional unbounded) and
+		// HorizonAny (no time filter at all).
+		from := day
+		return viewSpecBounds{from: &from}
+	case HorizonPast1d:
+		from := day.AddDate(0, 0, -1)
+		return viewSpecBounds{from: &from, to: &tomorrow}
 	case HorizonPast7d:
 		from := day.AddDate(0, 0, -7)
-		to := day.AddDate(0, 0, 1)
-		return viewSpecBounds{from: &from, to: &to}
+		return viewSpecBounds{from: &from, to: &tomorrow}
+	case HorizonPast14d:
+		from := day.AddDate(0, 0, -14)
+		return viewSpecBounds{from: &from, to: &tomorrow}
 	case HorizonPast30d:
 		from := day.AddDate(0, 0, -30)
-		to := day.AddDate(0, 0, 1)
-		return viewSpecBounds{from: &from, to: &to}
+		return viewSpecBounds{from: &from, to: &tomorrow}
 	case HorizonPast90d:
 		from := day.AddDate(0, 0, -90)
-		to := day.AddDate(0, 0, 1)
-		return viewSpecBounds{from: &from, to: &to}
+		return viewSpecBounds{from: &from, to: &tomorrow}
+	case HorizonPastAll:
+		// One-sided unbounded — up to and including today, no lower bound.
+		return viewSpecBounds{to: &tomorrow}
 	case HorizonAny, HorizonAll:
 		return viewSpecBounds{}
 	case HorizonCustom:

internal/services/view_service_bounds_test.go

@@ -0,0 +1,123 @@
+package services
+
+// Pure tests for computeViewSpecBounds — t-paliad-248. Covers every
+// TimeHorizon constant in the symmetric date-range fan, including the
+// six new ones added when the picker shipped (next_1d / next_14d /
+// next_all / past_1d / past_14d / past_all).
+//
+// Anchored against a fixed `now` so the assertions never drift with the
+// wall clock. Each case asserts the bounds shape (open-ended vs.
+// closed) and the exact offsets from the anchor day.
+
+import (
+	"testing"
+	"time"
+)
+
+func TestComputeViewSpecBounds_Horizons(t *testing.T) {
+	// Anchor: 2026-05-25 14:37:00 UTC. computeViewSpecBounds normalises
+	// to startOfDay UTC, so the wall-clock time within the day is
+	// irrelevant.
+	now := time.Date(2026, 5, 25, 14, 37, 0, 0, time.UTC)
+	day := time.Date(2026, 5, 25, 0, 0, 0, 0, time.UTC)
+	tomorrow := day.AddDate(0, 0, 1)
+
+	cases := []struct {
+		name     string
+		horizon  TimeHorizon
+		wantFrom *time.Time
+		wantTo   *time.Time
+	}{
+		// Future fan.
+		{"next_1d", HorizonNext1d, &day, tptr(day.AddDate(0, 0, 1))},
+		{"next_7d", HorizonNext7d, &day, tptr(day.AddDate(0, 0, 7))},
+		{"next_14d", HorizonNext14d, &day, tptr(day.AddDate(0, 0, 14))},
+		{"next_30d", HorizonNext30d, &day, tptr(day.AddDate(0, 0, 30))},
+		{"next_90d", HorizonNext90d, &day, tptr(day.AddDate(0, 0, 90))},
+		// One-sided unbounded: from today, no upper bound.
+		{"next_all", HorizonNextAll, &day, nil},
+
+		// Past fan — upper bound is tomorrow (exclusive end-of-today).
+		{"past_1d", HorizonPast1d, tptr(day.AddDate(0, 0, -1)), &tomorrow},
+		{"past_7d", HorizonPast7d, tptr(day.AddDate(0, 0, -7)), &tomorrow},
+		{"past_14d", HorizonPast14d, tptr(day.AddDate(0, 0, -14)), &tomorrow},
+		{"past_30d", HorizonPast30d, tptr(day.AddDate(0, 0, -30)), &tomorrow},
+		{"past_90d", HorizonPast90d, tptr(day.AddDate(0, 0, -90)), &tomorrow},
+		// One-sided unbounded: no lower bound, up to and including today.
+		{"past_all", HorizonPastAll, nil, &tomorrow},
+
+		// Bidirectional unbounded — both nil.
+		{"any", HorizonAny, nil, nil},
+		{"all", HorizonAll, nil, nil},
+	}
+
+	for _, tc := range cases {
+		t.Run(tc.name, func(t *testing.T) {
+			got := computeViewSpecBounds(now, TimeSpec{Horizon: tc.horizon})
+			assertBound(t, "from", got.from, tc.wantFrom)
+			assertBound(t, "to", got.to, tc.wantTo)
+		})
+	}
+}
+
+// TestComputeViewSpecBounds_NewHorizonsAreOneSided documents the
+// semantic distinction between next_all / past_all (one-sided
+// unbounded, with one bound nil and the other set) and the existing
+// HorizonAll / HorizonAny (both bounds nil).
+func TestComputeViewSpecBounds_NewHorizonsAreOneSided(t *testing.T) {
+	now := time.Date(2026, 5, 25, 0, 0, 0, 0, time.UTC)
+
+	nextAll := computeViewSpecBounds(now, TimeSpec{Horizon: HorizonNextAll})
+	if nextAll.from == nil {
+		t.Fatalf("HorizonNextAll: from must be set (today), got nil")
+	}
+	if nextAll.to != nil {
+		t.Fatalf("HorizonNextAll: to must be nil (no upper bound), got %v", *nextAll.to)
+	}
+
+	pastAll := computeViewSpecBounds(now, TimeSpec{Horizon: HorizonPastAll})
+	if pastAll.from != nil {
+		t.Fatalf("HorizonPastAll: from must be nil (no lower bound), got %v", *pastAll.from)
+	}
+	if pastAll.to == nil {
+		t.Fatalf("HorizonPastAll: to must be set (tomorrow), got nil")
+	}
+
+	any := computeViewSpecBounds(now, TimeSpec{Horizon: HorizonAny})
+	if any.from != nil || any.to != nil {
+		t.Fatalf("HorizonAny: both bounds must be nil, got from=%v to=%v", any.from, any.to)
+	}
+}
+
+// TestComputeViewSpecBounds_CustomRoundTrips makes sure the custom
+// horizon passes through the caller-supplied from/to verbatim — no
+// normalisation, no clamping.
+func TestComputeViewSpecBounds_CustomRoundTrips(t *testing.T) {
+	now := time.Date(2026, 5, 25, 0, 0, 0, 0, time.UTC)
+	from := time.Date(2026, 3, 15, 0, 0, 0, 0, time.UTC)
+	to := time.Date(2026, 4, 30, 0, 0, 0, 0, time.UTC)
+
+	got := computeViewSpecBounds(now, TimeSpec{Horizon: HorizonCustom, From: &from, To: &to})
+	if got.from == nil || !got.from.Equal(from) {
+		t.Fatalf("custom from: want %v, got %v", from, got.from)
+	}
+	if got.to == nil || !got.to.Equal(to) {
+		t.Fatalf("custom to: want %v, got %v", to, got.to)
+	}
+}
+
+func tptr(t time.Time) *time.Time { return &t }
+
+func assertBound(t *testing.T, name string, got *time.Time, want *time.Time) {
+	t.Helper()
+	switch {
+	case got == nil && want == nil:
+		return
+	case got == nil:
+		t.Fatalf("%s: want %v, got nil", name, *want)
+	case want == nil:
+		t.Fatalf("%s: want nil, got %v", name, *got)
+	case !got.Equal(*want):
+		t.Fatalf("%s: want %v, got %v", name, *want, *got)
+	}
+}