Close HUB-WP-0009 conformance gaps (C2, C7, C9, C10); mark blocked workplans

Implements the four residual conformance checks left open by the T04
minimal vertical:

- C2: GET /ports/registry/registrations/{hub_slug} resolves missing (404),
  ambiguous (shared reuse_surface_id across hub_slugs), and stale
  (deprecated/retired descriptor) registrations; a new .../audit route
  exposes queryable registration history from the existing in-memory
  history and the PostgreSQL runtime_audit_ledger.
- C7: harness proof that disabled compatibility groups deny access
  (404) with no fixture credentials involved, matching the existing
  fail-closed compat router behavior.
- C9: harness proof plus a dedicated test that /readyz degrades only on
  an unavailable configured dependency while unrelated disabled
  projections stay non-blocking.
- C10: ContractValidator now negotiates contract_version_min/max against
  the runtime's contract version and rejects incompatible or inverted
  ranges with an explicit 422 instead of silently accepting them.

HUB-WP-0009 is now finished. HUB-WP-0006 is marked blocked: its only open
task (T06) has no remaining hub-core code path and waits on an external
Forgejo identity/production deployment gate. HUB-WP-0011 is marked
blocked: T02/T03 already waited on external credential/deployment
review, and T01 needs a source/destination ownership and retention
decision against live message data before it can be implemented safely.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: sonnet
Assistant-Process: 310936@bnt-lap001
Assistant-Session: 00cd9abe-09a0-416b-88e0-f907b9101629

workplans/HUB-WP-0006-repository-classification-navigation.md

@@ -4,7 +4,7 @@ type: workplan
 title: "Repository classification aggregation and navigation"
 domain: infotech
 repo: hub-core
-status: active
+status: blocked
 flavor: implementation
 owner: codex
 topic_slug: custodian
@@ -190,6 +190,14 @@ directory or restoring State Hub as the classification authority. Once a
 scoped publisher endpoint is deployed and the candidate migration/image is
 rolled out, comparison and `RM_SLICE_TOPICSPINE` can proceed.
 
+Loose-ends review 2026-09-27: T01-T05 remain the only work owned by this repo,
+and all five are `done`. T06 has no remaining hub-core code path — it is
+waiting on `RAPPCOREHUB-WP-0003-T04` (a dedicated `read:repository` Forgejo
+identity plus an error-free 123-repository admission proof) and production
+placement/networking outside this repository. Marking the workplan `blocked`
+rather than `active` since nothing further can move here until that external
+gate closes.
+
 ## Acceptance
 
 - [x] Repo Manager v1.0 authority and projection contract accepted

workplans/HUB-WP-0009-extension-conformance-gaps.md

@@ -4,12 +4,12 @@ type: workplan
 title: "Complete the hub-extension conformance profile"
 domain: infotech
 repo: hub-core
-status: proposed
+status: finished
 flavor: residual
 owner: codex
 topic_slug: custodian
 created: "2026-08-31"
-updated: "2026-08-31"
+updated: "2026-09-27"
 origin: residual
 origin_ref: OPS-WP-0003
 related:
@@ -32,7 +32,7 @@ the current C1/C3/C4/C5/C6/C8 profile; this residual owns C2, C7, C9, and C10.
 
 ```task
 id: HUB-WP-0009-T01
-status: todo
+status: done
 flavor: residual
 priority: medium
 state_hub_task_id: "0702bd43-146e-5f5d-9bf3-81ae4a367afb"
@@ -42,11 +42,20 @@ Implement C2 against the public registry/discovery contract, including missing,
 ambiguous, and stale registrations. Keep repository and capability authority in
 their owner systems and make registry audit history queryable.
 
+Completed 2026-09-27. `GET /ports/registry/registrations/{hub_slug}` resolves a
+`hub_slug` to `missing` (404), `ambiguous` (naming every other `hub_slug` that
+declares the same `reuse_surface_id`), `stale` (descriptor `status` of
+`deprecated`/`retired`), or `ok`, without hub-core taking classification or
+capability authority. `GET .../audit` returns the append-only registration
+audit trail (both the in-memory store and the existing PostgreSQL
+`runtime_audit_ledger`). Harness check C2 and `tests/test_runtime.py` cover
+missing, ambiguous, and stale resolution plus non-empty audit history.
+
 ## Enforce raw-port configuration policy
 
 ```task
 id: HUB-WP-0009-T02
-status: todo
+status: done
 flavor: residual
 priority: medium
 state_hub_task_id: "427a663c-fbd5-55c8-9889-6946a5072932"
@@ -56,11 +65,22 @@ Implement C7 so production configuration cannot bypass named ports or silently
 enable overlapping authorities. Cover policy allow, deny, and unavailable
 behavior without embedding credentials in fixtures.
 
