SHR-WP-0002-T03 routed to core-hub

The vehicle is CORE-WP-0010, which depends on HUB-WP-0004, which still carries an
open decision about whether hub-core becomes a runtime at all. So the chain that
would move production off CoulombCore bottoms out in an unanswered architecture
question — a sequencing problem, which is why it sits with the project, though
the answer is core-hub's.

Two shapes put to them: interim move to railiance01 using the proven rapp
pattern, or absorb directly into hub-core and let that be the migration. The
project takes no side except that leaving it implicit is not acceptable.

Surfaced a dependency of our own: the CoulombCore decommission date is not
pinned anywhere citable.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
tegwick 2026-08-20 08:41:48 +02:00
parent bf2b8f08ce
commit 4e0f10fe96

View file

@ -145,6 +145,36 @@ Precedent worth reusing: `issue-core` was migrated off CoulombCore on 2026-08-19
via `ISSUE-WP-0007` and a `rapp-issue-core` package. That is the pattern, and it
is one week old.
**Routed to `core-hub` 2026-08-20; waiting on their answer.** The vehicle is
`CORE-WP-0010` (runtime absorption into hub-core, `proposed`, all tasks `todo`),
which depends on `HUB-WP-0004` — itself `proposed`, and still carrying an open
decision about whether `hub-core` stays an importable library or becomes a
library plus a permanent thin host.
**So the chain that would move production off CoulombCore bottoms out in an
unanswered architecture question.** That is a sequencing problem rather than an
implementation one, which is why it sits here and not in a child repo — but the
answer is core-hub's.
Two shapes were put to them:
- **(a) Interim move** — package Core Hub as-is onto railiance01, absorb into
hub-core later on a calm schedule. Costs a migration that would otherwise not
happen; buys independence from the decommission date.
- **(b) Absorb directly** — skip the interim host and let `CORE-WP-0010` /
`HUB-WP-0004` be the migration. Cheaper in total work; couples production
continuity to finishing an architecture decision under a hard external
deadline.
The project does not choose between them, but records the reasoning either way.
The one position taken: **leaving it implicit is not acceptable**, because the
decommission date is a real constraint currently represented in no plan —
including this project's own gate model, which `T06` addresses.
Also asked: whether the decommission date changes `HUB-WP-0004`'s open
library-vs-thin-host decision. **Open dependency for this project: the
CoulombCore decommission date is not pinned anywhere we can cite.**
```task
id: SHR-WP-0002-T04
status: todo