diff --git a/docs/design/config-redesign.md b/docs/design/config-redesign.md
deleted file mode 100644
index c1765ae..0000000
--- a/docs/design/config-redesign.md
+++ /dev/null
@@ -1,482 +0,0 @@
-# Config System Redesign
-
-## 1. Problem Statement
-
-`LoadConfig()` panics on the server because the config system assumes a writable
-config directory. On the server, `OPAL_CONFIG_DIR=/etc/opal` is read-only
-(systemd `ReadOnlyPaths`), `opal.yml` doesn't exist (Ansible only deploys
-`opal.env`), and the attempt to create it fails. The nil `*Config` propagates
-unchecked through `GetConfig()` callers to `BuildUrgencyCoefficients(nil)`,
-causing a nil-pointer panic.
-
-### Panic chain
-
-```
-sortByUrgency()                     report.go:426
-  cfg, _ := GetConfig()             ← error discarded, cfg = nil
-  coeffs := BuildUrgencyCoefficients(cfg)
-    return &UrgencyCoefficients{
-      Due: cfg.UrgencyDue,          ← nil dereference → PANIC
-    }
-```
-
-### Root cause
-
-The config system was designed for the CLI (user-writable `~/.config/opal/`)
-and has three interacting issues:
-
-1. **Write-on-read**: `LoadConfig()` creates directories and writes a default
-   `opal.yml` as a side effect of *reading* config. This fails when the
-   filesystem is read-only.
-2. **Error swallowing**: All internal callers use `cfg, _ := GetConfig()`,
-   turning a load failure into a nil-pointer panic instead of a graceful error.
-3. **No mode awareness**: The same code path runs for CLI users (writable home
-   dir, interactive, config file is useful) and for the server (read-only
-   `/etc/opal`, headless, defaults are fine).
-
----
-
-## 2. Current Architecture
-
-```mermaid
-graph TD
-    subgraph "Config Sources"
-        ENV["opal.env<br/>(systemd EnvironmentFile)"]
-        YML["opal.yml<br/>(Viper / YAML)"]
-        DEFAULTS["Hardcoded defaults<br/>(in LoadConfig)"]
-    end
-
-    subgraph "Loading Mechanisms"
-        AUTH_LOAD["auth.LoadConfig()<br/>os.Getenv() → auth.Config"]
-        ENGINE_LOAD["engine.LoadConfig()<br/>Viper → engine.Config"]
-    end
-
-    subgraph "Consumers"
-        SERVER["API Server<br/>(handlers, middleware)"]
-        CLI["CLI Commands<br/>(cmd/ package)"]
-    end
-
-    ENV --> AUTH_LOAD
-    YML --> ENGINE_LOAD
-    DEFAULTS --> ENGINE_LOAD
-
-    AUTH_LOAD --> SERVER
-    ENGINE_LOAD --> SERVER
-    ENGINE_LOAD --> CLI
-```
-
-### Two independent config subsystems
-
-| Aspect | `engine.Config` | `auth.Config` |
-|--------|----------------|---------------|
-| **Source** | `opal.yml` via Viper | Environment variables |
-| **Loaded by** | `engine.LoadConfig()` | `auth.LoadConfig()` |
-| **Caching** | Singleton (`globalConfig`) | None (re-read each call) |
-| **Write side effects** | Creates dir + file on load | None |
-| **Error model** | Returns `(*Config, error)` | Returns `*Config` (no error) |
-| **Used by** | CLI + Server (lazy) | Server only |
-
-### `engine.Config` field categories
-
-| Category | Fields | CLI | Server | Notes |
-|----------|--------|-----|--------|-------|
-| **Display** | `DefaultFilter`, `DefaultSort`, `DefaultReport`, `ColorOutput` | Yes | No | Terminal-only |
-| **Date** | `WeekStartDay`, `DefaultDueTime` | Yes | Yes | Used by `ParseDate()` |
-| **Urgency** | 13 urgency coefficients | Yes | Yes | Core scoring logic |
-| **Limits** | `NextLimit` | Yes | Indirectly | Report limit |
-| **Sync** | 6 sync fields | Yes | No | Client-side sync config |
-
-Key observation: The server only needs **urgency coefficients** and **date
-settings** from `engine.Config`. It doesn't need display preferences or sync
-settings. But all 30 fields are loaded through the same mechanism.
-
-### `engine.LoadConfig()` flow
-
-```
-1. Check globalConfig singleton → return if cached
-2. GetConfigDir() → resolve directory path
-3. os.MkdirAll(configDir)          ← FAILS on read-only FS
-4. Viper.ReadInConfig()
-5. If read fails:
-   a. Viper.WriteConfigAs()        ← FAILS on read-only FS
-   b. Re-read written file
-6. Unmarshal → Config struct
-7. Cache in globalConfig
-```
-
-Steps 3 and 5a are the failure points on the server.
-
-### Caller error handling audit
-
-| Caller | File:Line | Error handling |
-|--------|-----------|----------------|
-| `FormatTaskListWithFormat` | display.go:24 | `cfg, _ := GetConfig()` — **ignored** |
-| `formatMinimalLine` | display.go:119 | `cfg, _ := GetConfig()` — **ignored** |
-| `NextReport.SortFunc` | report.go:168 | `cfg, _ := GetConfig()` — **ignored** |
-| `NextReport.LimitFunc` | report.go:187 | `cfg, _ := GetConfig()` — **ignored** |
-| `sortByUrgency` | report.go:426 | `cfg, _ := GetConfig()` — **ignored** |
-| `PopulateUrgency` | task.go:769 | `cfg, _ := GetConfig()` — **ignored** |
-| `getWeekStart` | dateparse.go:484 | Checked — falls back to Monday |
-| All cmd/ callers | root.go, sync.go | Checked — exits on error |
-
-Every engine-internal caller except `dateparse.go` discards the error.
-
----
-
-## 3. Additional Issues Found
-
-### 3a. Config file clobbering
-
-`LoadConfig()` line 296-306 catches **any** `ReadInConfig` error (not just
-"file not found") and overwrites the config file with defaults. A YAML syntax
-error in the user's `opal.yml` silently destroys their customizations.
-
-### 3b. `SaveConfig()` manual field sync
-
-Adding a new config field requires updating three places:
-1. `Config` struct definition
-2. `LoadConfig()` — `v.SetDefault(...)` call
-3. `SaveConfig()` — `v.Set(...)` call
-
-Missing any one of these causes silent data loss on save or missing defaults.
-
-### 3c. `auth.LoadConfig()` silent parse failures
-
-```go
-jwtExpiry, _ := strconv.Atoi(getEnv("JWT_EXPIRY", "3600"))
-```
-
-If `JWT_EXPIRY=abc`, `Atoi` returns `(0, error)`, error is discarded, and
-`JWTExpiry` silently becomes 0 (tokens expire immediately).
-
-### 3d. Insecure JWT default
-
-`JWT_SECRET` defaults to `"change-me-in-production"`. While `validateServerConfig()`
-checks for empty values, it doesn't check for the insecure default.
-
-### 3e. Sync API key in plaintext
-
-`sync_api_key` is stored in `opal.yml` with no special file permissions.
-
-### 3f. No env-var override of YAML config
-
-Viper's `AutomaticEnv()` is never called, so there's no way to override YAML
-config values via environment variables. This is an obstacle for 12-factor
-server deployments.
-
----
-
-## 4. Design Options
-
-### Option A: Minimal fix — graceful fallback to defaults
-
-**Change**: Make `LoadConfig()` return a `DefaultConfig()` when it can't read
-or write the config file, instead of returning nil.
-
-```go
-func DefaultConfig() *Config {
-    return &Config{
-        DefaultFilter:      "status:pending",
-        DefaultSort:        "due,priority",
-        // ... all defaults ...
-        UrgencyDue:         12.0,
-        // ...
-    }
-}
-
-func LoadConfig() (*Config, error) {
-    if globalConfig != nil {
-        return globalConfig, nil
-    }
-
-    cfg, err := loadFromFile()
-    if err != nil {
-        // File not available — use defaults (common in server mode)
-        cfg = DefaultConfig()
-    }
-
-    globalConfig = cfg
-    return cfg, nil
-}
-```
-
-**Pros**: Smallest change, fixes the panic, no behavior change for CLI users.
-**Cons**: Doesn't address the architectural confusion. Error-swallowing callers
-remain. Write-on-read side effect remains for CLI. Three-source config stays.
-
----
-
-### Option B: Separate load paths for CLI and server
-
-**Change**: Split `LoadConfig()` into two functions:
-- `LoadConfigFromFile()` — current behavior for CLI (read/write YAML)
-- `LoadConfigFromDefaults()` — returns `DefaultConfig()` for server
-
-The server startup code calls `LoadConfigFromDefaults()` eagerly during init,
-populating the singleton before any lazy `GetConfig()` call.
-
-```go
-// cmd/server.go — in serverStartCmd.Run, before InitDB()
-engine.LoadConfigFromDefaults()
-```
-
-**Pros**: Fixes the panic. Server path never touches the filesystem for config.
-Explicit about which mode is running. CLI behavior unchanged.
-**Cons**: Two code paths to maintain. Server can't be customized without code
-changes (urgency tuning, etc.).
-
----
-
-### Option C: Read-only load with env-var overrides (recommended)
-
-**Change**: Restructure `LoadConfig()` to:
-1. Start with hardcoded defaults (always succeeds)
-2. Layer YAML file on top **if it exists** (read-only, never create)
-3. Layer environment variables on top (via Viper `AutomaticEnv`)
-4. Never write to the filesystem as a side effect of loading
-
-```go
-func LoadConfig() (*Config, error) {
-    if globalConfig != nil {
-        return globalConfig, nil
-    }
-
-    v := viper.New()
-    v.SetConfigType("yaml")
-
-    // 1. Hardcoded defaults (always present)
-    setDefaults(v)
-
-    // 2. YAML file overlay (optional, read-only)
-    if configPath, err := GetConfigPath(); err == nil {
-        v.SetConfigFile(configPath)
-        if err := v.ReadInConfig(); err != nil {
-            if _, ok := err.(viper.ConfigFileNotFoundError); !ok {
-                // File exists but is malformed — report, don't clobber
-                if _, statErr := os.Stat(configPath); statErr == nil {
-                    return nil, fmt.Errorf("config file %s is invalid: %w", configPath, err)
-                }
-                // File doesn't exist — that's fine, use defaults
-            }
-        }
-    }
-
-    // 3. Environment variable overlay
-    v.SetEnvPrefix("OPAL")
-    v.AutomaticEnv()
-
-    cfg := &Config{}
-    if err := v.Unmarshal(cfg); err != nil {
-        return nil, fmt.Errorf("failed to unmarshal config: %w", err)
-    }
-
-    globalConfig = cfg
-    return cfg, nil
-}
-```
-
-File creation moves to an explicit `InitConfig()` function, called only during
-`opal setup` and CLI first-run:
-
-```go
-func InitConfig() error {
-    configDir, err := GetConfigDir()
-    if err != nil {
-        return err
-    }
-    if err := os.MkdirAll(configDir, 0755); err != nil {
-        return fmt.Errorf("failed to create config directory: %w", err)
-    }
-    return SaveConfig(DefaultConfig())
-}
-```
-
-Environment variable mapping:
-
-| YAML key | Env var |
-|----------|---------|
-| `urgency_due_coefficient` | `OPAL_URGENCY_DUE_COEFFICIENT` |
-| `default_filter` | `OPAL_DEFAULT_FILTER` |
-| `week_start_day` | `OPAL_WEEK_START_DAY` |
-| ... | `OPAL_<UPPER_SNAKE>` |
-
-**Pros**:
-- Fixes the panic — loading never fails fatally (missing file = defaults)
-- Malformed YAML is reported, not silently clobbered
-- Server can tune urgency via `opal.env` without deploying `opal.yml`
-- 12-factor compatible (env vars override everything)
-- CLI behavior unchanged (reads existing `opal.yml` + env overrides)
-- Single code path for both CLI and server
-- No filesystem write side effects during load
-
-**Cons**:
-- `SaveConfig()` still needs the manual field-sync (separate improvement)
-- Slightly more Viper configuration
-
----
-
-### Option D: Full restructure with typed config sections
-
-**Change**: Split `Config` into domain-specific sub-configs and unify the
-loading mechanism for all config (merge `auth.Config` into the same system).
-
-```go
-type Config struct {
-    Display  DisplayConfig  `mapstructure:"display"`
-    Urgency  UrgencyConfig  `mapstructure:"urgency"`
-    Sync     SyncConfig     `mapstructure:"sync"`
-    Server   ServerConfig   `mapstructure:"server"`  // absorbs auth.Config
-}
-```
-
-**Pros**: Clean separation. Single config system. Extensible.
-**Cons**: Large refactor. Breaks existing `opal.yml` format. `auth.Config`
-works fine as-is for its purpose. Over-engineered for the current problem.
-
----
-
-## 5. Recommendation
-
-**Option C** — read-only load with env-var overrides.
-
-It fixes the immediate panic, eliminates the write-on-read footgun, enables
-server customization via environment variables, and does it with a focused
-change to one function. It doesn't over-engineer or restructure things that
-work.
-
-### Implementation plan
-
-#### Step 1: Extract `DefaultConfig()` constructor
-
-Create a `DefaultConfig()` function that returns a `*Config` with all defaults
-populated. This is the single source of truth for default values — used by
-`LoadConfig()`, `InitConfig()`, and `SaveConfig()`.
-
-**Files**: `internal/engine/config.go`
-
-#### Step 2: Rewrite `LoadConfig()` to be read-only
-
-Remove directory creation and file writing. Layer: defaults → YAML (if
-exists) → env vars. Return `DefaultConfig()` on missing file instead of nil.
-Return error only on malformed YAML (file exists but can't be parsed).
-
-**Files**: `internal/engine/config.go`
-
-#### Step 3: Extract `InitConfig()` for file creation
-
-Move the "create config directory + write defaults" logic into `InitConfig()`.
-Call it from `initializeApp()` (CLI first-run path) and `opal setup`.
-
-**Files**: `internal/engine/config.go`, `cmd/root.go`, `cmd/setup.go`
-
-#### Step 4: Fix error-swallowing callers
-
-Two options, from least to most invasive:
-
-**4a (recommended)**: Make `GetConfig()` never return nil. Since `LoadConfig()`
-now always returns a valid `*Config` (defaults on failure), `GetConfig()` also
-always returns non-nil. The `cfg, _ := GetConfig()` pattern becomes safe. The
-error return is kept for callers that want to distinguish "loaded from file" vs
-"using defaults" but nil is never returned.
-
-**4b (defensive)**: Also make `BuildUrgencyCoefficients()` accept nil and return
-default coefficients. Belt-and-suspenders.
-
-**Files**: `internal/engine/config.go`, `internal/engine/urgency.go`
-
-#### Step 5: Enable env-var overrides via Viper
-
-Add `v.SetEnvPrefix("OPAL")` and `v.AutomaticEnv()` so that any config key
-can be overridden by `OPAL_<KEY>`. Update `opal.env` in deployment docs to
-show urgency tuning examples.
-
-**Files**: `internal/engine/config.go`, `docs/deployment.md`
-
-#### Step 6: Eliminate `SaveConfig()` field duplication
-
-Replace the manual `v.Set()` calls with Viper's `mapstructure` round-trip or
-a reflect-based helper so new fields are automatically included.
-
-```go
-func SaveConfig(cfg *Config) error {
-    v := viper.New()
-    v.SetConfigFile(configPath)
-    v.SetConfigType("yaml")
-
-    // Use mapstructure tags to populate viper from struct
-    data, _ := mapstructure.Decode(cfg) // or manual marshal
-    for k, val := range data {
-        v.Set(k, val)
-    }
-    return v.WriteConfig()
-}
-```
-
-Alternatively, marshal to YAML directly with `yaml.Marshal` and write the
-bytes, bypassing Viper for the write path entirely.
-
-**Files**: `internal/engine/config.go`
-
-### Deployment changes
-
-After this redesign, the Ansible role needs **no changes** — `opal.env` is
-sufficient. To customize urgency coefficients on the server, add lines to
-`opal.env`:
-
-```bash
-# Server-side urgency tuning (optional)
-OPAL_URGENCY_DUE_COEFFICIENT=12.0
-OPAL_URGENCY_AGE_MAX=180
-```
-
-No `opal.yml` deployment needed. The server runs on defaults + env overrides.
-
----
-
-## 6. Technical Decisions
-
-### ADR-1: Config loading must not write to the filesystem
-
-- **Context**: `LoadConfig()` creates directories and writes `opal.yml` as a
-  side effect. This fails on read-only filesystems (server) and is surprising
-  behavior for a "load" function.
-- **Decision**: `LoadConfig()` becomes pure read. File creation moves to
-  `InitConfig()`, called explicitly during setup/first-run.
-- **Alternatives**: Deploy `opal.yml` via Ansible; make `/etc/opal` writable.
-- **Consequences**: CLI first-run code must call `InitConfig()` explicitly.
-  `IsFirstRun()` check remains in `initializeApp()`.
-
-### ADR-2: Missing config file returns defaults, not an error
-
-- **Context**: On the server, `opal.yml` doesn't exist and doesn't need to.
-  The current code treats this as a fatal error.
-- **Decision**: Missing file = use defaults silently. Malformed file = return
-  error (don't clobber). `GetConfig()` never returns nil.
-- **Alternatives**: Require `opal.yml` everywhere; use separate load functions
-  per mode.
-- **Consequences**: Callers that discard errors (`cfg, _ := GetConfig()`) are
-  now safe. The error return still exists for callers that need to distinguish
-  "file loaded" from "using defaults".
-
-### ADR-3: Environment variables can override any config key
-
-- **Context**: The server is configured entirely via env vars (`opal.env` +
-  systemd). Currently urgency coefficients can only be set via `opal.yml`.
-- **Decision**: Enable Viper's `AutomaticEnv()` with prefix `OPAL_`. Any YAML
-  key `foo_bar` can be overridden by `OPAL_FOO_BAR`.
-- **Alternatives**: Add a server-specific config file; keep config values
-  hardcoded for server.
-- **Consequences**: Layered config: defaults < YAML file < env vars. Aligns
-  with 12-factor app principles. Deployment can tune behavior without deploying
-  additional files.
-
-### ADR-4: Do not merge auth.Config into engine.Config
-
-- **Context**: `auth.Config` and `engine.Config` are completely independent
-  systems. Merging them would create a single unified config.
-- **Decision**: Keep them separate. `auth.Config` loads from env vars, works
-  correctly, and is server-only. No reason to change it.
-- **Alternatives**: Unified config struct with sections.
-- **Consequences**: Two config types remain. This is acceptable because they
-  serve different purposes, have different lifecycles, and the current
-  `auth.Config` has no bugs.
diff --git a/docs/design/web-bottom-sheet-design.md b/docs/design/web-bottom-sheet-design.md
new file mode 100644
index 0000000..da10bd2
--- /dev/null
+++ b/docs/design/web-bottom-sheet-design.md
@@ -0,0 +1,1633 @@
+# Task Detail Bottom Sheet — Design
+
+**Status:** Draft
+**Implements:** [web-cli-parity.md](web-cli-parity.md) 1.1 (Task Detail View) + 1.2 (Task Editing)
+**Depends on:** Existing `Task` type, `PUT /tasks/:uuid`, tag endpoints
+
+---
+
+## 1. Overview
+
+A bottom sheet that slides up when a user taps a task row. It shows every
+non-null field on the task and allows inline editing of mutable fields. This is
+the single biggest new surface in the web app — it becomes the hub for viewing,
+editing, starting/stopping, and deleting tasks.
+
+```
+┌─────────────────────────────────┐
+│  Header  │  ReportPicker  │  ⚙  │
+├─────────────────────────────────┤
+│                                 │
+│  Task list (partially visible,  │
+│  dimmed behind scrim)           │
+│                                 │
+├─────────────────────────────────┤  ← scrim starts here
+│ ┌─────────────────────────────┐ │
+│ │  ─── drag handle ───        │ │
+│ │                             │ │
+│ │  Buy groceries        [edit]│ │  ← description (tappable to edit)
+│ │                             │ │
+│ │  Status      Pending        │ │  ← read-only
+│ │  Priority    ● High         │ │  ← tappable
+│ │  Project     Home           │ │  ← tappable
+│ │  Due         Tomorrow       │ │  ← tappable
+│ │  Tags        errand, food   │ │  ← tappable (add/remove)
+│ │  Created     Feb 18         │ │  ← read-only
+│ │  Modified    Feb 19         │ │  ← read-only
+│ │  Urgency     8.2            │ │  ← read-only
+│ │                             │ │
+│ │  [Start]  [Delete]          │ │  ← action buttons
+│ └─────────────────────────────┘ │
+├─────────────────────────────────┤
+│  InputBar                       │
+└─────────────────────────────────┘
+```
+
+---
+
+## 2. Component: `BottomSheet.svelte`
+
+A generic, reusable bottom sheet. Owns the open/close lifecycle, scrim,
+drag-to-dismiss, and snap positioning. Content is a slot.
+
+### 2.1 Interface
+
+```typescript
+interface BottomSheetProps {
+  open: boolean
+  onClose: () => void
+}
+```
+
+Controlled via the `open` prop. No exposed methods needed.
+
+### 2.2 Behavior
+
+**Open:**
+- Sheet translates from `translateY(100%)` to `translateY(0)` via CSS transition
+- Scrim fades in (`opacity: 0 → 0.5`) — same `rgba(0,0,0,0.5)` as FilterModal
+  backdrop
+- Body scroll is locked (`overflow: hidden` on `<html>`) while sheet is open
+- Focus is trapped inside the sheet (keyboard accessibility)
+
+**Close (four ways):**
+1. **Tap scrim** — light-dismiss, same as FilterModal
+2. **Drag down** — swipe the sheet down past a threshold (see 2.3)
+3. **Close button** — explicit X in top-right (accessibility fallback)
+4. **Escape key** — keyboard dismiss
+
+**Position:**
+- Sheet takes up to 85% of viewport height (`max-height: 85dvh`)
+- Content scrolls internally (`overflow-y: auto`) if it exceeds the sheet height
+- On desktop (>768px), sheet is capped at 480px width and centered horizontally
+
+### 2.3 Drag-to-Dismiss Gesture
+
+Same angle-based detection model as `SwipeAction`, but vertical:
+
+1. Touch starts on the drag handle or sheet header area
+2. If `|deltaY| > 10px` AND `|deltaY| > |deltaX| * 2` → lock to vertical drag
+3. During drag: `translateY(deltaY)` (only positive — can't drag up past 0)
+4. On release: if `deltaY > 150px` or velocity > threshold → close with
+   animation. Otherwise snap back to `translateY(0)`
+5. CSS transition on release (`transition: transform 0.3s ease-out`)
+
+The drag handle is a visual affordance (small pill-shaped bar at the top), but
+the entire header region is the drag target.
+
+### 2.4 Implementation Pattern
+
+Uses a `<div>` rather than `<dialog>` (see ADR-7 below for rationale).
+
+```svelte
+<div class="sheet-scrim" class:open on:click={close}>
+  <div class="sheet" class:open style:transform="translateY({dragOffset}px)"
+       on:click|stopPropagation>
+    <div class="sheet-handle" on:touchstart={handleDragStart}
+         on:touchmove={handleDragMove} on:touchend={handleDragEnd}>
+      <div class="handle-bar"></div>
+    </div>
+    <div class="sheet-content">
+      <slot />
+    </div>
+  </div>
+</div>
+```
+
+### 2.5 CSS
+
+```css
+.sheet-scrim {
+  position: fixed;
+  inset: 0;
+  z-index: 50;
+  background: rgba(0, 0, 0, 0.5);
+  opacity: 0;
+  pointer-events: none;
+  transition: opacity 0.3s ease;
+}
+
+.sheet-scrim.open {
+  opacity: 1;
+  pointer-events: auto;
+}
+
+.sheet {
+  position: fixed;
+  bottom: 0;
+  left: 0;
+  right: 0;
+  max-height: 85dvh;
+  background: var(--bg-primary);
+  border-radius: 1rem 1rem 0 0;
+  box-shadow: var(--shadow-lg);
+  transform: translateY(100%);
+  transition: transform 0.3s ease-out;
+  display: flex;
+  flex-direction: column;
+  z-index: 51;
+}
+
+.sheet.open {
+  transform: translateY(0);
+}
+
+.sheet-handle {
+  display: flex;
+  justify-content: center;
+  padding: var(--spacing-sm) 0;
+  cursor: grab;
+  touch-action: none;
+}
+
+.handle-bar {
+  width: 2.5rem;
+  height: 0.25rem;
+  background: var(--text-tertiary);
+  border-radius: 9999px;
+}
+
+.sheet-content {
+  flex: 1;
+  overflow-y: auto;
+  overscroll-behavior: contain;
+  padding: 0 var(--spacing-md) var(--spacing-lg);
+}
+
+/* Desktop constraint */
+@media (min-width: 769px) {
+  .sheet {
+    max-width: 480px;
+    left: 50%;
+    transform: translateX(-50%) translateY(100%);
+  }
+  .sheet.open {
+    transform: translateX(-50%) translateY(0);
+  }
+}
+```
+
+---
+
+## 3. Component: `TaskDetail.svelte`
+
+The content rendered inside the `BottomSheet`. Owns the task field layout and
+inline editing logic.
+
+### 3.1 Interface
+
+```typescript
+interface TaskDetailProps {
+  task: Task
+  onUpdate: (uuid: string, updates: Partial<Task>) => Promise<void>
+  onStart: (uuid: string) => Promise<void>
+  onStop: (uuid: string) => Promise<void>
+  onDelete: (uuid: string) => void   // opens confirmation, doesn't delete directly
+  onComplete: (uuid: string) => void
+  onClose: () => void
+}
+```
+
+### 3.2 Field Layout
+
+Fields are displayed in a two-column key-value layout. Each row is a
+`field-row` with a label (left) and value (right). Editable fields show a
+subtle edit affordance on tap.
+
+**Field display order and editability:**
+
+| Field | Editable | Display | Shown when |
+|-------|----------|---------|------------|
+| Description | Yes | Large text at top, outside the key-value grid | Always |
+| Status | No | Badge: "Pending" / "Completed" / "Deleted" / "Recurring" | Always |
+| Priority | Yes | Colored dot + label. Tap → cycles through H/M/D/L | Always |
+| Project | Yes | Text. Tap → inline text input | Non-null, or "Add..." |
+| Due | Yes | Relative date + absolute in parentheses. Tap → date input | Non-null, or "Set..." |
+| Scheduled | Yes | Same format as due | Non-null, or "Set..." |
+| Wait | Yes | Same format | Non-null, or "Set..." |
+| Until | Yes | Same format | Non-null, or "Set..." |
+| Start (active since) | No | Relative time | Only if task is started |
+| Recurrence | Yes* | Duration label (e.g. "every 1 week") | Only on templates |
+| Parent | No | "Recurring instance" with parent link | Only on instances |
+| Tags | Yes | Pill list with + button to add, x on each to remove | Always (empty = just [+]) |
+| Created | No | Absolute date | Always |
+| Modified | No | Absolute date | Always |
+| End | No | Absolute date | Only if completed |
+| UUID | No | Truncated, tap to copy full UUID | Always |
+| Urgency | No | Numeric score | Always (> 0) |
+
+*Recurrence is editable only on template tasks (`status === 'R'`), not on
+instances. For all other editable fields on recurring instances, an "edit
+instance or template?" prompt appears first (see section 3.8).
+
+**Null-field rule:** Fields with null values are hidden entirely. No empty rows
+or placeholder text. Exception: editable fields that are commonly set show an
+"Add..." or "Set..." affordance when null (project, due, scheduled, wait,
+until).
+
+### 3.3 Visual Layout
+
+```
+ ─── handle ───
+
+ Buy groceries                                    [✏]
+ ─────────────────────────────────────────────────
+
+ Status        Pending
+ Priority      ● High                             [tap to change]
+ Project       Home                               [tap to edit]
+ Due           Tomorrow (Feb 20)                   [tap to edit]
+ Tags          [errand] [food] [+]
+
+ ─── divider ───
+
+ Created       Feb 18, 2026
+ Modified      Feb 19, 2026
+ Urgency       8.2
+ UUID          8f3a1b2c...                         [tap to copy]
+
+ ─── divider ───
+
+ [ ▶ Start ]    [ ✓ Complete ]    [ 🗑 Delete ]
+```
+
+Three visual sections separated by subtle dividers:
+1. **Editable fields** — the fields users interact with
+2. **Read-only metadata** — timestamps, urgency, UUID
+3. **Actions** — start/stop, delete, complete/uncomplete
+
+### 3.4 Inline Editing Model
+
+When a user taps an editable field value, the value transforms in-place into an
+input control. No modal, no separate edit screen.
+
+**Per-field edit controls:**
+
+| Field | Edit Control | Behavior |
+|-------|-------------|----------|
+| Description | Text input (auto-expanding) | Replace text, Enter to save, Escape to cancel |
+| Priority | Cycle on tap | No input — tapping cycles `H → M → default → L → H` |
+| Project | Text input | Inline text replaces the value. Enter to save. Empty = clear |
+| Due, Scheduled, Wait, Until | `<input type="date">` | Native date picker. Change event saves. Clear button to null |
+| Tags | Pill list + input | [x] on tag to remove, [+] opens a small text input for new tag |
+| Recurrence | Text input | Accepts duration format like `1w`, `2d`, `1mo`. Enter to save |
+
+**Edit lifecycle:**
+1. User taps field value → value becomes an input (the label stays)
+2. User modifies → on Enter or blur or selection → `onUpdate(uuid, { field: newValue })` is called
+3. **Optimistic:** UI shows new value immediately. On API failure, revert and
+   show a brief error toast
+4. Only one field is editable at a time. Tapping another field saves the current
+   one first
+
+**Date fields** use the native `<input type="date">`. This gives us the OS date
+picker on Android and a calendar dropdown on desktop — no library needed. The
+value is converted to/from Unix timestamp via the existing `toUnix`/`fromUnix`
+utils.
+
+### 3.5 Description Editing
+
+The description sits at the top of the sheet as a prominent heading. An edit
+icon (pencil) sits beside it. Tapping the icon (or the description text)
+replaces it with a `<textarea>` that auto-sizes to content.
+
+```
+ Before:  Buy groceries                    [✏]
+ During:  [Buy groceries and also milk_____|]   [✓] [✕]
+ After:   Buy groceries and also milk      [✏]
+```
+
+Save on Enter (without Shift). Cancel on Escape. Explicit save/cancel buttons
+for touch users who can't easily hit Enter/Escape.
+
+### 3.6 Tags Editing
+
+Tags are a special case — they use add/remove endpoints rather than a single
+PUT.
+
+```
+ Tags:   [errand ✕] [food ✕] [+ Add tag]
+```
+
+- Tapping `✕` on a tag calls `DELETE /tasks/:uuid/tags/:tag`
+- Tapping `[+ Add tag]` shows a small inline text input. Enter to add
+  (`POST /tasks/:uuid/tags`), Escape to cancel
+- Optimistic add/remove with rollback on failure
+
+### 3.7 Action Buttons
+
+At the bottom of the sheet, a row of action buttons:
+
+**For pending tasks:**
+```
+[ ▶ Start ]    [ ✓ Complete ]    [ 🗑 Delete ]
+```
+
+**For active (started) tasks:**
+```
+[ ⏹ Stop ]    [ ✓ Complete ]    [ 🗑 Delete ]
+```
+
+**For completed tasks:**
+```
+[ ↩ Uncomplete ]    [ 🗑 Delete ]
+```
+
+- Start/Stop calls `onStart`/`onStop` — wired to `POST /tasks/:uuid/start|stop`
+- Complete calls `onComplete` — same as checkbox/swipe in the list
+- Delete calls `onDelete` — opens the confirmation (designed separately in 1.5)
+- Uncomplete calls `onUpdate(uuid, { status: 'P' })` — sets status back to
+  pending
+
+### 3.8 Recurring Instance Edit — Instance vs Template
+
+When a user taps an editable field on a recurring instance (a task with
+`parent_uuid !== null`), a brief confirmation appears before the edit control
+opens:
+
+```
+ ┌──────────────────────────────┐
+ │  Edit this instance only     │
+ │  Edit template (all future)  │
+ │  Cancel                      │
+ └──────────────────────────────┘
+```
+
+**"Edit this instance"** — applies the change to the current task only via
+`PUT /tasks/:uuid`. Future instances spawned from the template are unaffected.
+
+**"Edit template"** — applies the change to the parent template via
+`PUT /tasks/:parent_uuid`. The current instance is NOT modified — the change
+takes effect on the next spawned instance. The sheet updates to show the
+template after the edit.
+
+**Which fields trigger this?** Only fields that exist on both instance and
+template: description, priority, project, due (as relative offset), tags,
+recurrence. Read-only and instance-specific fields (status, start, created,
+etc.) don't trigger the prompt.
+
+**Implementation:** A small inline popover or action sheet that appears on
+first tap. Selection is remembered for the duration of the sheet session — if
+the user picks "Edit this instance" once, subsequent edits in the same sheet
+opening default to instance without re-prompting. Switching tasks (closing and
+reopening the sheet) resets this.
+
+**Non-recurring tasks:** No prompt. Edits apply directly.
+
+---
+
+Button styling uses the existing `--color-*` tokens:
+- Start/Stop: `--color-primary`
+- Complete: `--color-success`
+- Delete: `--color-danger` (ghost variant — text only, no background)
+- Uncomplete: `--color-primary`
+
+---
+
+## 4. Integration with `+page.svelte`
+
+### 4.1 State
+
+Add to the page's reactive state:
+
+```typescript
+/** @type {Task|null} */
+let selectedTask = null;
+```
+
+### 4.2 Opening
+
+`TaskItem` gets a new `onTap` prop. Tapping the task content area (not the
+checkbox) calls `onTap(task)`. The page sets `selectedTask = task`.
+
+The tap target is the `.task-content` div that already exists in `TaskItem`. The
+checkbox already has `stopPropagation` so it won't trigger the tap.
+
+```svelte
+<!-- +page.svelte -->
+<TaskList
+  {tasks}
+  {loading}
+  {activeReport}
+  onComplete={handleComplete}
+  onTap={(task) => selectedTask = task}
+/>
+
+<BottomSheet open={selectedTask !== null} onClose={() => selectedTask = null}>
+  {#if selectedTask}
+    <TaskDetail
+      task={selectedTask}
+      onUpdate={handleUpdate}
+      onStart={handleStart}
+      onStop={handleStop}
+      onDelete={handleDelete}
+      onComplete={handleComplete}
+      onClose={() => selectedTask = null}
+    />
+  {/if}
+</BottomSheet>
+```
+
+### 4.3 Data Flow
+
+```mermaid
+sequenceDiagram
+    participant User
+    participant TaskItem
+    participant Page as +page.svelte
+    participant Sheet as BottomSheet
+    participant Detail as TaskDetail
+    participant API
+
+    User->>TaskItem: tap task row
+    TaskItem->>Page: onTap(task)
+    Page->>Page: selectedTask = task
+    Page->>Sheet: open=true
+    Sheet-->>User: sheet slides up
+
+    User->>Detail: tap Priority field
+    Detail->>Detail: cycle to next value
+    Detail->>API: PUT /tasks/:uuid {priority: 3}
+    API-->>Detail: updated task
+    Detail->>Page: onUpdate resolves
+    Page->>Page: update task in tasks[]
+
+    User->>Sheet: drag down / tap scrim
+    Sheet->>Page: onClose()
+    Page->>Page: selectedTask = null
+    Sheet-->>User: sheet slides down
+```
+
+### 4.4 Keeping Task State Fresh
+
+When `onUpdate` succeeds, the page must update both the `tasks[]` array (so the
+list reflects the change) and the `selectedTask` (so the sheet shows the new
+value):
+
+```javascript
+async function handleUpdate(uuid, updates) {
+  const updated = await tasksStore.updateTask(uuid, updates);
+  if (selectedTask?.uuid === uuid) {
+    selectedTask = { ...selectedTask, ...updates };
+  }
+}
+```
+
+---
+
+## 5. Technical Decisions
+
+### ADR-7: Bottom sheet as a custom div, not `<dialog>`
+
+**Context:** The FilterModal uses `<dialog>` with `showModal()`. Should the
+bottom sheet do the same?
+
+**Decision:** Use a custom `<div>` with manual scrim and focus trap.
+
+**Rationale:**
+- `<dialog>` with `showModal()` renders to the top-layer and centers content by
+  default. Fighting the centering for a bottom-anchored sheet adds complexity.
+- The sheet has drag-to-dismiss and `translateY` positioning that is easier to
+  control on a regular div.
+- Focus trapping can be done with a small tab-key handler.
+
+**Trade-off:** We lose `<dialog>`'s built-in focus management and Escape-to-close.
+We add a `keydown` listener for Escape and a simple focus trap.
+
+### ADR-8: Inline editing, not a separate edit mode
+
+**Context:** The spec mentions two approaches: "inline (tap field to edit) or
+form-based (edit mode that makes all fields editable)."
+
+**Decision:** Inline tap-to-edit. One field at a time.
+
+**Rationale:**
+- Inline editing is lower friction for single-field changes (the most common
+  case — "change the due date", "add a tag")
+- A form mode would require an edit/save/cancel flow for the entire form
+- Single-field editing means each change is a separate API call, which is
+  simpler and gives immediate feedback
+
+**Trade-off:** Multiple field changes require multiple taps and API calls. For
+batch changes, the CLI's `modify` command remains more efficient.
+
+### ADR-9: Native `<input type="date">` for date fields
+
+**Context:** Date editing needs a picker. Options: native input, custom
+calendar, or CLI-style text input ("tomorrow", "fri").
+
+**Decision:** Native `<input type="date">`.
+
+**Rationale:**
+- Android Chrome shows the system date picker — familiar, touch-friendly
+- Desktop Chrome/Firefox show a calendar dropdown
+- Zero dependency cost
+- The input bar already supports CLI-style relative dates for task creation
+
+**Trade-off:** No relative date input in the edit view. Users who prefer
+"tomorrow" can use the CLI or the input bar.
+
+### ADR-10: Priority cycles on tap, no dropdown
+
+**Context:** Priority has 4 values (H/M/default/L). How should it be edited?
+
+**Decision:** Tap the priority value to cycle: `H → M → default → L → H`.
+
+**Rationale:** 4 values is too few for a dropdown. Cycling is fast and the
+visual dot + label makes the current value clear.
+
+**Trade-off:** Going from H to L is 3 taps. Acceptable.
+
+---
+
+## 6. New/Modified Files
+
+```
+src/lib/components/
+├── BottomSheet.svelte          # NEW — generic bottom sheet
+├── TaskDetail.svelte           # NEW — task detail content
+├── TaskItem.svelte             # MODIFY — add onTap prop + click handler on .task-content
+└── TaskList.svelte             # MODIFY — pass onTap through
+
+src/routes/
+└── +page.svelte                # MODIFY — selectedTask state, handlers, sheet mount
+```
+
+No new API endpoints. No store changes (uses existing `tasksStore.updateTask`,
+`tasks.start`, `tasks.stop`).
+
+---
+
+## 7. Interaction Summary
+
+| User Action | Component | API Call | Result |
+|-------------|-----------|----------|--------|
+| Tap task row | TaskItem → page | — | Sheet opens with task detail |
+| Tap scrim / drag down / Escape | BottomSheet | — | Sheet closes |
+| Tap editable field | TaskDetail | — | Field becomes input |
+| Edit field + Enter/blur | TaskDetail | `PUT /tasks/:uuid` | Optimistic update |
+| Tap tag ✕ | TaskDetail | `DELETE /tasks/:uuid/tags/:tag` | Tag removed |
+| Tap + Add tag | TaskDetail | `POST /tasks/:uuid/tags` | Tag added |
+| Tap priority value | TaskDetail | `PUT /tasks/:uuid` | Priority cycles |
+| Tap Start | TaskDetail | `POST /tasks/:uuid/start` | Task becomes active |
+| Tap Stop | TaskDetail | `POST /tasks/:uuid/stop` | Task stops |
+| Tap Complete | TaskDetail | `POST /tasks/:uuid/complete` | Task completed, sheet closes |
+| Tap Delete | TaskDetail | — | Opens delete confirmation (separate design) |
+| Tap Uncomplete | TaskDetail | `PUT /tasks/:uuid` | Status → pending |
+| Tap UUID | TaskDetail | — | Copies to clipboard |
+| Swipe task left (not started) | SwipeAction → TaskItem → page | `POST /tasks/:uuid/start` | Task becomes active, row gets indicator |
+| Swipe task left (started) | SwipeAction → TaskItem → page | `POST /tasks/:uuid/stop` | Task stops, indicator removed |
+
+---
+
+---
+
+# Swipe Left to Start/Stop — Design
+
+**Implements:** [web-cli-parity.md](web-cli-parity.md) 1.3 (Start / Stop Timer)
+**Modifies:** `SwipeAction.svelte`, `TaskItem.svelte`, `+page.svelte`
+
+---
+
+## 9. Overview
+
+Mirrors the existing swipe-right-to-complete gesture. Swiping a task row left
+toggles the task's started/stopped state. The row does NOT collapse (unlike
+completion) — it stays in place with an updated active indicator.
+
+```
+ Right swipe (existing):
+   ───────────────►  Green + ✓   → Complete (row collapses)
+
+ Left swipe (new):
+   ◄───────────────  Primary + ▶  → Start  (row stays, gets active indicator)
+   ◄───────────────  Primary + ⏹  → Stop   (row stays, active indicator removed)
+```
+
+---
+
+## 10. SwipeAction Changes
+
+The current `SwipeAction` is extended from right-only to bidirectional. The
+component gains a second callback and a second background layer.
+
+### 10.1 Updated Interface
+
+```typescript
+interface SwipeActionProps {
+  onSwipeRight: () => void     // was: onSwipe — complete
+  onSwipeLeft: () => void      // new — start/stop toggle
+  leftIcon: 'start' | 'stop'  // controls which icon shows on left background
+}
+```
+
+All existing call sites are updated to use `onSwipeRight` (renamed from
+`onSwipe`) and must provide `onSwipeLeft`.
+
+### 10.2 Gesture Changes
+
+**Current** (line 56): `offsetX = Math.max(0, deltaX)` — clamps to positive.
+
+**New**: Allow negative deltaX when `onSwipeLeft` is provided.
+
+```javascript
+if (swiping) {
+  if (e.cancelable) e.preventDefault();
+  offsetX = deltaX;  // allow both directions
+}
+```
+
+**Threshold detection** on touch end:
+
+```javascript
+if (offsetX >= THRESHOLD) {
+  // Right swipe — complete (existing behavior)
+  completed = true;
+  offsetX = window.innerWidth;
+  setTimeout(() => onSwipeRight(), 200);
+} else if (offsetX <= -THRESHOLD) {
+  // Left swipe — start/stop (NEW)
+  triggered = true;
+  offsetX = -window.innerWidth;
+  setTimeout(() => {
+    onSwipeLeft();
+    // Snap back — row stays visible
+    offsetX = 0;
+    triggered = false;
+  }, 200);
+} else {
+  offsetX = 0;
+}
+```
+
+Key difference: right-swipe sets `completed = true` and the row collapses (via
+TaskItem's `completing` class). Left-swipe sets `triggered = true` temporarily,
+animates off-screen left, then **snaps back to 0** and the row remains. The
+task stays in the list with its active state toggled.
+
+### 10.3 Dual Background Layers
+
+Two background layers, one on each side. Only the relevant one is visible based
+on swipe direction.
+
+```svelte
+<!-- Left background (revealed on RIGHT swipe — complete) -->
+<div class="swipe-bg swipe-bg-right"
+     style:opacity={rightProgress}>
+  <svg class="swipe-icon" viewBox="0 0 24 24">
+    <path d="M5 13l4 4L19 7" />  <!-- checkmark -->
+  </svg>
+</div>
+
+<!-- Right background (revealed on LEFT swipe — start/stop) -->
+<div class="swipe-bg swipe-bg-left"
+     style:opacity={leftProgress}>
+  {#if leftIcon === 'stop'}
+    <svg class="swipe-icon" viewBox="0 0 24 24">
+      <rect x="6" y="6" width="12" height="12" rx="1" />  <!-- stop square -->
+    </svg>
+  {:else}
+    <svg class="swipe-icon" viewBox="0 0 24 24">
+      <polygon points="6,4 20,12 6,20" />  <!-- play triangle -->
+    </svg>
+  {/if}
+</div>
+```
+
+**Progress calculations:**
+
+```javascript
+$: rightProgress = offsetX > 0 ? Math.min(offsetX / THRESHOLD, 1) : 0;
+$: leftProgress = offsetX < 0 ? Math.min(Math.abs(offsetX) / THRESHOLD, 1) : 0;
+```
+
+### 10.4 CSS
+
+```css
+.swipe-bg {
+  position: absolute;
+  inset: 0;
+  display: flex;
+  align-items: center;
+}
+
+.swipe-bg-right {
+  background-color: var(--color-success);
+  padding-left: var(--spacing-lg);
+  justify-content: flex-start;
+}
+
+.swipe-bg-left {
+  background-color: var(--color-primary);
+  padding-right: var(--spacing-lg);
+  justify-content: flex-end;
+}
+
+.swipe-icon {
+  width: 1.5rem;
+  height: 1.5rem;
+  color: white;
+  fill: none;
+  stroke: currentColor;
+  stroke-width: 3;
+  stroke-linecap: round;
+  stroke-linejoin: round;
+}
+
+/* Override for filled icons (play/stop use fill, not stroke) */
+.swipe-bg-left .swipe-icon {
+  fill: white;
+  stroke: none;
+}
+```
+
+---
+
+## 11. TaskItem Changes
+
+### 11.1 New Props
+
+```typescript
+interface TaskItemProps {
+  task: Task
+  onComplete: (uuid: string) => void
+  onTap: (task: Task) => void          // from bottom sheet design
+  onStartStop: (uuid: string) => void  // new — toggle start/stop
+}
+```
+
+### 11.2 Active Indicator
+
+When a task has `task.start !== null`, it is active and needs a visual indicator
+in the list. Two changes:
+
+**1. Left border accent:**
+
+A colored left border on the task row. Subtle but visible in a list scan.
+
+```css
+.task-item.active {
+  border-left: 3px solid var(--color-primary);
+  padding-left: calc(var(--spacing-md) - 3px);  /* compensate for border */
+}
+```
+
+**2. "Active" meta pill:**
+
+A small pill in the meta row, similar to priority/project pills, using the
+primary color.
+
+```svelte
+{#if task.start}
+  <span class="meta-item active-pill">Active</span>
+{/if}
+```
+
+```css
+.active-pill {
+  background-color: rgba(var(--color-primary-rgb), 0.15);
+  color: var(--color-primary);
+}
+```
+
+Note: This requires the theme to expose a `--color-primary-rgb` token (just the
+RGB values without `rgb()`) for the alpha background. Alternatively, use a
+dedicated `--color-active-bg` / `--color-active-text` pair in each theme,
+following the existing badge pattern.
+
+### 11.3 SwipeAction Wiring
+
+```svelte
+<SwipeAction
+  onSwipeRight={() => onComplete(task.uuid)}
+  onSwipeLeft={() => onStartStop(task.uuid)}
+  leftIcon={task.start ? 'stop' : 'start'}
+>
+  <!-- task-item content -->
+</SwipeAction>
+```
+
+The `leftIcon` prop is derived from the task's current state — if started, show
+stop icon; if not started, show start icon. This gives the user a visual cue
+during the swipe about what action will happen.
+
+### 11.4 Tap Handler
+
+The `.task-content` div gets a click handler for opening the bottom sheet
+(from the bottom sheet design):
+
+```svelte
+<div class="task-content" on:click={() => onTap(task)}>
+```
+
+This is separate from the swipe gesture — taps are point events, swipes require
+movement past the 10px angle-lock threshold.
+
+---
+
+## 12. Page Integration
+
+### 12.1 New Handler in `+page.svelte`
+
+```javascript
+async function handleStartStop(uuid) {
+  const task = tasks.find(t => t.uuid === uuid);
+  if (!task) return;
+
+  try {
+    if (task.start) {
+      await tasksStore.stopTask(uuid);
+    } else {
+      await tasksStore.startTask(uuid);
+    }
+  } catch (error) {
+    console.error('Failed to start/stop task:', error);
+  }
+}
+```
+
+### 12.2 Store Methods
+
+`tasksStore` needs `startTask` and `stopTask` methods that call the existing
+API endpoints and update the local task array:
+
+```javascript
+async startTask(uuid) {
+  // Optimistic: set start to now
+  const now = Math.floor(Date.now() / 1000);
+  update(tasks => tasks.map(t =>
+    t.uuid === uuid ? { ...t, start: now } : t
+  ));
+  try {
+    await tasks.start(uuid);
+  } catch (err) {
+    // Rollback
+    update(tasks => tasks.map(t =>
+      t.uuid === uuid ? { ...t, start: null } : t
+    ));
+    throw err;
+  }
+}
+
+async stopTask(uuid) {
+  // Optimistic: clear start
+  let prevStart;
+  update(tasks => tasks.map(t => {
+    if (t.uuid === uuid) {
+      prevStart = t.start;
+      return { ...t, start: null };
+    }
+    return t;
+  }));
+  try {
+    await tasks.stop(uuid);
+  } catch (err) {
+    // Rollback
+    update(tasks => tasks.map(t =>
+      t.uuid === uuid ? { ...t, start: prevStart } : t
+    ));
+    throw err;
+  }
+}
+```
+
+### 12.3 Wiring
+
+```svelte
+<TaskList
+  {tasks}
+  {loading}
+  {activeReport}
+  onComplete={handleComplete}
+  onTap={(task) => selectedTask = task}
+  onStartStop={handleStartStop}
+/>
+```
+
+`TaskList` passes `onStartStop` through to each `TaskItem`.
+
+---
+
+## 13. Interaction Flow
+
+```mermaid
+sequenceDiagram
+    participant User
+    participant SwipeAction
+    participant TaskItem
+    participant Page
+    participant API
+
+    User->>SwipeAction: swipe left on task row
+    SwipeAction->>SwipeAction: offsetX goes negative, left bg reveals
+    SwipeAction->>SwipeAction: release past -100px threshold
+    SwipeAction->>SwipeAction: animate to -100vw, then snap back to 0
+    SwipeAction->>TaskItem: onSwipeLeft()
+    TaskItem->>Page: onStartStop(uuid)
+    Page->>Page: optimistic: toggle task.start
+    TaskItem-->>User: active indicator appears/disappears
+    Page->>API: POST /tasks/:uuid/start (or /stop)
+    API-->>Page: success
+    Note over Page: on failure, rollback optimistic update
+```
+
+---
+
+## 14. Technical Decision
+
+### ADR-11: Extend SwipeAction vs. new component
+
+**Context:** Left-swipe needs different behavior from right-swipe (toggle vs.
+collapse, different colors/icons). Should we extend the existing SwipeAction or
+create a separate component?
+
+**Decision:** Extend `SwipeAction` to be bidirectional. Rename `onSwipe` to
+`onSwipeRight`, add `onSwipeLeft`. All call sites are updated.
+
+**Rationale:**
+- Touch gesture handlers can't be cleanly nested — two swipe components on the
+  same element would fight over touch events
+- The angle-lock, threshold, and snap-back logic is identical in both
+  directions; only the threshold action differs
+- One component, one touch handler, two callbacks
+
+**Trade-off:** SwipeAction becomes slightly more complex (dual backgrounds,
+direction detection). This is manageable — the core gesture logic stays the same,
+with a direction check at threshold.
+
+---
+
+## 15. Theme Additions
+
+Each theme needs new tokens for the active state badge:
+
+```css
+/* Add to each theme block in app.css */
+--color-active-bg: rgba(57, 208, 186, 0.15);  /* obsidian: primary @ 15% */
+--color-active-text: #39d0ba;                   /* obsidian: primary */
+```
+
+Paper and midnight themes follow the same pattern with their respective primary
+colors (`#6366f1` for paper, `#8b5cf6` for midnight).
+
+---
+
+## 16. Updated File List
+
+Combining bottom sheet + swipe-left changes:
+
+```
+src/lib/components/
+├── BottomSheet.svelte          # NEW — generic bottom sheet
+├── TaskDetail.svelte           # NEW — task detail content
+├── SwipeAction.svelte          # MODIFY — bidirectional swipe support
+├── TaskItem.svelte             # MODIFY — onTap, onStartStop, active indicator
+└── TaskList.svelte             # MODIFY — pass onTap + onStartStop through
+
+src/lib/stores/
+└── tasks.js                    # MODIFY — add startTask(), stopTask()
+
+src/routes/
+└── +page.svelte                # MODIFY — selectedTask, handleStartStop, sheet
+
+src/app.css                     # MODIFY — add --color-active-bg/text tokens
+```
+
+---
+
+---
+
+# Undo Toast — Design
+
+**Implements:** [web-cli-parity.md](web-cli-parity.md) 1.4 (Uncomplete / Revert)
+**New component:** `Toast.svelte`
+**Modifies:** `+page.svelte`, `TaskDetail.svelte`
+
+---
+
+## 17. Overview
+
+Two paths to undo a completion:
+
+1. **Undo toast** — appears immediately after completing a task (swipe or
+   checkbox). Shows the task description and an "Undo" button. Auto-dismisses
+   after 5 seconds. This is the fast path for accidental completions.
+2. **Uncomplete in detail view** — available on any completed task via the
+   Completed report. The "Uncomplete" action button in `TaskDetail` (already
+   designed in section 3.7) handles this path.
+
+Both paths use the same API call: `PUT /tasks/:uuid` with
+`{ status: 'P', end: null }`.
+
+```
+┌─────────────────────────────────┐
+│  Task list                      │
+│                                 │
+│  ...                            │
+│                                 │
+├─────────────────────────────────┤
+│ ┌─────────────────────────────┐ │
+│ │ ✓ "Buy groceries"   [Undo] │ │  ← toast
+│ └─────────────────────────────┘ │
+├─────────────────────────────────┤
+│  InputBar                       │
+└─────────────────────────────────┘
+```
+
+The toast sits above the InputBar, inside the scroll area's bottom margin.
+
+---
+
+## 18. Component: `Toast.svelte`
+
+A generic, reusable toast/snackbar. Not specific to undo — can be used for
+any brief feedback message with an optional action button.
+
+### 18.1 Interface
+
+```typescript
+interface ToastProps {
+  message: string
+  action?: { label: string, handler: () => void }
+  duration?: number    // auto-dismiss ms, default 5000. 0 = no auto-dismiss
+  onDismiss: () => void
+}
+```
+
+### 18.2 Behavior
+
+- Appears with a slide-up + fade-in animation from the bottom
+- Auto-dismisses after `duration` ms (default 5s)
+- Dismisses immediately if the action button is tapped (after calling handler)
+- Dismisses on swipe-right (quick manual dismiss without action)
+- Only one toast is visible at a time. A new toast replaces the current one
+  (the previous action is lost — same as Android snackbar)
+
+### 18.3 Position
+
+- Fixed above the InputBar: `bottom: calc(InputBar height + spacing)`
+- Horizontally: full width with `var(--spacing-md)` margin on each side
+- On desktop (>768px): capped at `--content-max-width` and centered
+
+### 18.4 Layout
+
+```svelte
+<div class="toast" class:visible transition:fly={{ y: 20, duration: 200 }}>
+  <span class="toast-message">{message}</span>
+  {#if action}
+    <button class="toast-action" on:click={handleAction}>
+      {action.label}
+    </button>
+  {/if}
+</div>
+```
+
+### 18.5 CSS
+
+```css
+.toast {
+  position: fixed;
+  bottom: calc(3.5rem + var(--spacing-md));  /* above InputBar */
+  left: var(--spacing-md);
+  right: var(--spacing-md);
+  max-width: var(--content-max-width);
+  margin: 0 auto;
+  display: flex;
+  align-items: center;
+  justify-content: space-between;
+  gap: var(--spacing-md);
+  padding: var(--spacing-sm) var(--spacing-md);
+  background-color: var(--bg-tertiary);
+  border: 1px solid var(--border-color);
+  border-radius: var(--border-radius);
+  box-shadow: var(--shadow-md);
+  z-index: 40;  /* below sheet (50) but above content */
+}
+
+.toast-message {
+  font-size: var(--font-size-sm);
+  color: var(--text-primary);
+  min-width: 0;
+  overflow: hidden;
+  text-overflow: ellipsis;
+  white-space: nowrap;
+}
+
+.toast-action {
+  font-size: var(--font-size-sm);
+  font-weight: 600;
+  color: var(--color-primary);
+  background: none;
+  border: none;
+  cursor: pointer;
+  padding: var(--spacing-xs) var(--spacing-sm);
+  border-radius: 0.25rem;
+  white-space: nowrap;
+  min-width: unset;
+  min-height: 36px;  /* touch target */
+}
+
+.toast-action:hover {
+  background-color: var(--bg-secondary);
+}
+```
+
+---
+
+## 19. Undo Toast Integration
+
+### 19.1 State in `+page.svelte`
+
+```typescript
+/** @type {{ uuid: string, description: string } | null} */
+let undoToast = null;
+```
+
+### 19.2 Completion Flow Change
+
+When a task is completed, stash its info for the toast before removing it from
+the list:
+
+```javascript
+async function handleComplete(uuid) {
+  const task = tasks.find(t => t.uuid === uuid);
+  if (!task) return;
+
+  try {
+    await tasksStore.complete(uuid);
+    // Show undo toast
+    undoToast = { uuid: task.uuid, description: task.description };
+  } catch (error) {
+    console.error('Failed to complete task:', error);
+  }
+}
+```
+
+### 19.3 Undo Handler
+
+```javascript
+async function handleUndo() {
+  if (!undoToast) return;
+  const { uuid } = undoToast;
+  undoToast = null;  // dismiss toast immediately
+
+  try {
+    await tasksStore.updateTask(uuid, { status: 'P', end: null });
+    // Reload current report to show the restored task
+    await loadReport(activeReport);
+  } catch (error) {
+    console.error('Failed to undo completion:', error);
+  }
+}
+```
+
+### 19.4 Template
+
+```svelte
+{#if undoToast}
+  <Toast
+    message={'Completed "' + undoToast.description + '"'}
+    action={{ label: 'Undo', handler: handleUndo }}
+    onDismiss={() => undoToast = null}
+  />
+{/if}
+```
+
+### 19.5 Edge Cases
+
+- **Completing another task while toast is showing:** Replace the toast. The
+  previous undo opportunity is lost. This matches the standard snackbar pattern
+  — keeping a queue adds complexity for a rare scenario.
+- **Completing a recurring task:** The toast shows "Completed" with undo. If
+  undo is tapped, the completion is reverted but the spawned next instance is
+  NOT automatically deleted. The user may end up with a duplicate. This is
+  acceptable — it matches the CLI behavior where `undo` after `done` on a
+  recurring task restores the completed instance but leaves the new one. The
+  detail view can be used to clean up.
+- **Toast while bottom sheet is open:** The toast should appear below the sheet
+  scrim (z-index 40 < sheet 50). If the user completes from the detail view's
+  action button, close the sheet first, then show the toast.
+
+---
+
+# Delete Confirmation — Design
+
+**Implements:** [web-cli-parity.md](web-cli-parity.md) 1.5 (Delete Confirmation)
+**New component:** `ConfirmDialog.svelte`
+**Modifies:** `+page.svelte`, `TaskDetail.svelte`
+
+---
+
+## 20. Overview
+
+A confirmation dialog that appears before any delete action. Shows the task
+description so the user can verify what they're about to delete. Uses the native
+`<dialog>` element, matching the `FilterModal` pattern.
+
+```
+ ┌──────────────────────────────┐
+ │                              │
+ │  Delete task?                │
+ │                              │
+ │  "Buy groceries"             │
+ │                              │
+ │  This cannot be undone.      │
+ │                              │
+ │      [Cancel]    [Delete]    │
+ │                              │
+ └──────────────────────────────┘
+```
+
+---
+
+## 21. Component: `ConfirmDialog.svelte`
+
+A generic confirmation dialog. Not specific to delete — can be reused for any
+destructive action (bulk operations in Tier 2, etc.).
+
+### 21.1 Interface
+
+```typescript
+interface ConfirmDialogProps {
+  title: string
+  message: string           // task description or details to show
+  detail?: string           // secondary text (e.g. "This cannot be undone.")
+  confirmLabel: string      // button text, e.g. "Delete"
+  confirmVariant: 'danger' | 'primary'  // button color
+  onConfirm: () => void
+  onCancel: () => void
+}
+```
+
+Exposed method: `open()` — opens the dialog (matches FilterModal pattern).
+
+### 21.2 Template
+
+```svelte
+<dialog bind:this={dialogEl} class="confirm-dialog" on:click={handleBackdropClick}>
+  <div class="dialog-content">
+    <h3 class="dialog-title">{title}</h3>
+
+    <p class="dialog-message">"{message}"</p>
+
+    {#if detail}
+      <p class="dialog-detail">{detail}</p>
+    {/if}
+
+    <div class="dialog-actions">
+      <button class="btn btn-ghost" on:click={handleCancel} type="button">
+        Cancel
+      </button>
+      <button class="btn btn-{confirmVariant}" on:click={handleConfirm} type="button">
+        {confirmLabel}
+      </button>
+    </div>
+  </div>
+</dialog>
+```
+
+### 21.3 Behavior
+
+- Opens via `dialogEl.showModal()` — blocks interaction, provides backdrop
+- Closes on Cancel, Confirm, Escape, or backdrop click
+- Confirm calls `onConfirm` then closes
+- Cancel/Escape/backdrop calls `onCancel` then closes
+- Auto-focuses the Cancel button on open (safe default — user must deliberately
+  choose Delete)
+
+### 21.4 CSS
+
+```css
+.confirm-dialog {
+  border: none;
+  border-radius: var(--border-radius);
+  background: transparent;
+  padding: 0;
+  margin: auto;
+  max-width: min(360px, calc(100vw - 2rem));
+  width: 100%;
+}
+
+.confirm-dialog::backdrop {
+  background: rgba(0, 0, 0, 0.5);
+}
+
+.dialog-content {
+  background-color: var(--bg-primary);
+  border: 1px solid var(--border-color);
+  border-radius: var(--border-radius);
+  box-shadow: var(--shadow-lg);
+  padding: var(--spacing-lg);
+}
+
+.dialog-title {
+  font-size: var(--font-size-lg);
+  font-weight: 600;
+  color: var(--text-primary);
+  margin: 0 0 var(--spacing-md) 0;
+}
+
+.dialog-message {
+  font-size: var(--font-size-base);
+  color: var(--text-primary);
+  margin: 0 0 var(--spacing-xs) 0;
+  word-break: break-word;
+}
+
+.dialog-detail {
+  font-size: var(--font-size-sm);
+  color: var(--text-secondary);
+  margin: 0 0 var(--spacing-lg) 0;
+}
+
+.dialog-actions {
+  display: flex;
+  justify-content: flex-end;
+  gap: var(--spacing-sm);
+}
+
+.btn {
+  padding: var(--spacing-sm) var(--spacing-md);
+  border: none;
+  border-radius: var(--border-radius);
+  font-size: var(--font-size-sm);
+  font-family: inherit;
+  font-weight: 500;
+  cursor: pointer;
+  min-height: 40px;
+  min-width: unset;
+}
+
+.btn-ghost {
+  background: none;
+  color: var(--text-secondary);
+}
+
+.btn-ghost:hover {
+  background-color: var(--bg-secondary);
+  color: var(--text-primary);
+}
+
+.btn-danger {
+  background-color: var(--color-danger);
+  color: white;
+}
+
+.btn-danger:hover {
+  opacity: 0.9;
+}
+```
+
+---
+
+## 22. Delete Flow Integration
+
+### 22.1 State in `+page.svelte`
+
+```typescript
+/** @type {{ uuid: string, description: string } | null} */
+let deleteTarget = null;
+
+/** @type {ConfirmDialog} */
+let confirmDialog;
+```
+
+### 22.2 Triggering Delete
+
+Delete is triggered from the TaskDetail action buttons. The `onDelete` callback
+sets the target and opens the dialog:
+
+```javascript
+function handleDeleteRequest(uuid) {
+  const task = tasks.find(t => t.uuid === uuid)
+    ?? (selectedTask?.uuid === uuid ? selectedTask : null);
+  if (!task) return;
+
+  deleteTarget = { uuid: task.uuid, description: task.description };
+  confirmDialog.open();
+}
+```
+
+### 22.3 Confirm/Cancel Handlers
+
+```javascript
+async function handleDeleteConfirm() {
+  if (!deleteTarget) return;
+  const { uuid } = deleteTarget;
+  deleteTarget = null;
+
+  // Close the bottom sheet if it's open
+  selectedTask = null;
+
+  try {
+    await tasksStore.deleteTask(uuid);
+  } catch (error) {
+    console.error('Failed to delete task:', error);
+  }
+}
+
+function handleDeleteCancel() {
+  deleteTarget = null;
+  // Bottom sheet stays open — user cancelled
+}
+```
+
+### 22.4 Template
+
+```svelte
+<ConfirmDialog
+  bind:this={confirmDialog}
+  title="Delete task?"
+  message={deleteTarget?.description ?? ''}
+  detail="This cannot be undone."
+  confirmLabel="Delete"
+  confirmVariant="danger"
+  onConfirm={handleDeleteConfirm}
+  onCancel={handleDeleteCancel}
+/>
+```
+
+### 22.5 Z-Index Layering
+
+The dialog uses `<dialog>` with `showModal()`, which renders to the top-layer
+— it will appear above the bottom sheet scrim (z-index 50) and above the toast
+(z-index 40) without any manual z-index management.
+
+```
+Top layer (browser-managed):  ConfirmDialog (<dialog> showModal)
+z-index 51:                   BottomSheet panel
+z-index 50:                   BottomSheet scrim
+z-index 40:                   Toast
+Content:                      TaskList, Header, InputBar
+```
+
+---
+
+## 23. Interaction Flows
+
+### 23.1 Undo After Completion
+
+```mermaid
+sequenceDiagram
+    participant User
+    participant TaskItem
+    participant Page
+    participant Toast
+    participant API
+
+    User->>TaskItem: swipe right / checkbox
+    TaskItem->>Page: onComplete(uuid)
+    Page->>API: POST /tasks/:uuid/complete
+    Page->>Page: remove task from list
+    Page->>Toast: show "Completed 'Buy groceries'" + [Undo]
+    Toast-->>User: toast visible for 5s
+
+    alt User taps Undo
+        User->>Toast: tap [Undo]
+        Toast->>Page: handleUndo()
+        Page->>API: PUT /tasks/:uuid {status: 'P', end: null}
+        Page->>Page: reload report (task reappears)
+        Toast-->>User: toast dismissed
+    else Toast expires
+        Toast-->>Page: onDismiss()
+        Page->>Page: undoToast = null
+    end
+```
+
+### 23.2 Delete from Detail View
+
+```mermaid
+sequenceDiagram
+    participant User
+    participant Detail as TaskDetail
+    participant Page
+    participant Dialog as ConfirmDialog
+    participant API
+
+    User->>Detail: tap [Delete] button
+    Detail->>Page: onDelete(uuid)
+    Page->>Dialog: open()
+    Dialog-->>User: "Delete task? 'Buy groceries'"
+
+    alt User confirms
+        User->>Dialog: tap [Delete]
+        Dialog->>Page: onConfirm()
+        Page->>Page: close bottom sheet
+        Page->>API: DELETE /tasks/:uuid
+        Page->>Page: remove task from list
+    else User cancels
+        User->>Dialog: tap [Cancel] / Escape / backdrop
+        Dialog->>Page: onCancel()
+        Note over Page: bottom sheet stays open
+    end
+```
+
+---
+
+## 24. Technical Decisions
+
+### ADR-12: `<dialog>` for confirmation, `<div>` for toast
+
+**Context:** Both components are overlaid UI. Should they use the same pattern?
+
+**Decision:** `ConfirmDialog` uses `<dialog>` with `showModal()`. `Toast` uses
+a positioned `<div>`.
+
+**Rationale:**
+- The confirmation dialog IS a modal — it blocks interaction and requires a
+  deliberate choice. `<dialog>` provides backdrop, focus trapping, and Escape
+  handling for free.
+- The toast is NOT a modal — the user can ignore it and keep interacting with
+  the task list. A `<dialog>` would be wrong here because it would block
+  interaction.
+- Different semantics → different elements.
+
+### ADR-13: Single toast, not a queue
+
+**Context:** What happens if two tasks are completed quickly? Should toasts
+queue?
+
+**Decision:** Latest toast replaces the current one. No queue.
+
+**Rationale:**
+- Queuing toasts adds complexity (queue data structure, stacking layout or
+  sequential display, timing coordination)
+- The scenario is rare — completing two tasks within 5 seconds
+- When it does happen, the user most likely wants to undo the most recent one
+- Matches Android snackbar behavior, which is the established pattern
+
+**Trade-off:** The undo opportunity for the first completion is lost when the
+second one fires. Acceptable — the Completed report + Uncomplete button is the
+fallback path.
+
+### ADR-14: Auto-focus Cancel on confirm dialog
+
+**Context:** Which button should be focused when the dialog opens?
+
+**Decision:** Auto-focus Cancel.
+
+**Rationale:** Delete is destructive and irreversible. Focusing Cancel means an
+accidental Enter keypress doesn't delete the task. The user must deliberately
+tab to or click Delete.
+
+---
+
+## 25. Updated File List
+
+Full list combining all Tier 1 designs:
+
+```
+src/lib/components/
+├── BottomSheet.svelte          # NEW — generic bottom sheet (section 2)
+├── TaskDetail.svelte           # NEW — task detail + inline edit (section 3)
+├── Toast.svelte                # NEW — generic toast/snackbar (section 18)
+├── ConfirmDialog.svelte        # NEW — generic confirm dialog (section 21)
+├── SwipeAction.svelte          # MODIFY — bidirectional (section 10)
+├── TaskItem.svelte             # MODIFY — onTap, onStartStop, active indicator
+└── TaskList.svelte             # MODIFY — pass new callbacks through
+
+src/lib/stores/
+└── tasks.js                    # MODIFY — add startTask(), stopTask()
+
+src/routes/
+└── +page.svelte                # MODIFY — all Tier 1 state + handlers
+
+src/app.css                     # MODIFY — add --color-active-bg/text tokens
+```
+
+**New components: 4** (`BottomSheet`, `TaskDetail`, `Toast`, `ConfirmDialog`)
+**Modified components: 4** (`SwipeAction`, `TaskItem`, `TaskList`, `+page.svelte`)
+**Modified stores: 1** (`tasks.js`)
+**Modified styles: 1** (`app.css`)
+
+No new API endpoints — all Tier 1 features use existing endpoints.
+
+---
+
+## 8. Resolved Questions
+
+| # | Question | Resolution |
+|---|----------|------------|
+| Q1 | Should the sheet remember scroll position when the same task is re-opened? | **No.** Always scroll to top on open. |
+| Q2 | Should editing a recurring instance offer "edit this instance" vs "edit template"? | **Yes.** Show a confirmation prompt: "Edit this instance" or "Edit template". See section 3.8. |
+| Q3 | Should we show a loading state in the sheet while an edit is in flight? | **No.** Optimistic updates only. Show error on failure. |
diff --git a/docs/design/web-cli-parity.md b/docs/design/web-cli-parity.md
new file mode 100644
index 0000000..b24e368
--- /dev/null
+++ b/docs/design/web-cli-parity.md
@@ -0,0 +1,533 @@
+# Web CLI Parity — Requirements Spec
+
+**Status:** Draft
+**Last updated:** 2026-02-19
+**Related:** [`cli-ux-improvements.md`](cli-ux-improvements.md) — CLI UX
+improvements being developed in parallel. Features marked with **(CLI dep)**
+depend on or benefit from CLI-side work landing first.
+
+This document covers the features the CLI exposes that the web frontend does
+not. Each section maps a CLI capability to a proposed web feature, with
+acceptance criteria and priority.
+
+---
+
+## Problem Statement
+
+The opal CLI is the primary interface and offers rich task management: in-place
+editing, start/stop timers, detailed task info, project/tag browsing, bulk
+operations, and full sync controls. The web frontend currently only supports
+create, complete, delete, and report-based listing. Users who switch between
+CLI and web hit a wall — most tasks that go beyond "add" and "done" require
+falling back to the terminal.
+
+---
+
+## Tier 1 — Core Gaps (the web feels broken without these)
+
+### 1.1 Task Detail View (`info` equivalent)
+
+**CLI:** `opal info 2` shows every field on a task — UUID, status, description,
+urgency, priority, project, all timestamps (created, modified, started, ended,
+due, scheduled, wait, until), recurrence pattern, parent UUID, and tags.
+
+**Web gap:** Tapping a task does nothing. There is no way to see a task's full
+state.
+
+**User story:** As a user, I want to tap a task to see all of its fields so
+that I can understand its full context without switching to the CLI.
+
+**Acceptance criteria:**
+- Given a task in the list, when I tap it, then a detail view opens showing
+  every non-null field on the task
+- Given a task with a recurrence pattern, when I view its detail, then the
+  recurrence interval and parent template link are visible
+- Given a task with scheduled/wait/until dates, when I view its detail, then
+  those dates are displayed with labels
+- Given a task detail view, when I tap outside or press a close/back control,
+  then the detail view closes and the list is restored
+
+**Interaction:** Bottom sheet — slides up from the bottom of the screen.
+Natural on mobile, avoids a route change, and leaves the task list partially
+visible behind it. Light-dismiss (tap scrim to close).
+
+**Priority:** MUST
+
+---
+
+### 1.2 Task Editing (`modify` / `edit` equivalent)
+
+**CLI:** `opal 2 modify priority:H due:friday` changes attributes inline.
+`opal 2 edit` opens `$EDITOR` with all fields in a structured format.
+
+**Web gap:** There is no way to edit a task after creation. Users must delete
+and recreate to fix a typo or change a due date.
+
+**User story:** As a user, I want to edit any field on an existing task so that
+I can adjust it as my plans change.
+
+**Acceptance criteria:**
+- Given a task detail view, when I tap an editable field, then I can modify its
+  value
+- Given I change a field and confirm, when the update succeeds, then the task
+  list reflects the change
+- Given I change a field and confirm, when the update fails, then the error is
+  shown and the original value is preserved
+- Editable fields: description, project, priority, due, scheduled, wait, until,
+  tags, recurrence (on templates)
+- Read-only fields (displayed but not editable): UUID, created, modified, end,
+  parent UUID, status
+
+**Implementation notes:**
+- Uses `PUT /tasks/:uuid` — already exists in the API
+- For tags, uses `POST /tasks/:uuid/tags` and
+  `DELETE /tasks/:uuid/tags/:tag` — already exist
+- Field editing could be inline (tap field to edit) or form-based (edit mode
+  that makes all fields editable). Inline feels lighter for single-field tweaks.
+
+**Priority:** MUST
+
+---
+
+### 1.3 Start / Stop Timer (`start` / `stop` equivalent)
+
+**CLI:** `opal 1 start` marks a task as actively being worked on (sets `start`
+timestamp). `opal 1 stop` clears it. The `active` report lists started tasks.
+
+**Web gap:** The API endpoints (`POST /tasks/:uuid/start`,
+`POST /tasks/:uuid/stop`) are wired in `endpoints.js` but there are no UI
+controls. The `active` report works in the report picker but users can't
+actually start tasks.
+
+**User story:** As a user, I want to mark a task as "in progress" so that I can
+track what I'm actively working on and see it in the Active report.
+
+**Acceptance criteria:**
+- Given a pending task, when I tap a start control, then the task's start time
+  is set and it appears in the Active report
+- Given a started task, when I tap a stop control, then the start time is
+  cleared
+- Given a started task, when I view it in the list, then there is a visual
+  indicator that it is active (distinguishable from non-started tasks)
+- The start/stop action should be accessible from both the task row and the
+  detail view
+
+**Interaction:** Swipe left to toggle start/stop — mirrors swipe right for
+complete. Also accessible from the detail view (1.1). No visible button on the
+task row.
+
+**Priority:** MUST
+
+---
+
+### 1.4 Uncomplete / Revert (`modify status:pending` equivalent)
+
+**(CLI dep)** — CLI is getting a dedicated `uncomplete` command and a generic
+`undo` (see [IMP-1](cli-ux-improvements.md#imp-1-undo--uncomplete)). The web
+feature should align with however the CLI exposes this so the mental model is
+consistent.
+
+**CLI:** `opal <id> modify status:pending` reverts a completed task. IMP-1
+proposes `opal <id> uncomplete` and `opal undo` as dedicated commands.
+
+**Web gap:** Once a task is completed it disappears from the pending list. The
+only recovery is the `completed` report + CLI. This is also called out in
+`BUGS.md` as a missing feature.
+
+**User story:** As a user, I want to undo an accidental completion so that the
+task reappears in my pending list.
+
+**Acceptance criteria:**
+- Given a completed task (visible in the Completed report), when I tap an
+  uncomplete action, then the task's status reverts to pending and it
+  reappears in the pending list
+- Given I just completed a task, when I tap undo within a brief window (e.g.
+  toast with undo button), then the task is reverted without navigating to the
+  Completed report
+
+**Implementation notes:**
+- Uses `PUT /tasks/:uuid` with `{"status": "pending"}` — works today
+- The undo toast after completion is a UX nicety but not strictly required for
+  parity
+- If CLI IMP-1 lands an undo log table, the web could use the same mechanism
+  for a more robust undo (revert any action, not just completion)
+
+**Priority:** MUST
+
+---
+
+### 1.5 Delete Confirmation
+
+**(CLI dep)** — CLI is improving confirmation prompts to show matched tasks
+before confirming (see [IMP-3](cli-ux-improvements.md#imp-3-show-matched-tasks-in-confirmations)).
+The web confirmation should follow the same pattern.
+
+**CLI:** `opal delete` always prompts `Proceed? (y/N)` before deleting. IMP-3
+proposes showing the affected task(s) in the confirmation.
+
+**Web gap:** Delete is instant with no confirmation. There is no undo.
+
+**User story:** As a user, I want a confirmation before deleting a task so that
+I don't lose work by accident.
+
+**Acceptance criteria:**
+- Given I trigger a delete action, when the confirmation appears, then I must
+  explicitly confirm before the delete proceeds
+- Given I dismiss the confirmation, then the task is not deleted
+- The confirmation should show the task description (matching CLI IMP-3's
+  approach of showing what will be affected)
+
+**Priority:** MUST
+
+---
+
+## Tier 2 — CLI Parity (brings the web up to feature-complete)
+
+### ~~2.1 Projects View~~ — DEFERRED
+
+### ~~2.2 Tags View~~ — DEFERRED
+
+Projects and tags browsing is deferred. The existing filter syntax
+(`project:foo`, `+tag`) covers this adequately for now. When filter
+autocomplete is added later, discoverability will improve without needing
+dedicated views.
+
+---
+
+### 2.3 Display All Date Fields on Task Items
+
+**CLI:** `opal info` and the table display show scheduled, wait, until, and
+start dates when present. The `waiting` report makes sense because you can see
+*when* the wait expires.
+
+**Web gap:** Only the due date is shown on task rows. Scheduled, wait, until,
+and start dates are invisible. Users can set them via CLI syntax in the input
+bar but can't see them afterward.
+
+**User story:** As a user, I want to see all relevant dates on a task so that I
+understand when it's scheduled, when it becomes visible, and when it expires.
+
+**Acceptance criteria:**
+- Given a task with a `scheduled` date, then a "Scheduled: <date>" indicator
+  appears on the task row
+- Given a task with a `wait` date, then a "Wait: <date>" indicator appears
+- Given a task with an `until` date, then an "Until: <date>" indicator appears
+- Given a task with a `start` time set, then an "Active since <time>" or
+  similar indicator appears
+- Date fields that are null are not shown (no empty labels)
+- The detail view (1.1) shows all dates; the task row shows them in a
+  compact/abbreviated form
+
+**Priority:** SHOULD
+
+---
+
+### 2.4 Recurrence Display and Management
+
+**(CLI dep)** — CLI is improving recurring task feedback on completion (see
+[IMP-7](cli-ux-improvements.md#imp-7-recurring-task-feedback)). The web should
+show equivalent feedback when completing a recurring task.
+
+**CLI:** `opal add "standup" due:mon recur:1w` creates a recurring template +
+first instance. `opal template` and `opal recurring` list them. Completing an
+instance spawns the next one. `opal edit <id>` on an instance can update the
+template's recurrence pattern.
+
+**Web gap:** Recurring tasks can be created via CLI syntax in the input bar, and
+the `recurring`/`template` reports work, but:
+- There is no visual indicator that a task is a recurring instance
+- There is no way to see or navigate to the parent template
+- There is no way to edit the recurrence pattern
+- Completing a recurring task gives no feedback about the next instance
+
+**User story:** As a user, I want to see which tasks are recurring, view their
+schedule, and manage the recurrence pattern so that I can adjust repeating
+commitments.
+
+**Acceptance criteria:**
+- Given a recurring instance, when I view it in the list, then a recurrence
+  icon or badge is visible
+- Given a recurring instance, when I open its detail view, then the recurrence
+  interval and parent template are shown
+- Given a recurring template, when I open its detail view, then I can edit the
+  recurrence interval
+- Given I complete a recurring instance, then the next instance is
+  automatically created (this already works server-side; just verify the list
+  refreshes to show it)
+- Given I complete a recurring instance, then a toast or inline message shows
+  the next instance's due date (mirrors CLI IMP-7)
+
+**Priority:** SHOULD
+
+---
+
+### ~~2.5 Sync Controls~~ — DEFERRED
+
+Sync is deprioritized. The web has no client-side task parsing, so offline
+functionality is non-functioning. The web fetches directly from the server on
+every action — sync is only relevant if we move to an offline-first model,
+which is not planned.
+
+---
+
+### 2.6 Bulk Operations (`opal 1 2 3 modify ...` / `opal +tag done`)
+
+**CLI:** Filters and numeric IDs can target multiple tasks.
+`opal +urgent done` completes all tasks tagged `urgent`.
+`opal 1 2 3 modify project:sprint-2` moves three tasks at once.
+The CLI prompts for confirmation when multiple tasks are affected.
+
+**Web gap:** All actions are single-task only. No multi-select, no batch
+complete, no batch modify.
+
+**User story:** As a user, I want to select multiple tasks and perform an
+action on all of them so that I can manage tasks efficiently.
+
+**Acceptance criteria:**
+- Given I enter selection mode (e.g., long-press a task), then I can tap
+  additional tasks to add them to the selection
+- Given I have tasks selected, then I can batch-complete, batch-delete, or
+  batch-modify (at minimum: change project, add/remove tag, change priority)
+- Given a batch action targets 2+ tasks, then a confirmation prompt appears
+  before executing
+- Given I tap outside the selection or press a cancel control, then selection
+  mode is exited
+
+**Priority:** SHOULD
+
+---
+
+## Tier 3 — Power User & Polish
+
+### 3.1 Keyboard Shortcuts
+
+**CLI:** The CLI is entirely keyboard-driven by nature.
+
+**Web gap:** No keyboard shortcuts exist. Desktop users must use the mouse for
+everything.
+
+**User story:** As a desktop user, I want keyboard shortcuts so that I can
+manage tasks without reaching for the mouse.
+
+**Suggested bindings:**
+
+| Key | Action |
+|-----|--------|
+| `n` | Focus the input bar (new task) |
+| `j` / `k` | Move selection down / up in task list |
+| `x` | Complete selected task |
+| `e` | Open detail/edit for selected task |
+| `d` | Delete selected task (with confirmation) |
+| `s` | Start/stop selected task |
+| `Escape` | Close detail view / deselect / blur input |
+| `/` | Open filter modal |
+
+**Acceptance criteria:**
+- Given I press `n` when not focused on an input, then the input bar is focused
+- Given I press `j`/`k`, then the visual selection moves through the task list
+- Given I press `x` with a task selected, then that task is completed
+- Shortcuts are disabled when an input or textarea is focused (except Escape)
+
+**Priority:** COULD
+
+---
+
+### 3.2 Description Search
+
+**CLI:** Filtering by tags, project, priority, and status covers structured
+attributes, but there's no full-text description search in the CLI either.
+
+**Web opportunity:** The web could add a search capability that the CLI lacks.
+
+**User story:** As a user, I want to search tasks by description text so that I
+can find a specific task without remembering its tags or project.
+
+**Acceptance criteria:**
+- Given I type in a search field, then the task list filters to tasks whose
+  description contains the search text (case-insensitive)
+- Search can be client-side (filter the loaded report) or server-side (new
+  query param)
+
+**Interaction:** Extends the existing filter syntax. Bare text in the filter
+input is interpreted as a description search. The filter modal becomes
+filter/search — no separate search bar.
+
+**Priority:** COULD
+
+---
+
+### ~~3.3 Display IDs~~ — DROPPED
+
+Not needed. The web uses touch/tap interaction, not keyboard-driven ID
+selection. Display IDs are a CLI affordance that doesn't translate to the web
+interaction model.
+
+---
+
+### ~~3.4 API Key Management~~ — ON HOLD
+
+Blocked on user management investigation. Open questions: Are API keys
+user-scoped? Should we move to per-user databases? This feature should wait
+until the auth/user model is settled.
+
+---
+
+### 3.5 Task Annotations (`annotate` equivalent)
+
+**(CLI dep)** — The CLI is adding `opal <id> annotate "<text>"` (see
+[IMP-11](cli-ux-improvements.md#imp-11-task-annotations)). This requires a
+backend schema change (annotations storage). Once that lands, the web should
+surface annotations.
+
+**CLI (proposed):** `opal 3 annotate "Traced to token expiry"` adds a
+timestamped note. `opal 3 info` shows annotations. IMP-11 notes potential
+integration with jade-depo (the gems note management system).
+
+**Web gap:** No concept of annotations exists. Tasks have only a description
+field for text.
+
+**User story:** As a user, I want to add and view notes on a task so that I can
+record progress and context over time.
+
+**Acceptance criteria:**
+- Given a task detail view (1.1), then any existing annotations are shown as a
+  timestamped list below the task fields
+- Given a task detail view, when I tap an "Add note" control, then I can enter
+  annotation text and it is saved with a timestamp
+- Annotations are ordered newest-first or oldest-first (decide which)
+- Annotations are read-only after creation (no inline editing — `denotate`
+  removes the latest)
+
+**Decisions:**
+- Annotations are visible only in the detail view (1.1), not on the task row.
+- jade-depo integration is not relevant to the web UI at this time.
+
+**Priority:** COULD (blocked on CLI IMP-11 landing the backend schema)
+
+---
+
+### 3.6 Task History (`log` equivalent)
+
+**(CLI dep)** — The CLI is adding `opal <id> log` (see
+[IMP-12](cli-ux-improvements.md#imp-12-task-history)). This reads the existing
+`change_log` table which already exists for sync.
+
+**CLI (proposed):** `opal 3 log` shows timestamped change history (created,
+modified, completed, etc.).
+
+**Web gap:** No way to see what happened to a task over time.
+
+**User story:** As a user, I want to see a task's change history so that I can
+understand when and how it was modified.
+
+**Acceptance criteria:**
+- Given a task detail view (1.1), then a "History" section or tab shows the
+  change log for that task
+- Each entry shows: timestamp, change type, and what changed (e.g.,
+  "priority: default -> high")
+- History is read-only
+
+**Implementation notes:**
+- The `change_log` table already exists for sync. This likely needs a new API
+  endpoint (`GET /tasks/:uuid/log` or similar) to expose it.
+- Alternatively, the change log could be included in the task detail response.
+
+**Priority:** COULD (blocked on CLI IMP-12 / API endpoint)
+
+---
+
+### 3.7 Configurable Default Report
+
+**CLI:** `default_report` in `opal.yml` controls what `opal` with no arguments
+shows (default: `list`). `default_filter` controls the base filter.
+
+**Web gap:** The web always starts on the `list` report. There is no user
+preference for the landing view.
+
+**User story:** As a user, I want to choose which report I see when I open the
+app so that my most-used view loads first.
+
+**Acceptance criteria:**
+- Given I choose a default report in settings, then the app opens to that
+  report on next launch
+- The preference is stored in localStorage (no backend change needed)
+
+**Priority:** COULD
+
+---
+
+## Non-Functional Requirements
+
+| # | Requirement | Priority |
+|---|-------------|----------|
+| NFR-1 | All new features must work on Android Chrome and desktop Chrome/Firefox (per architecture doc) | MUST |
+| NFR-2 | Task detail and edit interactions must be touch-friendly (44px minimum tap targets) | MUST |
+| NFR-3 | Editing a task must be optimistic — UI updates immediately, rolls back on failure | SHOULD |
+| NFR-4 | Keyboard shortcuts must not conflict with browser defaults (Ctrl+T, etc.) | MUST |
+| NFR-5 | New features must work with all three themes (Obsidian, Paper, Midnight) | MUST |
+| NFR-6 | No new API endpoints are required for Tier 1 — all endpoints already exist | N/A |
+
+---
+
+## Constraints & Assumptions
+
+**Constraints:**
+- Single-screen architecture per the existing design doc — no new routes for
+  projects/tags (use sheets/modals/filters instead)
+- Server-side parsing and sorting — the frontend stays a thin shell
+- SvelteKit + Vite stack, Svelte 5 runes
+
+**Assumptions:**
+- The `PUT /tasks/:uuid` endpoint accepts partial updates (only fields present
+  in the request body are changed)
+- The working set display IDs are not currently exposed via the API; Tier 3.3
+  would require an API change
+- Sync transport (pull/push) works correctly; the gap is only in applying
+  pulled changes to the store
+
+---
+
+## Cross-Reference: CLI UX Improvements
+
+The following items from [`cli-ux-improvements.md`](cli-ux-improvements.md)
+directly affect web features in this spec:
+
+| CLI IMP | CLI Feature | Web Impact |
+|---------|-------------|------------|
+| IMP-1 | Undo / uncomplete | Enables 1.4 (uncomplete). If undo log is stored in DB, web can use same mechanism. |
+| IMP-2 | Better `add` feedback | Web already shows the created task in-list. No direct web change, but if the API response for `POST /tasks/parse` is enriched (display ID, parsed modifiers), the web could show a richer confirmation toast. |
+| IMP-3 | Show matched tasks in confirmations | Pattern for 1.5 (delete confirmation) and 2.6 (bulk ops). |
+| IMP-5 | Handle colons in descriptions | Affects web input bar — same parsing runs server-side via `/tasks/parse`. No web change needed, but web benefits automatically. |
+| IMP-7 | Recurring task feedback | Directly feeds 2.4 (recurrence display). |
+| IMP-9 | Relative dates in CLI | Web already does this. No change needed. |
+| IMP-11 | Task annotations | Enables 3.5 (annotations on web). Blocked on backend schema. |
+| IMP-12 | Task history | Enables 3.6 (history on web). Blocked on API endpoint. |
+
+Items from the CLI spec with **no web impact**: IMP-4 (delete ID resolution
+bug), IMP-6 (consistent error codes), IMP-8 (shell completions), IMP-10
+(dry-run flag), IMP-13 (version command).
+
+---
+
+## Out of Scope
+
+- Collaboration / multi-user sharing
+- Notifications, reminders, or push alerts
+- Custom fields or metadata
+- Drag-to-reorder (ordering is report/urgency-driven)
+- Offline-first / IndexedDB task storage (tasks are server-side only)
+- iOS Safari support
+
+---
+
+## Open Questions Summary
+
+| # | Question | Blocks | Status |
+|---|----------|--------|--------|
+| ~~Q1~~ | ~~Detail view format~~ | ~~1.1~~ | **Resolved** — bottom sheet |
+| ~~Q2~~ | ~~Start/stop control placement~~ | ~~1.3~~ | **Resolved** — swipe left |
+| ~~Q3~~ | ~~Projects/tags view format~~ | ~~2.1, 2.2~~ | **Resolved** — deferred, use filters |
+| ~~Q4~~ | ~~Description search format~~ | ~~3.2~~ | **Resolved** — extend filter syntax |
+| ~~Q5~~ | ~~Display IDs~~ | ~~3.3~~ | **Resolved** — dropped |
+| ~~Q6~~ | ~~Annotation visibility~~ | ~~3.5~~ | **Resolved** — detail view only |
+| ~~Q7~~ | ~~jade-depo integration~~ | ~~3.5~~ | **Resolved** — not for web |
diff --git a/opal-web/src/lib/api/client.js b/opal-web/src/lib/api/client.js
index 93220b4..43fd67d 100644
--- a/opal-web/src/lib/api/client.js
+++ b/opal-web/src/lib/api/client.js
@@ -18,9 +18,10 @@ export const API_BASE = import.meta.env.VITE_API_URL || 'http://localhost:8080';
 export async function apiRequest(endpoint, options = {}) {
 	const auth = get(authStore);
 	
+	/** @type {Record<string, string>} */
 	const headers = {
 		'Content-Type': 'application/json',
-		...options.headers
+		.../** @type {Record<string, string>} */ (options.headers)
 	};
 	
 	if (auth.accessToken) {
diff --git a/opal-web/src/lib/api/endpoints.js b/opal-web/src/lib/api/endpoints.js
index 22ae267..a8fbf4f 100644
--- a/opal-web/src/lib/api/endpoints.js
+++ b/opal-web/src/lib/api/endpoints.js
@@ -76,7 +76,7 @@ export const tasks = {
 
 	/**
 	 * @param {string} input - Raw opal CLI syntax
-	 * @returns {Promise<Task>}
+	 * @returns {Promise<{task?: Task} & Task>}
 	 */
 	async parse(input) {
 		return apiRequest('/tasks/parse', {
@@ -143,7 +143,7 @@ export const sync = {
 	},
 	
 	/**
-	 * @param {Task[]} tasks
+	 * @param {Partial<Task>[]} tasks
 	 * @param {string} clientId
 	 * @returns {Promise<{processed: number, conflicts: number}>}
 	 */
diff --git a/opal-web/src/lib/stores/sync.js b/opal-web/src/lib/stores/sync.js
index 71be2dc..1a67fba 100644
--- a/opal-web/src/lib/stores/sync.js
+++ b/opal-web/src/lib/stores/sync.js
@@ -56,7 +56,8 @@ function createSyncStore() {
 				const state = loadSyncState();
 				const queue = getQueue();
 
-				let result = {
+				/** @type {SyncResult} */
+				const result = {
 					pulled: 0,
 					pushed: 0,
 					conflicts_resolved: 0,
@@ -70,7 +71,7 @@ function createSyncStore() {
 						await syncAPI.push(tasks, state.clientId);
 						clearQueue();
 						result.pushed = queue.length;
-					} catch (error) {
+					} catch (/** @type {any} */ error) {
 						result.errors.push(`Failed to push queue: ${error.message}`);
 					}
 				}
@@ -79,7 +80,7 @@ function createSyncStore() {
 					const changes = await syncAPI.getChanges(state.lastSync, state.clientId);
 					result.pulled = changes.length;
 					// TODO: Apply changes to local state
-				} catch (error) {
+				} catch (/** @type {any} */ error) {
 					result.errors.push(`Failed to pull changes: ${error.message}`);
 				}
 
@@ -95,7 +96,7 @@ function createSyncStore() {
 				}));
 
 				return result;
-			} catch (error) {
+			} catch (/** @type {any} */ error) {
 				update(state => ({
 					...state,
 					status: 'error',
diff --git a/opal-web/src/lib/stores/tasks.js b/opal-web/src/lib/stores/tasks.js
index 91dd433..c84bb4b 100644
--- a/opal-web/src/lib/stores/tasks.js
+++ b/opal-web/src/lib/stores/tasks.js
@@ -42,7 +42,7 @@ function createTasksStore() {
 		async parseAndCreate(input) {
 			try {
 				const result = await tasksAPI.parse(input);
-				const created = result.task ?? result;
+				const created = /** @type {Task} */ (result.task ?? result);
 				update(tasks => [created, ...tasks]);
 				return created;
 			} catch (error) {
@@ -64,7 +64,7 @@ function createTasksStore() {
 
 		/**
 		 * Optimistic create — queues offline on failure.
-		 * @param {Partial<Task>} task
+		 * @param {Task} task
 		 */
 		async add(task) {
 			try {
@@ -172,6 +172,7 @@ export const completedTasks = derived(
 export const tasksByProject = derived(
 	tasksStore,
 	$tasks => {
+		/** @type {Record<string, Task[]>} */
 		const grouped = {};
 		$tasks.forEach(task => {
 			const project = task.project || 'No Project';