From 4e0f10fe965603195c8d85c6bc0dcd622d15b26f Mon Sep 17 00:00:00 2001 From: tegwick Date: Thu, 20 Aug 2026 08:41:48 +0200 Subject: [PATCH] SHR-WP-0002-T03 routed to core-hub MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- ...0002-predecessor-and-deployment-reality.md | 30 +++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/workplans/SHR-WP-0002-predecessor-and-deployment-reality.md b/workplans/SHR-WP-0002-predecessor-and-deployment-reality.md index 2079d7a..f8fa0f8 100644 --- a/workplans/SHR-WP-0002-predecessor-and-deployment-reality.md +++ b/workplans/SHR-WP-0002-predecessor-and-deployment-reality.md @@ -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