tegwick
4f68c5609f
`ADHOC-YYYY-MM-DD` is unique per date but not per repository, so any two repos
opening an ad-hoc on the same day collide. The 2026-08-26 fleet projection
reset refused 9 records for exactly this reason.
Canon (work-record-types_v0.1, CUST-WP-0066) settled the form as
`{PREFIX}-WP-ADHOC-YYYY-MM-DD`, filename unchanged, and grandfathered existing
ids on the condition they are never *silently* re-derived. This is the explicit
migration that clause allows for.
The hub id is derived from the record id, so a changed id is a different
record: stale state_hub_*_id fields are dropped and fix-consistency re-derives.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
32 lines
929 B
Markdown
32 lines
929 B
Markdown
---
|
|
id: STATE-WP-ADHOC-2026-06-04
|
|
type: workplan
|
|
title: "Ad hoc fixes - 2026-06-04"
|
|
domain: custodian
|
|
repo: state-hub
|
|
status: finished
|
|
owner: codex
|
|
topic_slug: custodian
|
|
created: "2026-06-04"
|
|
updated: "2026-06-04"
|
|
---
|
|
|
|
# Ad hoc fixes - 2026-06-04
|
|
|
|
## Fix Dashboard Overview API Loading
|
|
|
|
```task
|
|
id: STATE-WP-ADHOC-2026-06-04-T01
|
|
status: done
|
|
priority: high
|
|
```
|
|
|
|
The overview page reported `Dashboard data load failed: NetworkError when
|
|
attempting to fetch resource.` even when the API was healthy from Windows.
|
|
The root cause was brittle browser/API connection setup: the dashboard assumed
|
|
`http://127.0.0.1:8000`, while the API CORS defaults allowed only the exact
|
|
dashboard origins on port 3000.
|
|
|
|
Result: the dashboard now resolves its API base from the current browser host
|
|
with explicit query/storage/global overrides, and the API allows common local
|
|
Observable dashboard origins on ports 3000-3005, including IPv6 loopback.
|