coulomb/hub-core
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs: plan NetKingdom platform-root access for Hub Core and extensions
Some checks are pending
CI Smoke / pytest-smoke (push) Waiting to run
Details
CI Smoke / host-smoke (push) Successful in 0s
Details

Browse source 
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a0e715-b802-70f0-a8fa-590d9ee673a5
This commit is contained in:
tegwick 2026-09-28 10:42:52 +02:00
parent d6ce08f013
commit e5b67b391d
5 changed files with 490 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

9
WORK-RECORDS.md
View file

@ -17,6 +17,7 @@
| workplan | HUB-WP-0007 | finished | — | workplans/HUB-WP-0007-workload-projection-transport.md |
| workplan | HUB-WP-0008 | finished | — | workplans/HUB-WP-0008-legacy-message-identity-reconciliation.md |
| workplan | HUB-WP-0009 | proposed | — | workplans/HUB-WP-0009-extension-conformance-gaps.md |
| workplan | HUB-WP-0012 | proposed | — | workplans/HUB-WP-0012-netkingdom-platform-root-access.md |
| task | HUB-WP-0001-T01 | done | — | workplans/HUB-WP-0001-statehub-bootstrap.md |
| task | HUB-WP-0001-T02 | done | — | workplans/HUB-WP-0001-statehub-bootstrap.md |
| task | HUB-WP-0001-T03 | done | — | workplans/HUB-WP-0001-statehub-bootstrap.md |
@ -61,3 +62,11 @@
| task | HUB-WP-0009-T02 | todo | — | workplans/HUB-WP-0009-extension-conformance-gaps.md |
| task | HUB-WP-0009-T03 | todo | — | workplans/HUB-WP-0009-extension-conformance-gaps.md |
| task | HUB-WP-0009-T04 | todo | — | workplans/HUB-WP-0009-extension-conformance-gaps.md |
| task | HUB-WP-0012-T01 | todo | — | workplans/HUB-WP-0012-netkingdom-platform-root-access.md |
| task | HUB-WP-0012-T02 | todo | — | workplans/HUB-WP-0012-netkingdom-platform-root-access.md |
| task | HUB-WP-0012-T03 | todo | — | workplans/HUB-WP-0012-netkingdom-platform-root-access.md |
| task | HUB-WP-0012-T04 | todo | — | workplans/HUB-WP-0012-netkingdom-platform-root-access.md |
| task | HUB-WP-0012-T05 | todo | — | workplans/HUB-WP-0012-netkingdom-platform-root-access.md |
| task | HUB-WP-0012-T06 | todo | — | workplans/HUB-WP-0012-netkingdom-platform-root-access.md |
| task | HUB-WP-0012-T07 | wait | — | workplans/HUB-WP-0012-netkingdom-platform-root-access.md |
| task | HUB-WP-0012-T08 | todo | — | workplans/HUB-WP-0012-netkingdom-platform-root-access.md |

232
docs/netkingdom-access-blueprint.md Normal file
View file