+Completed 2026-09-27. `RuntimeSettings.__post_init__` already fails closed at
+construction when `v2_write_groups` overlaps `legacy_write_groups` or names a
+group `v2_groups` has not enabled, so overlapping raw-port authority cannot be
+configured. Harness check C7 proves the runtime denies (`404`) both a
+registry-shaped and an operator-shaped `/api/v2` route whenever their
+compatibility group is disabled, with no bearer token or fixture credential
+involved — confirming the deny/unavailable-by-default policy the compat
+router (`hub_core/runtime/compat.py::_enabled`/`_protected`) already
+enforces for allow (enabled + authorized), deny (disabled or unauthorized),
+and unavailable (compat store absent) paths.
+
 ## Prove dependency-aware readiness
 
 ```task
 id: HUB-WP-0009-T03
-status: todo
+status: done
 flavor: residual
 priority: high
 state_hub_task_id: "41476950-bb3f-5fc3-8d44-bea3d851e5f9"
@@ -70,11 +90,19 @@ Implement C9 for every enabled port and compatibility group. Readiness must
 fail when its required database, policy, registry, or owner projection is
 unavailable while unrelated disabled groups remain non-blocking.
 
+Completed 2026-09-27. `/readyz` already aggregated per-dependency checks
+(database, `port.repo` navigation projection, workload projection,
+authorization); harness check C9 and
+`test_readiness_blocks_on_unavailable_dependency_but_not_disabled_ones` now
+prove the contract explicitly: an unavailable configured `port.repo`
+projection client degrades readiness to `503` while the unconfigured workload
+projection stays `not_applicable` and does not block.
+
 ## Add contract-version negotiation
 
 ```task
 id: HUB-WP-0009-T04
-status: todo
+status: done
 flavor: residual
 priority: medium
 state_hub_task_id: "90849a2d-c3ac-5fca-b86f-88cef2803957"
@@ -85,9 +113,23 @@ responses. Include the 0.1 compatibility adapter and ensure future versions do
 not silently accept a contract they cannot interpret. Record tenant-isolation
 coverage separately if it still exceeds this profile.
 
+Completed 2026-09-27. `ContractValidator` now negotiates
+`contract_version_min`/`contract_version_max` against the runtime's
+`CONTRACT_VERSION` (0.1.0) on every registration, rejecting an inverted range
+or a range that excludes the runtime version with a 422 and an explicit
+incompatibility message instead of silently accepting an unsupported
+contract. Harness check C10 and two `tests/test_runtime.py` cases cover the
+out-of-range and inverted-range rejections; the packaged ops-hub fixture
+(`0.1.0`-`0.1.0`) continues to register, proving the 0.1 compatibility
+adapter still passes. Tenant isolation remains explicitly out of this
+profile, unchanged from the original scoping note.
+
 ## Acceptance
 
-- [ ] C2, C7, C9, and C10 are automated and fail closed
-- [ ] The conformance report distinguishes unsupported from pass/fail
-- [ ] Ops Hub's canonical owner package passes the expanded profile
-- [ ] Any tenant-isolation residual has its own live owner record
+- [x] C2, C7, C9, and C10 are automated and fail closed
+- [x] The conformance report distinguishes unsupported from pass/fail
+- [x] Ops Hub's canonical owner package passes the expanded profile
+- [ ] Any tenant-isolation residual has its own live owner record — out of
+      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.

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

@@ -4,12 +4,12 @@ type: workplan
 title: "State Hub inbox freshness and reader cutover"
 domain: infotech
 repo: hub-core
-status: proposed
+status: blocked
 flavor: residual
 owner: codex
 topic_slug: infotech
 created: "2026-09-05"
-updated: "2026-09-05"
+updated: "2026-09-27"
 origin: residual
 origin_ref: HUB-WP-0010
 related:
@@ -36,6 +36,19 @@ it into an unconditional overwrite loop. Prove recovery and idempotency without
 creating a second message writer. Decide the source/destination ownership
 boundary before live client traffic moves.
 
+Loose-ends review 2026-09-27: left `todo`, not implemented in this pass. This
+task's own scope calls for a source/destination ownership boundary decision —
+who is authoritative for a message once both State Hub and hub-core hold a
+copy, and what "deletes/retention treatment" means for messages State Hub no
+longer serves (archive locally, tombstone, or refuse) — before writing the
+monotonic-cursor and upsert logic that would encode that decision durably
+against live message data. That is the same kind of call this workplan's T02
+requires external review for, and it should not be made unilaterally in a
+loose-ends pass. Recommend Bernd (or a follow-up session with that decision
+in hand) confirms the ownership/retention boundary, after which the cursor
+and upsert implementation is a bounded, mechanical follow-on to the existing
+`import_snapshot` in `hub_core/runtime/inbox_projection.py`.
+
 ## Admit the actual reader identity and full scope semantics
 
 ```task