[P1-04] Add component handles, registry, readiness, and dependency-aware health #42

New issue

Open

opened 2026-07-22 00:17:08 +00:00 by lost-rob0t · 1 comment

lost-rob0t commented

2026-07-22 00:17:08 +00:00

(Migrated from github.com)

ARDR reconciliation — 2026-08-29

Canonical research/design now exist:

Research: lost-rob0t/starintel-auto-research/roam/research/star-server/STAR-RESEARCH-042-component-handles-registry-readiness-health.org — READY_FOR_DESIGN.
Design: lost-rob0t/starintel-auto-research/roam/design/star-server/STAR-SERVER-049-component-handles-registry-readiness-health.org — DESIGN_READY_FOR_OPERATOR_REVIEW.
Auto-Research transaction: #197.
Implementation authorization: PENDING / AWAITING_OPERATOR_IMPLEMENTATION_APPROVAL.

Current-source correction

The original issue predates current star.runtime lifecycle work. Current source already owns runtime lifecycle, retained actor/consumer/HTTP/kernel handles, owned consumer threads, CouchDB/Rabbit readiness probes, and process live/ready endpoints. The #37 ARDR design already owns the future closed component registry, dependency graph, lifecycle states, reconnect fencing, and required-component health.

Therefore do not create another component manager/registry beside #37.

The remaining #42 scope is the public/runtime identity projection over that lifecycle registry:

opaque immutable ComponentHandle(runtimeId, componentId, generation);
monotonically increasing component-incarnation generation;
stale-handle fencing before dispatch;
typed bounded capability/message lookup;
discovery does not grant authorization;
private local-actor/router/Rabbit/application-service ingress behind one handle contract;
explicit component health/readiness snapshots instead of non-NIL resource checks;
dependency-aware runtime readiness reusing #37's graph;
read-only pressure projection from #35/#36;
topology-safe public capability projection.

The original "extra HTTP Rabbit connection" defect appears repaired in current lifecycle source: HTTP startup explicitly states Rabbit publication is actor-owned. Preserve that repair; do not recreate work for it unless current implementation evidence changes.

Proposed implementation slices — ALL PENDING OPERATOR APPROVAL

Pure component-handle value + fake registry/generation semantics over the #37 component abstraction.
Stale-fenced private ingress resolution; fake ingress only.
Capability/message-type index from validated component metadata, with authorization remaining in application/domain policy.
Migrate readiness from actor/kernel/HTTP non-NIL checks to explicit component health snapshots.
Migrate one local actor/router destination from raw reference to opaque handle.
Migrate one Rabbit/remote route behind the same handle contract.
Add bounded operator diagnostics and topology-safe public capability projection.

Mandatory first RED

install component search generation N
handle = lookup(search)
replace search -> generation N+1
inspect/send with handle N
=> stale-component-handle
=> zero invocation of N+1 ingress

Untouched current server must fail because no opaque generation-bearing component handle contract exists.

Sibling REDs:

capability is discoverable but unauthorized caller invokes zero handler calls;
required component has retained non-NIL resource but explicit health=false -> runtime unready;
optional component failure remains degraded rather than silently required;
dependency A unready makes required dependent B unready via #37 graph;
local and Rabbit ingress return equivalent stale/unavailable handle outcomes;
public capability output contains no raw actor refs, private service endpoints, Rabbit/CouchDB/Valkey topology, or credential values.

Acceptance

one lifecycle registry/graph under star.runtime, not two;
opaque generation-bearing handles replace raw cross-component actor refs;
stale handles never auto-upgrade;
raw concrete resources remain runtime/adapter-private;
discovery cannot bypass authorization;
explicit required-component health drives readiness;
#35/#36 remain capacity/admission authorities;
local/remote ingress share handle failure semantics;
no new StarLang syntax or external supervisor.

Implementation authorization

PENDING / AWAITING_OPERATOR_IMPLEMENTATION_APPROVAL

Research readiness, design completion, issue state, or machine review do not authorize RAGE implementation.

