claim.gf.cx — own surface, not just a same-zone alias

Date: 2026-05-21 · Status: Option A shipped, Option B parked · Build effort (Option B): ~30 min editorial + scripting

Current state (Option A — shipped 2026-05-21)

claim.gf.cx is bound as an additional Custom Domain on the dare-dev-reports CDN, security layer, and DNS provider sitting in front of dare.co.uk.">CF Pages project — alongside reports.dare.co.uk and devreports.dare.co.uk. The host-binding exists for cookie-zone-alignment so the embedded ask-opus widget can authenticate same-zone with ask-opus.gf.cx.

After today’s Option A fix: - Bare claim.gf.cx/ → 302 to most-recent claim cockpit (currently /dare_claim_cockpit_046414618_2026-05-20) - Any specific path (e.g. claim.gf.cx/dare_claim_cockpit_<id>_<date>) → serves the cockpit unchanged - Mechanism: functions/_middleware.js auto-emitted by dare_dev_reports_publish.py on each publish; checks url.hostname === "claim.gf.cx" and only intercepts the bare path

This is functional but architecturally lazy — claim.gf.cx is still pretending to be the dev-reports catalog with a single-cockpit redirect papered on top.

Option B — claim.gf.cx as its own claim-focused surface

Long-term, claim.gf.cx becomes a dedicated claim-management landing with content distinct from the dev-reports catalog. Three concrete pieces:

Piece 1: Active-claims index at /

Replace the bare-host redirect with an actual index page listing:

• All active claims (one card per claim, sourced from pa_claim_filesystem_init.py output structure)
• Per-claim summary: claim ID, carrier, analyst, status (in-progress / awaiting-response / paid / closed), date opened, next deadline
• One-click into each claim’s full cockpit
• Visual indicators: red for overdue deadlines, amber for “needs steward action this week”, green for “paid + closed”
• Sortable by recency, deadline-urgency, or carrier
• A “+ New claim” button that triggers pa_claim_filesystem_init.py (gates: insurance company picker → carrier-specific document templates)

Piece 2: Claim-scoped Opus widget context

Currently the ask-opus widget on each cockpit uses data-context-id="claim-<id>" — one KB context per claim. Extend this:

• The claim index page itself has a widget at data-context-id="claims-overview" for cross-claim questions (“which claims need attention this week?”, “what’s the total paid across active claims?”)
• Each cockpit’s widget can reference the overview context for portfolio-level coaching
• Wire the widget’s data-context-hint to inject the active claims summary so Opus has visibility into the portfolio without needing to be told each time

Piece 3: Claim-specific dashboard features

Things that make sense on claim.gf.cx but NOT on reports.dare.co.uk:

• Carrier-specific Q&A capture pattern (lifted from pa/equipment/ Q&A — “What does Liberty Mutual mean by ‘reservation of rights’?”, “What’s the typical timeline for an ALE claim?”)
• Document upload + ingest (drag a PDF onto the page, hand to pa_claim_analyse.py)
• Money-flow visualisation across all claims (received vs spent vs owed)
• Deadlines calendar across all claims (rolls up the per-cockpit deadlines bars into a portfolio view)
• Print-to-paper claim packets for filing / mailing (per feedback_paper_cockpit_print_affordance.md)

Implementation sketch (Option B)

Phase 1 — Active-claims index page (~30 min)

New file: ~/bin/pa_claim_index_render.py — generates claim_index.html from the filesystem layout that pa_claim_filesystem_init.py creates.

Scan logic:

from pathlib import Path
import json

CLAIMS_ROOT = Path.home() / "Code/home-projects/pa/home-insurance/claims"
for claim_dir in CLAIMS_ROOT.iterdir():
    if not claim_dir.is_dir(): continue
    sidecar = claim_dir / "claim.json"  # produced by pa_claim_filesystem_init
    if not sidecar.exists(): continue
    claim = json.loads(sidecar.read_text())
    # Emit card with claim metadata, status, next deadline, cockpit URL

Replace the middleware’s bare-host redirect with a static claim_index.html. Middleware then ONLY intercepts to render the index on bare-host requests, OR we make the staging dir serve claim_index.html as the host-specific root via Pages Functions onRequest rewrite.

Phase 2 — Cross-claim widget context (~15 min)

Update pa_claim_index_render.py to embed the ask-opus widget block with data-context-id="claims-overview". The widget already handles per-context KB persistence; nothing changes on the Worker side.

Phase 3 — Editorial features (variable)

Drop in carrier-Q&A, document-upload, money-flow viz one at a time as needs arise. Each is its own micro-build.

Resume conditions

Build Option B when ANY hold:

1. Second active claim — Dan opens a claim with a different carrier (e.g. State Farm, Allstate). The single-cockpit redirect breaks the moment there are 2+ active claims of different context.
2. Cross-claim question Dan wants to ask Opus — e.g. “compare the timelines on Liberty Mutual vs the other carrier”, which needs claims-overview widget context.
3. claim.gf.cx becomes a daily-use surface — currently visited ~weekly. When it crosses into daily, the redirect tax compounds.
4. A specific feature unlocks — e.g. document upload + analysis, money-flow viz. Each piece is independently triggerable.

Sibling memories

• project_pa_claim_cockpit.md — per-claim cockpit pattern (the building block)
• project_pa_document_ingestion_pipeline.md — adjacent infrastructure
• feedback_cf_access_cookies_dont_cross_zones.md — WHY claim.gf.cx is on this same project at all
• feedback_paper_cockpit_print_affordance.md — adjacent feature that lifts cleanly

The aphorism

A subdomain that needs a redirect to make sense is borrowing its identity from somewhere else. The Option-B work upgrades claim.gf.cx from “alias with a band-aid” to “first-class surface with its own job.”