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

New issue

Open

opened 2026-09-02 17:26:32 +00:00 by nsaspy · 0 comments

nsaspy commented

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

Owner

ARDR reconciliation — 2026-08-29

Canonical research/design now own this issue:

Research: lost-rob0t/starintel-auto-research/roam/research/star-server/STAR-RESEARCH-050-manifest-runtime-plan-composition.org — READY_FOR_DESIGN.
Design/adversarial review: lost-rob0t/starintel-auto-research/roam/design/star-server/STAR-MANIFEST-001-document-contracts.org — DESIGN_READY_FOR_OPERATOR_REVIEW.
Auto-Research transaction: lost-rob0t/starintel-auto-research#199.
Implementation authorization: PENDING / AWAITING_OPERATOR_IMPLEMENTATION_APPROVAL.

Current-source correction

Do not implement the original issue as a second server-local actor declaration language.

Current StarLang already compiles domain-server manifest semantics including stable identity, keyed/domain ownership, accepted message types, tools, restart policy, mailbox policy, dispatcher identity and capabilities. Current starintel-server still composes actors imperatively through globals, startup hooks, raw actor-index registration and hard-coded startup/routing.

The missing server feature is therefore a pure manifest linker/runtime-plan compiler, not another copy of actor semantics.

Three-layer authority

StarLang semantic program manifest — compiler-produced immutable actor/domain behavior and capabilities.
StarIntel Actor Deployment Manifest — inert host-runtime binding to one exact semantic artifact/digest.
StarIntel Dataset Manifest — inert dataset/catalog/storage/governance + typed component/flow bindings.

These inputs compile before side effects into one deterministic RuntimePlan consumed by the existing runtime authorities.

Actor Deployment Manifest may own

stable component instance ID/version;
exact semantic manifest/artifact reference + digest;
trusted installed adapter kind/ref;
runtime component dependencies;
workload/dispatcher profile request and bounded routee constraints;
mailbox/admission profile constrained by semantic limits;
local/Rabbit/remote ingress binding refs;
authz/lease/idempotency policy refs;
config/options schema + opaque secret refs;
readiness/health adapter refs from a closed installed vocabulary.

It may not independently redefine accepted/produced types, domain ownership, capabilities/tools, executable actor body, or self-authorize worker/thread grants. Compatible deployment restrictions may narrow a semantic contract; widening is rejected.

Dataset Manifest may own

dataset ID/version, tenant/owner;
exact schema/spec compatibility refs;
document types/membership where applicable;
storage binding refs;
validation/normalization policy refs;
indexes/views/materializations/embeddings/graph refs;
provenance, retention, publication, access, lease and research/analysis policy refs;
actor/component bindings and typed flow bindings.

flowBindings selects declared typed ports/routes. It is not an executable workflow DSL and cannot grant capabilities or make a component accept an undeclared type.

Pure RuntimePlan

Compilation produces a deterministic inert plan containing at least:

source manifest IDs/digests;
components and stable component IDs;
capability index;
lifecycle dependency graph;
typed routes;
dataset bindings;
thread/Sento-lane demand;
mailbox/admission demand;
storage binding refs;
diagnostics;
plan digest.

No actor system, thread, Rabbit/CouchDB/Valkey connection, timer, listener, secret resolution, or arbitrary plugin execution occurs during this phase.

Existing authority dependencies

#34 owns process thread grants.
#35 owns aggregate Sento execution-lane accounting.
#36 owns mailbox/admission policy.
#37 owns lifecycle graph/start-stop/reconnect.
#40 owns explicit runtime/application contracts.
#41 owns concrete adapters.
#42 owns component handles/generation/readiness.
StarLang owns actor/domain semantic declarations.

#43 links declarative inputs and feeds demands/graph/identity into those existing authorities. It does not reimplement them.

Proposed implementation slices — ALL PENDING OPERATOR APPROVAL

Slice 1 — pure manifest linker + RuntimePlan model

Fake semantic manifests and inert actor/dataset fixtures only. No production runtime effects.

Mandatory RED-first target:

semantic component identity/email accepts EmailSeed
actor binding identity/email pins semantic digest A
dataset flow routes PersonDocument -> identity/email

compileRuntimePlan(...)
=> typed incompatible-route
=> zero actor/thread/network callbacks

Untouched current server must fail because no pure manifest linker/runtime-plan compiler exists.

Sibling REDs:

