Three dated corrections, following the blockquote convention ADR-007 uses:
- Decision 2's merge/refresh dichotomy is not exhaustive. Repository records
took a third shape — cache-only records whose source exists and is reachable
but was never introduced to central. Refreshing would have destroyed them.
- The Context recorded the shared port but not why it was silent: an unbound
ssh -L binds every loopback family, and ExitOnForwardFailure fires only when
every bind fails.
- A new Outcome section states that the ADR's own remediation never landed and
the condition was still live seven weeks later.
Refs CUST-WP-0067-T06
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
rmgr repo-onboard is the missing managed_repos write path. 33 of 44 cache-only
repositories onboarded to central (78 -> 111); the other 11 carry written
dispositions rather than guessed classifications.
T04 uncovered why onboarding only worked from a workstation: the hub resolved
its classification allowed-values file from hardcoded developer checkouts, so
every classification write 500'd in the container. T09 delivers that file.
The local cache database must not be discarded yet — 11 records live only there.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
state-hub-mcp serves SSE on ClusterIP 10.43.110.80:8001, verified from the node
rather than through a tunnel, and reads central's data end-to-end (79 repos).
Remote port map and dev-hub registration repointed off the reverse tunnel.
state-hub-mcp-railiance01 is now safe to remove. state-hub-railiance01 is not:
~120 AGENTS.md files still depend on it until T07.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Remote repointing turned out to be larger than a config change. The port map
is prose copied into ~120 AGENTS.md files with no generator behind it, and the
Helm chart deploys no MCP server on central, so remote dev-hub exists only as
a reverse tunnel to the workstation.
Global agent instructions repointed to the in-cluster ClusterIP; the two
reverse tunnels stay until T07 and T08 remove what depends on them.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Operator decision 2026-08-24: rather than making two hub instances coexist
safely, retire the second one. The local postgres+uvicorn instance is what
impersonates central and is redundant with ADR-010 decision 3 plus Repo
Manager's file-derived index.
With it gone, state-hub-primary binds 127.0.0.1:8000 unchanged and every
existing default becomes correct with no call-site edits.
Adds the cache-only recovery export (44 records) as the T05 source.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ADR-010 documented two hub instances sharing port 8000 separated only by IP
family; the condition was never remediated. Repo onboarding from the
workstation has landed in the local cache since 2026-07-08 — 122 cache repos
vs 78 central, a strict subset with 0 central-only records.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Publish project-repository-flavor_v0.1 with naming, GOAL.md (not durable
INTENT.md), authority boundary, lifecycle, residuals, and archive rules.
Close ADR-005 deferred naming and CUST-WP-0050 D1a; cross-link from the
repo classification standard.
Stage 3 delivered end-to-end: intake hub entity (T01), fix-consistency
registration (T02), the promotion transition (T03, the actual point of
this workplan), generated per-repo index (T04), queue closures
retargeted to it (T05), suggestions retired with a real-data migration
(T06). All live-verified against the running API/DB, not just tests --
including catching and fixing a real bug in T03 (silent false-success
on a missing repo_id). 563 tests green throughout.
Carried forward, not blocking: full transclusion rendering (markitect,
T04 follow-on), an engagement hub entity (T02's honest deferral), the
pre-existing sync_schedules bug found 2026-07-20 (TD f29e49eb, out of
scope), and the 10 migrated intake findings needing their actual domain
owners to pick them up.
The reconciliation that started with AWQ-010 is complete.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Traced the origin of the-custodian issues #1-5 (opened 2026-07-08, all
reviewed and closed 2026-07-20): this ActivityDefinition's matched rule
always produces a TaskSpec (rules/actions.py::_task_spec_for_rule), and
RunActivityWorkflow unconditionally routes TaskSpecs through emit_tasks
-> the deployment-wide IssueSink (ISSUE_SINK_TYPE=rest -> issue-core ->
Forgejo). It is the fleet's only consumer of the task_template rule
action -- confirmed via grep across activity-definitions/.
Per current policy (Forgejo issue tracking is not the fleet coordination
mechanism), paused rather than left to recreate the same sidetrack daily:
enabled: false, status: paused, re-enable path documented in the file
(needs a new activity-core report-sink authoring a kind: intake work
record instead of an IssueSink task spec). Added as item 6 to
CUST-WP-0060's stage-3 successor seed, including the reminder to grep the
fleet for any other task_template consumer before stage 3 ships.
This is the ADR-001 file-level fix; the live activity-core DB row and
Temporal schedule pick it up on the next Railiance-deployed
'make sync-activity-definitions' run -- not something I have credentials
or standing to trigger directly from this session.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
