Automating GWR Delay Repay claims by driving a real Firefox on an on-demand AWS host over VNC, so a slow/interactive web task can be run (and watched) reliably. Working dir: /home/john/delayrepay (README there for tool-level detail). Built over the 2026-08-27 and 2026-08-28 sessions.
Goal: fire one command, it provisions a browser host, drives the claim, and stays viewable from any workstation — with at most one approval and surviving the operator being away 10+ minutes (several claims a month expected, incl. the delayed return leg).
Claim status: see delayrepay/claims for the current state (reference, status, award) of every claim submitted — the single source of truth, kept in sync with GWR's own Claim History page. Notes below keep only ticket/journey evidence, not ongoing status.
Latest browser host — 2026-09-15: maitake (i-02f5a709874764f11, eu-central-1) is TERMINATED at John's request; no longer needed. See EC2 Host Registry for lifecycle status.
TODO — 28 Sep 2026 outbound leg (Bristol Parkway → Paddington): run the claim. Train 1L04 (SX), booked Bristol Parkway dep 06:59, booked Paddington arr 08:16 (working time). GPS shows departure ~06:59, held stops near Reading (~08:02–08:05, ~08:13–08:19), then arrival — stationary ~300 m from Paddington by 08:46:08, walking on the concourse by 08:49. Actual arrival ≈ 08:46. Delay ≈ 30 min, on the boundary between GWR's 15–29 and 30–59 min bands — the public timetable/GWR's own recorded time will decide which; WTT working times run ~0.5–1 min tighter. Ticket details not yet gathered — check reclaim/ on WebDAV for a ticket image for this date. To run: fill in claim.conf on kelp and ./run_claim.sh (see Quick start above) — this has to be run from kelp itself, not from a chat session's sandboxed tool access.
TODO — 30 Sep 2026 outbound leg (Bristol Parkway → Paddington): run the claim. Train 1L04 (SX, UID G15040), booked Bristol Parkway dep 06:59, booked Paddington arr 08:16 (working time). GPS shows John at Parkway from ~06:49, stationary until departure ~07:08 (≈9 min late away), a slow crawl in from ~08:26, stopped ~280 m from Paddington at ~08:33:04, walking on the concourse by 08:36. Actual arrival ≈ 08:33. Delay ≈ 17 min — GWR's 15–29 min band, not near a boundary (public timetable may shave ~0.5–1 min). Ticket details not yet gathered — check reclaim/ on WebDAV for a ticket image for this date. To run: fill in claim.conf on kelp and ./run_claim.sh from kelp itself.
2026-10-21 — movement analysis + season-ticket shift. GPS (owntracks) + WTT via pg_query for delayed journeys since the last submitted claim (GWR-2238-489-127, 9 Sep). Candidates (GPS arrival vs booked 1L04 PAD 08:16, or booked return BPW arr): outbound — 28 Sep ~33 min (30–59), 30 Sep ~20 min, 12 Oct ~17 min, 24 Sep ~16 min (NEW; GPS sparse). return — 29 Sep ~52 min (30–59, the strongest of all: ~19:48 dep = 1B32 booked BPW 21:01, GPS arr ~21:53, traced as a continuous held train), 10 Sep ~16 min (borderline — could be the 19:12 1U31 which would be on-time). All other legs arrived within ~0–12 min. Evidence model changed: John now holds a monthly GWR season ticket (Bristol Parkway ↔ London Zones 1–6, type 16A), so claims use the smartcard/season as evidence (the same for every journey in its validity) and pay the season daily-rate proportion, not the old Advance-single amounts. The smartcard/season number is deliberately NOT recorded in notes (sensitive) — supplied at claim time. Validity caveat: the current season runs 07 Oct–06 Nov 2026, so it only covers 12 Oct; the September candidates (24/28/29/30 Sep) need the September season (same smartcard, earlier load — visible in the portal's smartcard-history page).
TODO — get official actual times from an API instead of relying on GPS (added 2026-10-12): prompted by the 12 Oct 1L04 outbound leg, where the GPS-derived arrival (~08:31–08:32 vs booked 08:16) put the delay at 15–17 min, right on GWR's 15-minute threshold, with ±1–2 min of GPS error at the terminus. The WTT tables in the owntracks DB hold scheduled times only. (1) Register for the National Rail Data Portal Historical Service Performance (HSP) API (free, basic auth): serviceMetrics for BPW→PAD in the relevant window, then serviceDetails on the service ID for scheduled vs actual at every stop plus delay reason codes. (2) Add a service_performance(from_crs, to_crs, date, time_window) tool to the misc MCP connector (see misc-server/tools and misc-server/todo) wrapping HSP, so it can be used alongside pg_query and the GPS track; a chat session's sandbox cannot call these APIs directly (network allowlist). (3) Fallbacks if HSP is unsuitable: Realtime Trains API (api.rtt.io; historic access may be restricted), Darwin/OpenLDBWS via Huxley2 (live boards only), Network Rail TRUST feeds (complete but heavy). API details are from memory and unverified — check the provider docs when registering. Related: WTT Train Timetable.
Handover for the historical Flexi delay scan (separate, still open): Historical Flexi Delay Scan — 7 Sep 2026.
Once a claim is submitted, log the reference/status in delayrepay/claims and remove its TODO from here — don't leave a completed TODO paragraph in place; delayrepay/lessons/sessions is where the run itself (host, bugs hit, what was learned) gets written up, not this note.
See also provisioning, toolkit, viewer-setup (+ runnable), lessons (+ sessions). Related: ansible/aws-browser-host, delay-repay-vnc-howto.
WTT Train Timetable — scheduled train times (Network Rail Working Timetable) in the owntracks DB, queryable via the pg_query MCP tool and joinable to GPS locations for scheduled-vs-actual delay calculation. Covers GWML Paddington <-> Bristol Parkway / Swansea / Carmarthen, both directions (down from Paddington and up into Paddington). Examples: the 27 Aug 19:18 Paddington->Bristol Parkway is 1B31 (SX), booked Bristol Parkway 20:27; a Bristol Parkway->Paddington claim joins the up train's booked BRISTOL PARKWAY dep and LONDON PADDINGTON arr (e.g. 1L01 05:52 -> 07:16). Not yet loaded: other destinations/routes.
Ticket evidence: photos of tickets/receipts for a claim are kept on the WebDAV server under reclaim/ (e.g. reclaim/IMG_1484.jpeg for the 27 Aug return leg) — this is the standard location, check there first when a claim needs ticket details.
Cloudflare lab testing: hosts/nameko provides an alternative test VNC environment (1920×1080, responsive, stunnel on port 5901).
Login gotcha + resolution (2026-10-21): the Delay Repay portal (delayrepay.gwr.com) and the main GWR website (gwr.com) are separate logins whose passwords can differ. This caused real confusion: the password stored in pwsafe was the main-site one, which silently failed on the Delay Repay portal, prompting repeated resets. Resolved: John set both accounts to the same password — matching the one in the pushed Firefox profile bundle (~/aws/browser-secrets/ on kelp: key4.db + logins.json) — and updated pwsafe to match. So all four (delayrepay.gwr.com, gwr.com, the pushed profile, pwsafe) now hold the same value, pwsafe is the authoritative record, and it matches the login injected into each provisioned host. If anything is ever out of sync, trust the pwsafe value and re-export the profile bundle from it.