semantic digest mismatch -> reject before effects;
deployment adds undeclared capability -> reject widening;
duplicate component ID -> reject;
unknown dependency / forbidden lifecycle cycle -> reject;
raw credential or arbitrary callback field -> reject;
equivalent input ordering -> identical normalized RuntimePlan.

Slice 2 — real StarLang semantic artifact linking

Consume one compiler-produced immutable StarLang manifest/lock artifact through a narrow reader; verify exact digest and narrowing rules without executing StarLang source at server startup.

Slice 3 — Dataset Manifest schema + cross-link validation

Data-only deterministic normalization. Reject incompatible component/type/storage/governance bindings before effects.

Slice 4 — existing runtime authority integration

Feed lifecycle graph to #37, process/Sento demand to #34/#35, mailbox/admission demand to #36, and component IDs to #42. Do not duplicate those algorithms.

Slice 5 — first realized actor vertical

Realize one small current actor from a validated plan. Existing compatibility entrypoint must delegate to the same plan-owned component.

Slice 6 — dataset-specific flow proof

Two fixture datasets choose different valid bindings without source changes. Neither may route undeclared types or widen capabilities.

Slice 7 — retire migrated legacy authority

Only after equivalence/restart tests: delegate/remove the corresponding global startup hook, raw actor-index entry, and hard-coded route ownership.

Acceptance criteria

StarLang semantic manifest remains the actor/domain semantic authority;
Actor Deployment Manifest references rather than duplicates semantic truth;
Dataset Manifest is data/catalog/governance + typed bindings, not executable workflow code;
invalid topology fails before long-lived side effects;
equivalent inputs produce deterministic plans;
manifests request but cannot grant process/Sento/mailbox capacity;
no raw secrets, host callbacks, live resource handles, or arbitrary code in data manifests;
runtime identity uses stable component IDs and later #42 generation-bearing handles;
two datasets can select different compatible flows without source edits;
no undeclared type can cross a compiled route;
implementation stays blocked until explicit operator authorization.

Implementation authorization

PENDING / AWAITING_OPERATOR_IMPLEMENTATION_APPROVAL

P1 priority, READY_FOR_DESIGN, completed design/adversarial review, issue state, publication, or machine output do not authorize RAGE implementation.