@ -0,0 +1,232 @@
# Hub Core and extension access through NetKingdom
Status: proposed implementation blueprint, 2026-09-28. Owner: `hub-core`.
Execution record: [HUB-WP-0012](../workplans/HUB-WP-0012-netkingdom-platform-root-access.md).
Requested outcome: the person signing in as `platform-root` can access and
administer the whole platform, including Hub Core, its extensions, and Railiance.
Other human users are denied initially. Public exposure follows proven access
enforcement. Fine-grained delegation is a later phase of the same workplan.
## Findings and evidence boundary
This is a source/configuration review plus read-only runtime observation, not
an authenticated platform-root acceptance test. No account, token, role,
policy, public listener, or production workload was changed.
| Boundary | Observed state on 2026-09-28 | Consequence |
| --- | --- | --- |
| Hub Core | `runtime/app.py` mounts `ports.py` without a global authorization dependency; native registration, messaging, events and generic projections lack a verified subject/tenant context | Enforce access in the service and SDK, not only at Ingress |
| Compatibility API | `runtime/compat.py::_protected` accepts a shared configured bearer or an imported consumer key; no resource/tenant decision follows | Replace broad bearer authority with authenticated principal plus action authorization |
| MCP | Separate runtime/transport and reusable host wrapper | Inventory every tool and carry caller identity to the same protected API; no server-wide root token |
| Inbox pilot | Snapshot GET reader uses the shared token and literal `state-hub` recipient | Keep private; caller migration remains HUB-WP-0011, not a completed retirement slice |
| Extension conformance | HUB-WP-0009 finished C2/C7/C9/C10; its explicit tenant-isolation gap has no implementation | This workplan owns the new security profile; 0.1 conformance is insufficient for exposure |
| Identity | Live issuer discovery at `https://kc.coulomb.social` advertises S256, authorization code and client credentials; KeyCape, Authelia, LLDAP and identity-provisioner Deployments Ready | Reuse the issuer; no second identity database or new IdP |
| User and tenant management | User Engine and Tenant Engine Deployments Ready; USER-WP-0030 and NK-WP-0038 finished | Reuse account lifecycle and tenant authority; readiness does not prove this root account's effective grants |
| Policy | Six service-specific flex-auth Deployments Ready; none for Hub Core | Register a protected system and owner-managed policy deployment; don't borrow another consumer's PDP/credentials |
| Hosting | Core Hub legacy/candidate/publisher Ready; revision 28 has Ingress off | Keep private until the new admission gate; the earlier public grant alone does not satisfy this request |
| Current external blockers | Public host presents Traefik default certificate; publisher accepts 113/123 with nine private-source errors and an identity-canon registry mismatch | Existing RAPPCOREHUB-WP-0002/0003 retain these operational obligations |
Source findings use the current checkout. Live hub image remains the September 5
pin, so later source conformance changes are not claimed deployed. The root
account's immutable subject, effective memberships, MFA and revocation behavior
still require an attended, non-secret acceptance receipt.
## Authority and request path
```mermaid
flowchart TD
Human[Human: platform-root] --> Login[KeyCape OIDC login]
Login --> Client[Hub browser session or CLI]
Users[User Engine: account and membership lifecycle] --> Facts[Verified account and tenant facts]
Tenants[Tenant Engine: tenant lifecycle and capability roles] --> Facts
Client --> Hub[Hub Core API: authenticate and enforce]
Workload[Named service or agent identity] --> Hub
Facts --> Policy[flex-auth: action and resource decision]
Hub --> Policy
Hub --> Extension[Extension API: authenticate and enforce]
Extension --> Policy
Extension --> Owner[Railiance or domain owner: execute and enforce]
Owner --> Audit[Durable audit evidence]
Hub --> Audit
```
KeyCape owns authentication and signed IAM claims. User Engine owns account,
application profile and membership lifecycle. Tenant Engine owns tenant state
and capability roles. NetKingdom owns the IAM profile and identity integration.
`flex-auth` owns decisions; the announced `access-engine` rename changes a repo
coordinate, not current runtime names or audiences (NK-WP-0039).
Hub Core and every extension enforce decisions locally. Domain services retain
their data, commands and approvals. Railiance retains infrastructure execution;
ops-warden retains SSH certificate issuance; approval-engine retains durable
approval lifecycle; OpenBao/platform owners retain credential custody. Hub Core
does not become a privileged Kubernetes or OpenBao proxy merely by hosting UI.
## M1: full platform-root access
Bind the existing platform-root account by verified `(issuer, subject)`, resolved
through its owning identity/account records. A username or email is only a
display/lookup hint, never the privilege check. Do not fabricate a subject UUID,
auto-promote the first login, or grant every `platform-operator` root access.
User Engine currently uses `platform-operator` for some administrative gates;
T02 must map the specific root account's entitlement into those existing policy
vocabularies rather than assume a universal `platform-root` role already exists.
M1 grants that principal all registered platform actions and resources through
each service's normal enforcement path, including Hub Core registry, messaging,
events, projections, work/repository operations via owners, extension surfaces,
tenant administration, and Railiance administration. Where full administration
requires crossing tenant boundaries, record an explicit platform-root grant
and audit both actor tenant and target tenant. Root remains `tenant:platform`;
it does not impersonate a tenant member. Tenant admins and ordinary users gain
no platform access in M1. Workloads retain only their individually registered
service/agent permissions and cannot inherit the human grant.
Use a versioned, owner-reviewed action/resource catalog and entitlement, not a
hardcoded middleware bypass. New actions require catalog/policy review before
they become routable. Fine-grained human roles are deferred, but signature
validation, deny-by-default, tenant attribution and audit are M1 requirements.
Full access does not waive existing confirmations, approval obligations,
single-writer controls, secret non-disclosure, or emergency custody rules.
The estate access matrix must enumerate every active platform service and
management surface from owner/Fabric inventories. Seed it with Hub Core,
ops-hub, repo-manager, activity-core, User/Tenant Engine, identity administration,
policy/approval/audit surfaces, Forgejo, OpenBao/secrets operations, and
Railiance Kubernetes, deployment/GitOps, SSH and observability. Each row names
owner, resource/realm, audience, enforcement point, grant, safe test, and receipt.
Existing native/SSH/attended paths may satisfy a row; a generic hub token may
not. M1 is not complete while any inventoried platform surface is inaccessible
or untested. Non-hub services need integration, not reclassification as hubs.
## Authentication and session contract
Use accepted [IAM Profile v0.3](../../net-kingdom/canon/standards/iam-profile_v0.3.md).
The browser uses Authorization Code + PKCE S256 through a confidential session
backend with exact registered redirects, state/nonce, Secure HttpOnly cookies,
CSRF protection and logout. Store tokens server-side, not browser local storage.
CLI/MCP clients use an issuer-supported flow and their own audience-bound
credentials; do not assume device flow or token exchange exists without proof.
The OAuth design follows [RFC 9700](https://www.rfc-editor.org/rfc/rfc9700.html).
The API validates access-token type, issuer, audience, allowed algorithm,
signature, key rotation, expiry/not-before and required IAM claims. ID tokens
are not API credentials. Missing/invalid authentication returns 401; verified
but disallowed access returns 403; unavailable authorization returns a bounded
503 without executing work. Resolve trusted resource/tenant facts on the server;
ignore user-supplied subject, role, tenant headers and purported verified flags.
Platform-root requires AAL2 or stronger per IAM v0.3 and NK-ADR-0016; an ordinary
SSO session does not establish that. Reuse the accepted enrollment/recovery
journeys and attest the privileged login. NK-WP-0042's per-request step-up and
IAM v0.4 are proposed, not available guarantees. M1 can use the existing
per-client privileged MFA path only after its usability/return journey is
accepted; otherwise remain private and record that blocker.
T02 fixes measurable token/session lifetimes, assurance freshness and maximum
grant-revocation delay. Proposed upper bound: five minutes for ordinary root
access; privileged mutations recheck current root entitlement and tenant state
at execution and fail closed when unavailable. Logout invalidates the local
session immediately; expired or revoked authority cannot survive refresh.
Use authoritative owner APIs for high-stakes tenant capability facts;
`tenant_roles` in a token is only a cache. Test user suspension, grant removal,
tenant suspension and issuer/policy outages, not just successful sign-in.
## Authorization, forwarding and extension contract
Every request carries server-established actor, calling workload, target
tenant, action, resource, assurance and correlation identity. The service
authenticates to flex-auth using an admitted workload identity separately from
the end user's identity. Caller TokenReview alone must not authorize arbitrary
claims asserted by that caller. Adopt the current fact-provenance and binding
contracts (FLEX-WP-0025, FLEX-WP-0017).
Verify the decision's request binding, action/resource/tenant, validity,
policy version, obligations and authenticated origin. Require a signed decision
and trusted rotating verification keys per FLEX-WP-0024, or an explicitly
reviewed equivalent authenticated channel. An unsigned development decision is
not sufficient for public M1. Signing code being finished does not prove a
production signing-key custody lane exists; owner delivery is a T03 gate.
Audit allow/deny/error with actor, caller, tenant, action/resource, policy and
decision IDs, correlation and outcome; never tokens or message bodies. Required
audit failure prevents privileged mutation; bounded durable buffering must be
specified rather than silently dropping evidence.
Expose one reusable enforcement/context seam for embedded routers, native
`/ports`, `/api/v2`, aliases, docs/catalogs, projection APIs, browser and MCP.
Only minimal liveness and the exact login/callback mechanics may be unauthenticated;
detailed readiness is internal. Test direct Service requests as well as Ingress.
Legacy keys get explicit private, bounded migration lanes with named owners;
they must not become a public bypass or be distributed to extensions.
An extension manifest declares protected-system identity, token audience,
action/resource namespaces, tenant behavior and required security-contract
version. Extensions validate their own audience and enforce their own policy;
Hub Core cannot forward a bearer to an unrelated audience. Use only a proven
issuer delegation/exchange mechanism, or a reviewed authenticated workload call
with integrity-bound end-user delegation. If neither exists, use a separate
client login and leave delegation unsupported. Never relay root's bearer as a
generic backend credential. Service-initiated events bind producer/address to
the authenticated workload; payload `sender` is not authority.
Version the security profile and extend conformance beyond HUB-WP-0009.
Cover list/filter/detail, exports, caches, pagination, broadcasts, aliases,
streaming/MCP and event replay; no cross-tenant existence/count leak. Classify
legacy unlabelled records explicitly as platform-owned or quarantine them;
never infer their tenant from the current viewer. Platform-root may administer
them through its explicit platform grant. Non-root multi-tenant admission waits
for Phase 2 data migration and isolation tests.
## Retirement integration and sequencing
| Existing owner record | Relationship to this work |
| --- | --- |
| HUB-WP-0004/0005, CORE-WP-0010 | Runtime selection/absorption already decided; implement here, retain Core Hub rollback privately; no new feature lane in Core Hub |
| HUB-WP-0009 | Existing contract checks stay finished; this work owns the missing identity/tenant conformance profile |
| HUB-WP-0011 | Reuse the new caller/context seam for T02; inbox freshness, retention, recipient/alias semantics and reader switch stay there |
| STATE-WP-0079 | Authentication does not close its 425-item disposition, single-writer, parity, metering or retirement gates; apply the security gate per slice |
| RMGR-WP-0001/0002/0003 | Git/file authority stays in Repo Manager; Hub Core views and invokes governed owner APIs |
| OPS-WP-0003; ACTIVITY-WP-0029 | Existing extension and event/schedule alignment finished; add security conformance/caller migration without reopening completed tasks |
| FIN-WP-0003; RAIL-FAB-WP-0028 | Fabric authority stays specialized; hosted Fabric is blocked independently; integrate the available owner surface and report missing runtime evidence |
| RAPPCOREHUB-WP-0002/0003/0004 | Packaging/exposure, publisher credential gate and completed private inbox pilot retain their owners |
| NK-WP-0038/0039/0042; USER-WP-0030; TEN-WP-0012 | Reuse delivered identity/admin behavior; respect pending coordinate, step-up and tenant conformance work rather than claim them complete |
Implement shared contracts and platform-root access privately first. Exercise
one extension (ops-hub), actual workload callers and Railiance owner paths, then
complete the platform access matrix. Gate each State Hub reader/writer move on
the same identity checks plus that slice's existing data/freshness gates.
Do not add permanent authentication/tenant authority to retiring State Hub.
Public enablement is a separate final gate under RAPPCOREHUB-WP-0002: authenticated
root success, ordinary-user/anonymous denial, direct-path denial, MFA, revocation,
policy failure, audit, all published route/tool coverage, current image pins,
TLS issuance and consumer tests, then explicit exposure approval. Fix release
configuration so routine upgrades preserve the approved exposure mode while
new installations default private. Do not expose the legacy rollback service.
Rollback retracts public access before restoring any image lacking enforcement;
it never restores an anonymously reachable older runtime. No full historical
Helm rollback that silently revives the old public configuration.
## Later phase retained in the same plan
After M1, define tenant-admin and ordinary-user grants, delegated agents,
per-extension/action permissions, recipient ACLs and tenant-scoped storage,
queries, caches and retention. Preserve the root entitlement as an explicit
policy grant. Phase 2 is open work, not a prerequisite for proving the coarse
root-only model, and must not be silently dropped when M1 closes.
## Source map
- `hub-core/hub_core/runtime/{app,ports,compat,config,inbox_projection}.py`,
`hub_core/mcp/server.py`, `docs/runtime.md`, `docs/conformance.md`.
- NetKingdom `docs/platform-identity-security-architecture.md`, accepted IAM
v0.3, `docs/adr/ADR-0016-mfa-user-preference-and-workload-step-up.md`.
- User Engine `wiki/ArchitectureBlueprint.md`, `docs/development.md`;
flex-auth `docs/iam-profile-consumption.md`, decision binding/signature and
inbound caller-auth contracts. The older consumption doc's v0.2 reference
does not supersede accepted additive v0.3.
- Retirement project `architecture/hub-extension-architecture_v0.1.md`,
`architecture/child-workplan-map_v0.1.md`, and owner workplans in the table.
Historical map statuses are not treated as current delivery evidence.
- Runtime checks: deployment readiness listing, issuer discovery, and
`rapp-core-hub/docs/evidence/loose-end-review-20260928.md`.

5
workplans/HUB-WP-0009-extension-conformance-gaps.md
View file

@ -133,3 +133,8 @@ profile, unchanged from the original scoping note.
scope: the 0.1 runtime still has no tenant identity/authorization
context, as noted in `docs/conformance.md`; no owner record exists to
link because there is no implementation to attribute one to.
2026-09-28 follow-up: the newly requested `HUB-WP-0012` now owns the
identity/tenant enforcement and extension security profile, including Phase 2
isolation. This supplies the missing residual owner without claiming that
the 0.1 profile already implements tenant isolation.

6
workplans/HUB-WP-0011-statehub-inbox-freshness-and-cutover.md
View file

@ -66,6 +66,12 @@ and thread/read/archive semantics for the selected reader. The existing pilot
supports only one literal agent and exact sender filters. Never distribute the
operator token as an application credential.
2026-09-28 integration dependency: `HUB-WP-0012-T02` through `T05` own the
shared NetKingdom identity, policy and workload-caller contract. Reuse that
contract here; this task retains inbox-specific recipient/alias semantics.
The root-only human milestone does not authorize an automated reader as root
or close the freshness and reader-switch tasks.
## Execute one reviewed client switch
```task

238
workplans/HUB-WP-0012-netkingdom-platform-root-access.md Normal file
View file

@ -0,0 +1,238 @@
---
id: HUB-WP-0012
type: workplan
title: "NetKingdom identity and tenant integration: platform-root first"
domain: infotech
repo: hub-core
status: proposed
flavor: implementation
owner: codex
topic_slug: infotech
created: "2026-09-28"
updated: "2026-09-28"
related:
- HUB-WP-0009
- HUB-WP-0011
- STATE-WP-0079
- CORE-WP-0010
- RAPPCOREHUB-WP-0002
- RAPPCOREHUB-WP-0003
- NK-WP-0038
- NK-WP-0039
- NK-WP-0042
- USER-WP-0030
- TEN-WP-0012
- FLEX-WP-0024
- FLEX-WP-0025
- SHR-WP-0001
state_hub_workstream_id: "e61ce290-c5ec-516c-8589-ef9a55cf3aa3"
---
# NetKingdom integration, platform-root first
## Outcome and boundaries
The existing platform-root login receives full Hub Core, extension and platform
access, including Railiance, through verified NetKingdom identity and the
owners' enforcement paths. Other human users are denied initially. Public
exposure waits for access-control evidence and a separate approved rollout.
[Architecture blueprint](../docs/netkingdom-access-blueprint.md) defines the
contract and reviewed baseline. This is the single new integration workplan;
existing retirement and rollout plans retain their tasks. Core Hub receives no
new product feature work. This planning session does not implement or activate
grants, enroll factors, deploy policies, expose services or retire State Hub.
Status is proposed because cross-owner policy, root identity binding and live
acceptance are not yet reviewed. The user has selected the root-first scope;
there is no need to reopen that product decision. Dependencies below are
per-task sequencing, not a blanket wait for every related workplan to finish.
## T01 — Freeze the integration contract and platform coverage matrix
```task
id: HUB-WP-0012-T01
status: todo
priority: high
state_hub_task_id: "204f4fb0-e240-5558-8790-5985517b85e0"
```
Owner: hub-core; contract reviewers: NetKingdom, user-engine, tenant-engine,
flex-auth and affected extension/platform owners. Review the blueprint and
inventory every HTTP route, alias, MCP tool, embedded router and active platform
service/management surface. Record audience, action/resource, actor/target
tenant, enforcement point and test owner for each. Include Railiance Kubernetes,
GitOps/deployments, SSH, observability and platform identity/secret administration.
Confirm root's explicit cross-tenant administrative coverage and existing
approval obligations. Set the versioned security-profile and migration contract.
Done when no published route/tool or active platform surface lacks a row and
owner, contract reviewers' decisions are recorded, and M1 success/deny cases
are executable specifications. Unknown/disputed rows remain visible blockers.
## T02 — Bind platform-root identity, login, tenant and revocation
```task
id: HUB-WP-0012-T02
status: todo
priority: high
state_hub_task_id: "9a955fbf-f289-51b7-9682-bbe471694595"
```
Depends on T01. Owners: NetKingdom/KeyCape, user-engine and tenant-engine;
hub-core owns consumption. Resolve the existing root account to `(iss, sub)`
without recording credentials. Establish its explicit platform entitlement,
map existing platform-operator vocabulary, register Hub clients/audiences and
exact redirects, and implement PKCE sessions and API token validation. No
username comparison or first-login promotion. Require the existing AAL2 floor
and accepted enrollment/recovery; do not assume proposed IAM v0.4 step-up works.
Fix measurable session/token/assurance lifetimes and revocation bounds; include
live authoritative tenant/account checks for privileged actions.
Done when attended root login succeeds privately, an ordinary account and a
forged same-name account fail, MFA/recovery/logout/key rotation work, and
suspension/grant withdrawal deny within the agreed bound. Record immutable
identity references and sanitized receipts only. Reuse NK-WP-0042 if additional
step-up implementation is actually required.
## T03 — Deliver root policy and authenticated decision evaluation
```task
id: HUB-WP-0012-T03
status: todo
priority: high
state_hub_task_id: "feea8f20-aad4-583b-958a-a8efeb9c133c"
```
Depends on T01; live acceptance also needs T02. flex-auth owns the protected
system, complete action/resource grant and service deployment; platform owners
own credential/signing-key delivery. Hub Core owns enforcement integration.
Authenticate the calling workload separately from the end user, validate fact
provenance, signed decision origin, request binding and obligations. Root gets
all registered platform actions; non-root humans deny; callers get explicit
workload grants only. Fail closed on unsigned/untrusted, stale, mismatched,
unavailable or obligation-incomplete decisions. Prove audit durability and key
rotation. No token/PDP credential reuse from another protected system.
Done when a private pinned deployment passes positive root decisions and the
tampered-signature, wrong actor/action/resource/tenant, expired decision,
untrusted caller and policy-outage matrix. Finished signing source work is not
substituted for evidence of production custody and delivery.
## T04 — Enforce the boundary across Hub Core and its clients
```task
id: HUB-WP-0012-T04
status: todo
priority: high
state_hub_task_id: "15bc3cae-4575-56c9-afd2-e1e348109ca9"
```
Depends on T02/T03. Add the reusable verified actor/tenant context and local
enforcement seam to all native ports, projections, compatibility routes/aliases,
catalogs/docs, browser, MCP and embedded router paths. Minimal liveness and
login mechanics are the only public exceptions. Bind messaging/event producer
identity to the caller; prevent direct-Service bypass. Remove shared root
credentials from normal clients and confine unavoidable migration keys to
named private lanes. Add readiness checks for configured identity/policy
dependencies. Root can administer every Hub Core function; an ordinary logged-in
user cannot. Include revocation, concurrency, cache and audit-failure tests.
Done when the route/tool inventory is covered by automated allow/deny tests,
private full-root browser/API/MCP journeys pass, and legacy callers have tested
bounded migration/rollback paths without a public bypass.
## T05 — Admit extensions and State Hub migration callers
```task
id: HUB-WP-0012-T05
status: todo
priority: high
state_hub_task_id: "6d29854e-e894-5340-9e13-8866e80246f4"
```
Depends on T04. Publish the versioned extension security profile and harness.
Use ops-hub as first extension, then all inventoried exposed extensions;
activity-core, Repo Manager and inbox readers receive separate workload
identities. Each extension enforces audience/action/tenant and authenticates
delegation; no forwarding root tokens across audiences. Preserve domain/Fabric
authority and explicit unsupported/deferred surfaces.
Done when root succeeds and anonymous/non-root/wrong-tenant/wrong-audience
callers fail across extension boundaries; calls and audit retain actor plus
workload identities. HUB-WP-0011-T02 consumes this contract, while its T01/T03
retain freshness and reader cutover. STATE-WP-0079 keeps each slice's writer,
parity, retention and zero-traffic gates. This task does not claim retirement.
## T06 — Prove full platform-root coverage, including Railiance (M1)
```task
id: HUB-WP-0012-T06
status: todo
priority: high
state_hub_task_id: "97b0b242-e9a7-53cd-941f-a1822fcf93a5"
```
Depends on T04/T05 and the external owners for each T01 row. Integrate the same
root identity/entitlement with all inventoried platform management surfaces.
Use native owner paths for SSH certificates, Kubernetes/RBAC, GitOps,
credentials and approvals; Hub Core is not an unrestricted execution proxy.
Keep caller and human attribution distinct and preserve existing confirmation
and approval obligations. Test allowed administration with reversible or
isolated operations and independently verify denied non-root attempts.
M1 is accepted only when every coverage row has an attended/live receipt,
including full Hub Core access and Railiance administration, revocation and
audit. A navigation link or Hub Core token alone is not evidence of access to
another service. Any missing backend integration keeps M1 open.
## T07 — Package and gate public exposure
```task
id: HUB-WP-0012-T07
status: todo
priority: high
state_hub_task_id: "0c15cb82-7c59-5a44-8bf0-857ea4438642"
```
Depends on M1. Owner: rapp-core-hub through existing RAPPCOREHUB-WP-0002-T05,
with NetKingdom/platform/reef owners. Pin the verified image, credential
references, policy boundary and explicit release exposure setting. Run local,
server-dry-run, private root/deny, TLS and consumer gates. Resolve the existing
publisher failures in RAPPCOREHUB-WP-0003 separately where required by smoke.
Obtain the concrete public-enable approval only after evidence is reviewable.
Routine upgrades preserve approved exposure; fresh installs stay private.
Rollback retracts public access before any pre-enforcement image is restored.
Done when the approved public surface passes root access, non-root/anonymous
denial, no bypass, trusted TLS, revocation and rollback checks. Never enable
Ingress just to repair the old public stabilization check ahead of this gate.
## T08 — Refine roles, tenant isolation and delegation (Phase 2)
```task
id: HUB-WP-0012-T08
status: todo
priority: medium
state_hub_task_id: "59a0672c-560e-5b43-9d83-9f90d498698f"
```
Deferred until M1; not an M1 dependency. Hub Core with NetKingdom, User/Tenant
Engine, policy and extension owners define tenant admins, ordinary users,
recipient rules, delegated agents and per-action/extension permissions. Migrate
legacy data with explicit tenant provenance; test query/export/cache/event and
MCP isolation before admitting any non-root tenant users. Root's platform grant
remains explicit and auditable. Do not create a second workplan merely to defer
this task; this plan stays open after M1 until Phase 2 is completed or explicitly
re-scoped with a durable owner.
## Acceptance checkpoints
- [x] Architecture/source/runtime review captured; new implementation owner is hub-core
- [ ] T01 contract review and complete platform surface inventory accepted
- [ ] M1: T02–T06 full platform-root access and denial/revocation evidence accepted
- [ ] T07: authenticated public exposure separately approved and verified
- [ ] Phase 2: T08 delegated and tenant-scoped access accepted
Planning completion is not implementation completion. No authenticated root
session or entitlement was tested in the 2026-09-28 review.