ARDR: P1 runtime component handles, generation fencing, and health projection #187

New issue

Open

opened 2026-09-02 17:26:15 +00:00 by nsaspy · 1 comment

nsaspy commented

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

Owner

Bounded ARDR research transaction for lost-rob0t/starintel-server#42.

Canonical research:
roam/research/star-server/STAR-RESEARCH-042-component-handles-registry-readiness-health.org

Canonical design:
roam/design/star-server/STAR-SERVER-049-component-handles-registry-readiness-health.org

Current-source reconciliation: star.runtime and the #37 lifecycle design already own runtime lifecycle/components/dependency health. #42 must not create a second component manager. The selected scope is opaque generation-bearing handles, stale-reference fencing, capability lookup that does not grant authority, and explicit readiness/health projection over the existing lifecycle registry.

Research lifecycle: READY_FOR_DESIGN.
Design lifecycle: DESIGN_READY_FOR_OPERATOR_REVIEW.

Implementation authorization remains PENDING / AWAITING_OPERATOR_IMPLEMENTATION_APPROVAL. Issue state, design readiness, publication, or machine review cannot authorize RAGE implementation.

Bounded ARDR research transaction for `lost-rob0t/starintel-server#42`. Canonical research: `roam/research/star-server/STAR-RESEARCH-042-component-handles-registry-readiness-health.org` Canonical design: `roam/design/star-server/STAR-SERVER-049-component-handles-registry-readiness-health.org` Current-source reconciliation: `star.runtime` and the #37 lifecycle design already own runtime lifecycle/components/dependency health. #42 must not create a second component manager. The selected scope is opaque generation-bearing handles, stale-reference fencing, capability lookup that does not grant authority, and explicit readiness/health projection over the existing lifecycle registry. Research lifecycle: `READY_FOR_DESIGN`. Design lifecycle: `DESIGN_READY_FOR_OPERATOR_REVIEW`. **Implementation authorization remains PENDING / AWAITING_OPERATOR_IMPLEMENTATION_APPROVAL.** Issue state, design readiness, publication, or machine review cannot authorize RAGE implementation.

nsaspy commented

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

Author

Owner

Correction — research status and public/private wording

The previous summary was misleading in two ways.

This is Auto-Research output, not a landed StarIntel Server implementation. Nothing in starintel-server should be described as having "landed" from this research transaction. The correct status is: research/design artifacts were produced for operator review; implementation remains unapproved.
starintel-server is not being described as private. The intended boundary is API encapsulation, not repository/source visibility. Raw actor refs, Rabbit/CouchDB handles, HTTP server handles, threads, and other concrete runtime objects may exist normally in StarIntel Server source and implementation. The design proposal is only that external/public component references should not expose those raw runtime objects directly; callers would use opaque component handles instead. Saying those internals "stay private" without that qualification was wrong/misleading.

Correct research summary

Auto-Research investigated starintel-server#42 and proposed a generation-bearing component-reference API layered over the existing star.runtime lifecycle work. A handle such as {runtimeId, componentId, generation} would identify a specific component incarnation; restart/replacement would advance the generation so a stale handle fails rather than silently resolving to a replacement. The research also proposes explicit component health/dependency-based readiness instead of equating a retained non-NIL runtime object with health. Capability lookup remains discovery and does not itself authorize an operation.

This is research/design for operator review, not an implementation announcement.

Backlog direction

Auto-Research should prioritize the StarIntel v4 ideas/backlog as a seed source for future research cycles rather than manufacturing low-level runtime topics merely because they can be derived from existing implementation issues. Existing GitHub issues may still supply concrete defects/constraints, but the v4 ideas file should be treated as a primary product-direction backlog source.

## Correction — research status and public/private wording The previous summary was misleading in two ways. 1. **This is Auto-Research output, not a landed StarIntel Server implementation.** Nothing in `starintel-server` should be described as having "landed" from this research transaction. The correct status is: research/design artifacts were produced for operator review; implementation remains unapproved. 2. **`starintel-server` is not being described as private.** The intended boundary is API encapsulation, not repository/source visibility. Raw actor refs, Rabbit/CouchDB handles, HTTP server handles, threads, and other concrete runtime objects may exist normally in StarIntel Server source and implementation. The design proposal is only that external/public component references should not expose those raw runtime objects directly; callers would use opaque component handles instead. Saying those internals "stay private" without that qualification was wrong/misleading. ### Correct research summary Auto-Research investigated `starintel-server#42` and proposed a generation-bearing component-reference API layered over the existing `star.runtime` lifecycle work. A handle such as `{runtimeId, componentId, generation}` would identify a specific component incarnation; restart/replacement would advance the generation so a stale handle fails rather than silently resolving to a replacement. The research also proposes explicit component health/dependency-based readiness instead of equating a retained non-NIL runtime object with health. Capability lookup remains discovery and does not itself authorize an operation. This is **research/design for operator review**, not an implementation announcement. ### Backlog direction Auto-Research should prioritize the StarIntel v4 ideas/backlog as a seed source for future research cycles rather than manufacturing low-level runtime topics merely because they can be derived from existing implementation issues. Existing GitHub issues may still supply concrete defects/constraints, but the v4 ideas file should be treated as a primary product-direction backlog source.