## ARDR reconciliation — 2026-08-29 Canonical research/design now own this issue: - Research: `lost-rob0t/starintel-auto-research/roam/research/star-server/STAR-RESEARCH-050-manifest-runtime-plan-composition.org` — `READY_FOR_DESIGN`. - Design/adversarial review: `lost-rob0t/starintel-auto-research/roam/design/star-server/STAR-MANIFEST-001-document-contracts.org` — `DESIGN_READY_FOR_OPERATOR_REVIEW`. - Auto-Research transaction: `lost-rob0t/starintel-auto-research#199`. - **Implementation authorization: PENDING / AWAITING_OPERATOR_IMPLEMENTATION_APPROVAL.** ## Current-source correction Do not implement the original issue as a second server-local actor declaration language. Current StarLang already compiles domain-server manifest semantics including stable identity, keyed/domain ownership, accepted message types, tools, restart policy, mailbox policy, dispatcher identity and capabilities. Current starintel-server still composes actors imperatively through globals, startup hooks, raw actor-index registration and hard-coded startup/routing. The missing server feature is therefore a **pure manifest linker/runtime-plan compiler**, not another copy of actor semantics. ## Three-layer authority 1. **StarLang semantic program manifest** — compiler-produced immutable actor/domain behavior and capabilities. 2. **StarIntel Actor Deployment Manifest** — inert host-runtime binding to one exact semantic artifact/digest. 3. **StarIntel Dataset Manifest** — inert dataset/catalog/storage/governance + typed component/flow bindings. These inputs compile before side effects into one deterministic `RuntimePlan` consumed by the existing runtime authorities. ## Actor Deployment Manifest may own - stable component instance ID/version; - exact semantic manifest/artifact reference + digest; - trusted installed adapter kind/ref; - runtime component dependencies; - workload/dispatcher profile request and bounded routee constraints; - mailbox/admission profile constrained by semantic limits; - local/Rabbit/remote ingress binding refs; - authz/lease/idempotency policy refs; - config/options schema + opaque secret refs; - readiness/health adapter refs from a closed installed vocabulary. It may **not** independently redefine accepted/produced types, domain ownership, capabilities/tools, executable actor body, or self-authorize worker/thread grants. Compatible deployment restrictions may narrow a semantic contract; widening is rejected. ## Dataset Manifest may own - dataset ID/version, tenant/owner; - exact schema/spec compatibility refs; - document types/membership where applicable; - storage binding refs; - validation/normalization policy refs; - indexes/views/materializations/embeddings/graph refs; - provenance, retention, publication, access, lease and research/analysis policy refs; - actor/component bindings and typed flow bindings. `flowBindings` selects declared typed ports/routes. It is **not** an executable workflow DSL and cannot grant capabilities or make a component accept an undeclared type. ## Pure RuntimePlan Compilation produces a deterministic inert plan containing at least: - source manifest IDs/digests; - components and stable component IDs; - capability index; - lifecycle dependency graph; - typed routes; - dataset bindings; - thread/Sento-lane demand; - mailbox/admission demand; - storage binding refs; - diagnostics; - plan digest. No actor system, thread, Rabbit/CouchDB/Valkey connection, timer, listener, secret resolution, or arbitrary plugin execution occurs during this phase. ## Existing authority dependencies - #34 owns process thread grants. - #35 owns aggregate Sento execution-lane accounting. - #36 owns mailbox/admission policy. - #37 owns lifecycle graph/start-stop/reconnect. - #40 owns explicit runtime/application contracts. - #41 owns concrete adapters. - #42 owns component handles/generation/readiness. - StarLang owns actor/domain semantic declarations. #43 links declarative inputs and feeds demands/graph/identity into those existing authorities. It does not reimplement them. ## Proposed implementation slices — ALL PENDING OPERATOR APPROVAL ### Slice 1 — pure manifest linker + RuntimePlan model Fake semantic manifests and inert actor/dataset fixtures only. No production runtime effects. **Mandatory RED-first target:** ```text semantic component identity/email accepts EmailSeed actor binding identity/email pins semantic digest A dataset flow routes PersonDocument -> identity/email compileRuntimePlan(...) => typed incompatible-route => zero actor/thread/network callbacks ``` Untouched current server must fail because no pure manifest linker/runtime-plan compiler exists. Sibling REDs: - semantic digest mismatch -> reject before effects; - deployment adds undeclared capability -> reject widening; - duplicate component ID -> reject; - unknown dependency / forbidden lifecycle cycle -> reject; - raw credential or arbitrary callback field -> reject; - equivalent input ordering -> identical normalized RuntimePlan. ### Slice 2 — real StarLang semantic artifact linking Consume one compiler-produced immutable StarLang manifest/lock artifact through a narrow reader; verify exact digest and narrowing rules without executing StarLang source at server startup. ### Slice 3 — Dataset Manifest schema + cross-link validation Data-only deterministic normalization. Reject incompatible component/type/storage/governance bindings before effects. ### Slice 4 — existing runtime authority integration Feed lifecycle graph to #37, process/Sento demand to #34/#35, mailbox/admission demand to #36, and component IDs to #42. Do not duplicate those algorithms. ### Slice 5 — first realized actor vertical Realize one small current actor from a validated plan. Existing compatibility entrypoint must delegate to the same plan-owned component. ### Slice 6 — dataset-specific flow proof Two fixture datasets choose different valid bindings without source changes. Neither may route undeclared types or widen capabilities. ### Slice 7 — retire migrated legacy authority Only after equivalence/restart tests: delegate/remove the corresponding global startup hook, raw actor-index entry, and hard-coded route ownership. ## Acceptance criteria - StarLang semantic manifest remains the actor/domain semantic authority; - Actor Deployment Manifest references rather than duplicates semantic truth; - Dataset Manifest is data/catalog/governance + typed bindings, not executable workflow code; - invalid topology fails before long-lived side effects; - equivalent inputs produce deterministic plans; - manifests request but cannot grant process/Sento/mailbox capacity; - no raw secrets, host callbacks, live resource handles, or arbitrary code in data manifests; - runtime identity uses stable component IDs and later #42 generation-bearing handles; - two datasets can select different compatible flows without source edits; - no undeclared type can cross a compiled route; - implementation stays blocked until explicit operator authorization. ## Implementation authorization `PENDING / AWAITING_OPERATOR_IMPLEMENTATION_APPROVAL` P1 priority, `READY_FOR_DESIGN`, completed design/adversarial review, issue state, publication, or machine output do **not** authorize RAGE implementation.