Expose POST /consistency/sweep/remote-all so activity-core can trigger
the workstation ADR-001 remote-all sweep via the bridge tunnel pattern.
Records consistency_sweep_remote_all progress events and documents the
cutover runbook while the local custodian-sync timer remains interim.
Document stale remote sshd forward on Railiance01 :18000 as root cause of
reconnect loop; T03 verified after bridge maintenance cleanup and manual
canaries for hourly RecentlyOnScope and daily WSJF triage.
Persist the Fri-evening→Sun-afternoon automation gap assessment in
history/, and add STATE-WP-0063 (repair broken paths and cluster
reachability) plus STATE-WP-0064 (move State Hub consistency sync to
Railiance01 via activity-core). Workplans registered in State Hub via
fix-consistency.
fix-consistency registered the workstream and tasks and wrote their UUIDs into
the workplan frontmatter/task blocks.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Add /docs/services reference (two-dimension model, persistence, API) and a
pointer note from /docs/tpsc; add it to the Reference nav.
- Add a test asserting first_party.repo_slug resolves to a managed_repos FK
(8 services tests green).
- Mark STATE-WP-0062 tasks done / status finished.
Known classes seeded in the live catalog via the API (Gitea, Postgres as
self-hosted/third-party; State Hub as self-hosted/first-party at Level 2).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Proposed plan to restructure the single TPSC services view into a catalog
classified along two orthogonal dimensions — hosting (self_hosted|cloud_hosted)
and development (first_party|third_party). Common fields live in a core
service_catalog table; dimension-specific data composes via extension tables
(third-party upstream contacts, first-party repo link, cloud data-processing/
GDPR, self-hosted infra). Existing TPSC migrates to (cloud_hosted, third_party)
with /tpsc/* kept as a back-compat view. Includes Services nav section and the
Tier->Level rename scoped to the Service DoM policy.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Proposed plan (status: proposed) for a Suggestion entity with a persisted
relevance/demand counter feeding a WSJF read-model projection. Authored during
ops-warden WP-0012 triage; tracks gated needs as relevance-accruing suggestions
rather than inert todo tasks.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Marks CUST-WP-0003 finished with implementation evidence after verifying the dashboard WHI card, docs, and reference navigation are already present and the hub tasks are done.
Adds preferred workplan REST/event surfaces, legacy-meter telemetry and weekly review summaries, documentation/dashboard terminology updates, dashboard API loading fixes, and close-out sync for STATE-WP-0052 and STATE-WP-0054.
Workstream 0cca23a9-9640-491a-92db-6414db891019 (slug state-wp-0053)
created with status: proposed. Six tasks T01-T06 created and their
ids backfilled into the workplan file's task frontmatter so the
consistency checker links file ↔ DB correctly.
Coordination message sent to codex (state hub message
9d4fe78d-c3c4-4a98-a430-88f9757a0c79) requesting review of scope,
owner confirmation, and a decision on whether to promote from
proposed to ready/active.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Following the CUST-WP-0045 daily-triage cutover, the activity-core
runner now writes a daily progress event with the full WSJF report
nested under detail.report. The only ways to read it today are tail
the working-memory file or curl /progress/ — neither serves the
"sit-down review" use case the triage was designed for.
Proposed dashboard page under the existing Workstreams section:
recent reports table, per-report detail with linked recommendations,
14-day pattern view, action colour cues consistent with the rest of
the dashboard. Read-only; no schema or API changes; reuses the
existing /progress/?event_type=daily_triage endpoint.
Six tasks (T01 skeleton + nav, T02 recent table, T03 detail with
links, T04 colour cues, T05 pattern view, T06 docs). Status:
proposed — awaiting review before workstream registration.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
