[P1-05] Implement actor manifests and dataset manifests as validated runtime configuration #43

New issue

Open

opened 2026-07-22 00:17:29 +00:00 by lost-rob0t · 0 comments

lost-rob0t commented

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

(Migrated from github.com)

Auto-research requirement

Canonical StarIntel research defines actor manifests for capabilities/lifecycle and dataset manifests for declarative document flows. Current routing is spread across global hooks, hardcoded queue bindings, hardcoded actor names, and init Lisp.

Actor manifest fields

component/actor id and version
accepted/produced message/document types
capabilities
dispatcher and router-pool assignment
routee count and routing strategy/key
mailbox capacity and overload policy
dependencies and startup order
lease requirements
retry/idempotency behavior
health/readiness checks
lifecycle/restart policy
local/Rabbit/remote route bindings

Dataset manifest fields

dataset id, tenant/owner, storage database/partition
accepted document types/schema versions
validation/normalization pipeline
actor/component bindings
routing keys and flows
search/index/view configuration
retention, provenance, authorization, and lease policy
embedding/analysis/research-job configuration where enabled

Requirements

Validated data format; no arbitrary code execution.
Manifest compilation produces a runtime plan and thread-budget contribution before startup.
Reject missing components, route cycles where forbidden, incompatible dtypes, duplicate routes, and over-budget plans.
Preserve an explicit extension mechanism for trusted Lisp plugins separately.

Acceptance tests

A valid manifest starts the declared components/routes.
Invalid dependencies, unknown dtypes, duplicate actor ids, and over-budget dispatchers fail before threads start.
The generated runtime plan is inspectable and deterministic.
Two datasets can use different flows without changing server source.

## Auto-research requirement Canonical StarIntel research defines actor manifests for capabilities/lifecycle and dataset manifests for declarative document flows. Current routing is spread across global hooks, hardcoded queue bindings, hardcoded actor names, and init Lisp. ## Actor manifest fields - component/actor id and version - accepted/produced message/document types - capabilities - dispatcher and router-pool assignment - routee count and routing strategy/key - mailbox capacity and overload policy - dependencies and startup order - lease requirements - retry/idempotency behavior - health/readiness checks - lifecycle/restart policy - local/Rabbit/remote route bindings ## Dataset manifest fields - dataset id, tenant/owner, storage database/partition - accepted document types/schema versions - validation/normalization pipeline - actor/component bindings - routing keys and flows - search/index/view configuration - retention, provenance, authorization, and lease policy - embedding/analysis/research-job configuration where enabled ## Requirements - Validated data format; no arbitrary code execution. - Manifest compilation produces a runtime plan and thread-budget contribution before startup. - Reject missing components, route cycles where forbidden, incompatible dtypes, duplicate routes, and over-budget plans. - Preserve an explicit extension mechanism for trusted Lisp plugins separately. ## Acceptance tests - A valid manifest starts the declared components/routes. - Invalid dependencies, unknown dtypes, duplicate actor ids, and over-budget dispatchers fail before threads start. - The generated runtime plan is inspectable and deterministic. - Two datasets can use different flows without changing server source.