## ARDR reconciliation — 2026-08-29 Canonical research/design now exist: - Research: `lost-rob0t/starintel-auto-research/roam/research/star-server/STAR-RESEARCH-042-component-handles-registry-readiness-health.org` — `READY_FOR_DESIGN`. - Design: `lost-rob0t/starintel-auto-research/roam/design/star-server/STAR-SERVER-049-component-handles-registry-readiness-health.org` — `DESIGN_READY_FOR_OPERATOR_REVIEW`. - Auto-Research transaction: #197. - **Implementation authorization: PENDING / AWAITING_OPERATOR_IMPLEMENTATION_APPROVAL.** ## Current-source correction The original issue predates current `star.runtime` lifecycle work. Current source already owns runtime lifecycle, retained actor/consumer/HTTP/kernel handles, owned consumer threads, CouchDB/Rabbit readiness probes, and process live/ready endpoints. The #37 ARDR design already owns the future closed component registry, dependency graph, lifecycle states, reconnect fencing, and required-component health. Therefore **do not create another component manager/registry beside #37**. The remaining #42 scope is the public/runtime identity projection over that lifecycle registry: - opaque immutable `ComponentHandle(runtimeId, componentId, generation)`; - monotonically increasing component-incarnation generation; - stale-handle fencing before dispatch; - typed bounded capability/message lookup; - discovery does not grant authorization; - private local-actor/router/Rabbit/application-service ingress behind one handle contract; - explicit component health/readiness snapshots instead of non-NIL resource checks; - dependency-aware runtime readiness reusing #37's graph; - read-only pressure projection from #35/#36; - topology-safe public capability projection. The original "extra HTTP Rabbit connection" defect appears repaired in current lifecycle source: HTTP startup explicitly states Rabbit publication is actor-owned. Preserve that repair; do not recreate work for it unless current implementation evidence changes. ## Proposed implementation slices — ALL PENDING OPERATOR APPROVAL 1. Pure component-handle value + fake registry/generation semantics over the #37 component abstraction. 2. Stale-fenced private ingress resolution; fake ingress only. 3. Capability/message-type index from validated component metadata, with authorization remaining in application/domain policy. 4. Migrate readiness from actor/kernel/HTTP non-NIL checks to explicit component health snapshots. 5. Migrate one local actor/router destination from raw reference to opaque handle. 6. Migrate one Rabbit/remote route behind the same handle contract. 7. Add bounded operator diagnostics and topology-safe public capability projection. ## Mandatory first RED ```text install component search generation N handle = lookup(search) replace search -> generation N+1 inspect/send with handle N => stale-component-handle => zero invocation of N+1 ingress ``` Untouched current server must fail because no opaque generation-bearing component handle contract exists. Sibling REDs: - capability is discoverable but unauthorized caller invokes zero handler calls; - required component has retained non-NIL resource but explicit health=false -> runtime unready; - optional component failure remains degraded rather than silently required; - dependency A unready makes required dependent B unready via #37 graph; - local and Rabbit ingress return equivalent stale/unavailable handle outcomes; - public capability output contains no raw actor refs, private service endpoints, Rabbit/CouchDB/Valkey topology, or credential values. ## Acceptance - one lifecycle registry/graph under `star.runtime`, not two; - opaque generation-bearing handles replace raw cross-component actor refs; - stale handles never auto-upgrade; - raw concrete resources remain runtime/adapter-private; - discovery cannot bypass authorization; - explicit required-component health drives readiness; - #35/#36 remain capacity/admission authorities; - local/remote ingress share handle failure semantics; - no new StarLang syntax or external supervisor. ## Implementation authorization `PENDING / AWAITING_OPERATOR_IMPLEMENTATION_APPROVAL` Research readiness, design completion, issue state, or machine review do not authorize RAGE implementation.

nsaspy referenced this issue

2026-08-28 03:29:46 +00:00

Own server lifecycle and expose truthful readiness #103

nsaspy referenced this issue

2026-09-02 17:26:32 +00:00

[P1-06] Replace dead matcher/URL extractor with bounded typed document transforms #134

nsaspy referenced this issue

2026-09-02 17:26:32 +00:00

[P1-05] Compile StarLang actor semantics + dataset manifests into a validated RuntimePlan #135

nsaspy referenced this issue

2026-09-02 17:26:32 +00:00

[P1-03] Extract concrete adapters behind explicit runtime-owned typed ports #136

nsaspy commented

2026-09-02 17:26:52 +00:00

Owner

Wording correction from Auto-Research

The phrase that raw actor refs/resources "remain private" should be read strictly as an API encapsulation boundary, not as a claim that StarIntel Server source or these implementation objects are private.

starintel-server can of course contain and use actor refs, Rabbit/CouchDB resources, HTTP handles, threads, and other concrete runtime objects. The proposed #42 design only says that the public component-reference contract should not hand those concrete objects directly to callers; it would expose opaque generation-bearing handles instead.

Also, the linked Auto-Research work is research/design only. It has not "landed" this behavior in StarIntel Server and does not constitute implementation authorization.

## Wording correction from Auto-Research The phrase that raw actor refs/resources "remain private" should be read strictly as an **API encapsulation boundary**, not as a claim that StarIntel Server source or these implementation objects are private. `starintel-server` can of course contain and use actor refs, Rabbit/CouchDB resources, HTTP handles, threads, and other concrete runtime objects. The proposed #42 design only says that the *public component-reference contract* should not hand those concrete objects directly to callers; it would expose opaque generation-bearing handles instead. Also, the linked Auto-Research work is **research/design only**. It has not "landed" this behavior in StarIntel Server and does not constitute implementation authorization.