SENTO-000 Managed Component Runtime

Extend Sento¹ into a complete actor runtime² for composing independently managed gservers³ inside one actor system⁴ and across Sento nodes⁵.

The extension supplies generic runtime facilities. It must not contain StarIntel⁶ domains, intelligence collection rules, document schemas, case logic, or application-specific policy.

Primary consumer:

• STAR-SERVER-000 Composable Intelligence GServer Domains

Research basis:

• SENTO-000 Sento Runtime Analysis
• SENTO-000 ZeroMQ Transport Analysis

The design is based on source review of:

• repository: mdbergmann/cl-gserver
• branch: master
• commit: a889b8375709ca9396bba5d06b6e460689a23716
• Sento version: 3.4.3
• Sento remoting⁷ version: 0.1.0
• ZeroMQ⁸ engine: libzmq⁹
• review date: 2026-07-19

Every implementation record must identify the exact Sento, libzmq, Common Lisp binding, and operating-system package versions being used.

Sento already provides:

• actors¹⁰
• actor systems
• nested actor contexts¹¹
• hierarchical actor paths¹²
• custom actor classes¹³
• actor lifecycle hooks¹⁴
• actor watching¹⁵
• shared and pinned dispatchers¹⁶
• bounded and unbounded mailboxes¹⁷
• bounded and unbounded queues¹⁸
• random and round-robin routers¹⁹
• event streams²⁰
• futures²¹
• tasks²²
• finite-state-machine actors²³
• stashing actors²⁴
• wheel timers²⁵
• local actor references²⁶
• remote actor references
• TCP transport²⁷
• TLS support²⁸
• a serializer protocol²⁹

The extension must use these facilities rather than replace them.

Use one Sento actor system per operating-system process⁴⁰ by default.

Inside the actor system, compose managed components⁴¹ under supervisor actors⁴².

Every application domain receives:

• one root supervisor
• one dedicated control dispatcher
• one default domain dispatcher
• zero or more subdomain dispatchers
• one optional scoped event stream
• one component registry entry
• one or more ingress actors⁴³
• zero or more managed router pools
• zero or more optional ZeroMQ reactor components⁴⁴
• lifecycle, readiness, health, overload, and metrics state

Use another process when the requirement is actual process isolation⁴⁵, independent scaling, independent deployment, privilege separation, or crash containment.

Use multiple actor systems inside one process only for tests, compatibility bridges, staged migration, or a measured runtime-isolation requirement.

Add an actor failure policy⁴⁶ selected when an actor is created.

Proposed values:

• :resume: preserve current behavior; return a handler-error result and keep processing
• :stop: stop the actor and publish a failed termination record
• :escalate: stop the actor and mark the failure for its supervisor or watcher
• :custom: call a user-supplied failure-directive function

Proposed creation options:

(ac:actor-of context
  :receive receiver
  :failure-policy :escalate
  :failure-classifier classifier)

A failure classifier receives the actor reference, message, sender, condition, actor state, and mailbox metadata. It returns a failure directive⁴⁷.

The default remains :resume for backward compatibility⁴⁸.

Replace reason-free stop notifications with a structured value while retaining a compatibility notification.

(defstruct termination-record
  actor
  actor-path
  actor-name
  actor-generation
  reason
  condition
  failed-message-summary
  started-at
  stopped-at
  parent-path
  metadata)

Proposed reasons:

• :normal
• :explicit-stop
• :parent-stop
• :handler-failure
• :initialization-failure
• :mailbox-failure
• :dispatcher-failure
• :transport-failure
• :forced-stop
• :shutdown-timeout

Watchers receive:

(list :terminated termination-record)

The old (:stopped . actor) notification may remain behind a compatibility option during migration.

Add an actor generation number⁴⁹ or restart incarnation identifier⁵⁰.

A restarted actor may reuse the same logical name and path, but monitoring, component handles, and remote replies must distinguish the old instance from the new instance.

Expose public read-only operations:

(mailbox-depth actor)
(mailbox-capacity actor)
(mailbox-bounded-p actor)
(mailbox-processed-count actor)
(mailbox-rejected-count actor)
(mailbox-running-p actor)

Add configurable bounded-mailbox policies:

• :signal: signal queue-full as today
• :reject: return a structured rejected result
• :drop-new: discard the arriving message and record it
• :drop-old: discard the oldest queued message and record it
• :reply-busy: send a structured busy response when a sender exists
• :block: wait for capacity with a mandatory deadline
• :custom: call an overload-policy function

Blocking without a deadline is forbidden because actor-to-actor blocking can deadlock⁵¹ the runtime.

Every rejected or dropped message increments metrics and emits an overload event.

Add stop modes:

• :discard: current behavior
• :drain: finish queued messages before stopping
• :deadline: drain until a deadline, then discard remaining messages
• :handoff: return or transfer queued messages to a replacement actor

Extend routing with a message-aware strategy protocol:

(defgeneric select-routee (strategy message routees routing-context))

Add public routee operations:

(add-routee router routee)
(remove-routee router routee)
(replace-routees router routees)
(routees router)

Built-in strategies:

• random
• round robin
• least mailbox depth
• consistent hash⁵²
• rendezvous hash⁵³
• explicit key function
• broadcast⁵⁴

The existing count-only custom strategy remains supported as a compatibility adapter.

Expose:

(dispatcher-worker-count dispatcher)
(dispatcher-running-worker-count dispatcher)
(dispatcher-queue-depth dispatcher)
(dispatcher-processed-count dispatcher)
(dispatcher-rejected-count dispatcher)
(dispatcher-status dispatcher)

Dynamic dispatcher resizing is a later capability. Initial implementations may require restart to change worker count.

Add a stable actor-system identifier⁵⁵ for component handles, remoting, ZeroMQ envelopes, metrics, termination records, stale-reference detection, and multi-system tests.

Remove extension dependence on private asys::timeout-timer access. Export a supported timeout scheduling protocol or route all component timers through the public scheduler.

Define a child specification⁵⁷ containing:

• logical identifier
• actor name
• start function
• initialization arguments
• dispatcher identifier
• mailbox type
• queue capacity
• overload policy
• failure policy
• restart class
• shutdown mode
• shutdown deadline
• dependencies
• readiness probe
• health probe
• metadata

Restart classes:

• :permanent: restart after normal or abnormal termination
• :transient: restart only after abnormal termination
• :temporary: never restart

Child types:

• :worker
• :supervisor
• :router-pool
• :transport-reactor
• :component

A supervisor owns child specifications and current child instances.

Required restart strategies⁵⁸:

• :one-for-one: restart only the failed child
• :one-for-all: stop and restart every child
• :rest-for-one: restart the failed child and every child started after it

Required controls:

• maximum restart count
• restart window
• exponential backoff⁵⁹
• optional jitter⁶⁰
• startup timeout
• readiness timeout
• shutdown timeout
• escalation target
• deterministic startup order
• reverse shutdown order
• child generation tracking
• structured lifecycle events

Supervisor states:

• :defined
• :starting
• :ready
• :degraded
• :restarting
• :stopping
• :stopped
• :failed

The supervisor may use Sento FSM facilities, but the child table, restart window, and lifecycle events must remain explicit and testable.

A component may declare child dependencies as a directed acyclic graph⁶¹.

Startup rules:

1. Validate that dependency identifiers exist.
2. Reject cycles.
3. Start dependencies before dependents.
4. Wait for declared readiness before starting dependents.
5. Shut down dependents before dependencies.

Readiness⁶² means the component can accept new work.

Health⁶³ means the component is functioning within its declared operating limits.

A component can be alive but not ready, or ready but degraded.

Probes must have deadlines and must not block the supervisor dispatcher indefinitely.

A managed component is a supervisor-owned actor subtree with stable logical identity, root supervisor, declared children, domain dispatcher tree, optional scoped event stream, ingress references, capability metadata, lifecycle state, health and readiness state, metrics namespace, and local or remote location.

Public operations:

(define-component ...)
(start-component runtime component-spec)
(stop-component runtime component-id &key mode deadline)
(restart-component runtime component-id)
(component-ref runtime component-id)
(component-status runtime component-id)
(component-health runtime component-id)
(component-ready-p runtime component-id)

A component handle⁶⁴ hides whether a component is local in the current actor system, local in another actor system, remote through Sento remoting, or remote through a ZeroMQ transport adapter.

Minimum fields:

• component identifier
• actor-system identifier
• node identifier
• process identifier
• ingress reference or transport route
• component generation
• capability set
• transport kind
• metadata

Application code routes through handles rather than arbitrary actor-path discovery.

The component registry indexes component identifier, capability, accepted message type, actor-system identifier, node identifier, lifecycle state, readiness state, generation, and transport kind.

The registry supports register, replace, unregister, lookup by identifier, lookup by capability, subscribe to changes, and resolve local or remote handle.

A component may create a private event stream beneath its supervisor actor context.

The managed event bus must watch subscribers, remove terminated subscribers, use typed event envelopes, report subscriber count, report delivery failures, support explicit close, and stop with the component.

The system event stream remains available for runtime-wide events.

A managed router pool⁶⁵ is a supervisor-owned group of equivalent routee actors⁶⁶.

Required operations:

(start-router-pool supervisor pool-spec)
(scale-router-pool pool-ref new-size)
(router-pool-status pool-ref)
(router-pool-routees pool-ref)
(router-pool-metrics pool-ref)
(stop-router-pool pool-ref &key mode deadline)

Required behavior:

• create routees from one child template
• watch every routee
• replace failed routees according to policy
• scale up and down
• drain a routee before planned removal
• reject or buffer work when no routee is ready
• emit lifecycle and overload events
• expose membership generation
• expose routee health and mailbox pressure

A keyed router⁶⁷ maps messages with the same key to the same routee while membership is stable.

Supported key examples include target, account, case, sensor, program, dataset, and tenant.

When membership changes, the pool must define which keys move, how in-flight work finishes, whether state is transferred, whether a key is temporarily paused, and how stale-route messages are handled.

Stateful keyed actors must not be scaled with random routing.

The pool manager uses a control dispatcher⁶⁸.

Routees process application messages on a domain or subdomain dispatcher, called the data plane⁶⁹.

Control messages must not wait behind saturated application queues.

Dispatchers are per domain by default.

A domain owns a dispatcher namespace and may define subdomains inside the same process.

Workload-class dispatchers are optional shared infrastructure. They are not the primary ownership boundary.

Recommended identifier form:

:domain/humint/control
:domain/humint/default
:domain/humint/source-management
:domain/humint/interviews

:domain/socmint/control
:domain/socmint/default
:domain/socmint/platform-x
:domain/socmint/platform-telegram
:domain/socmint/media

:domain/sigint/control
:domain/sigint/default
:domain/sigint/ingest
:domain/sigint/decode
:domain/sigint/correlation

:domain/cyber/control
:domain/cyber/default
:domain/cyber/discovery
:domain/cyber/scanning
:domain/cyber/analysis

:domain/bbp/control
:domain/bbp/default
:domain/bbp/programs
:domain/bbp/enumeration
:domain/bbp/findings

:domain/threat-intel/control
:domain/threat-intel/default
:domain/threat-intel/feeds
:domain/threat-intel/enrichment
:domain/threat-intel/correlation

These are examples. A domain manifest defines the actual subdomains.

Every domain receives at least:

• a small control dispatcher for supervisors, registries, health, routing control, and transport control
• a default dispatcher for normal domain actors

A domain may add subdomain dispatchers when one area can saturate the domain, blocks on external I/O⁷⁰, is CPU-heavy⁷¹, requires different queue limits, requires independent scaling, or requires dedicated latency targets.

Application work must never run on the domain control dispatcher.

The control dispatcher is reserved for supervisor messages, routee lifecycle, transport lifecycle, readiness and health, registry changes, overload decisions, shutdown coordination, and metrics snapshots.

A subdomain is a named workload or organizational area inside a domain process.

A subdomain may contain its own dispatcher, supervisor, routee pools, queue policies, event bus, ZeroMQ reactor, and metrics prefix.

A subdomain is not automatically a separate process or actor system.

The runtime may define platform-owned dispatchers:

• :platform/control
• :platform/remoting
• :platform/zeromq
• :platform/registry
• :platform/storage

Domain actors use platform services through declared handles. Platform dispatchers do not replace domain dispatchers.

Before startup, the runtime computes total shared dispatcher workers, total pinned actors, ZeroMQ reactor threads, libzmq I/O threads⁷², timer threads, remoting transport threads, and configured maximum process thread count.

Startup fails or warns when the declared dispatcher and transport tree exceeds the configured thread budget⁷³.

Use Sento remoting for direct Sento-to-Sento actor communication when location-transparent actor references are required.

Use ZeroMQ for explicit component, service, work, and event transport patterns where brokerless asynchronous messaging or non-Sento peers are useful.

Use Star Router⁷⁹ for client-facing routing, heterogeneous services⁸⁰, and application-level cross-process routing where the destination is not a raw Sento actor reference.

The three paths are adapters behind the same component-handle protocol. Application actors do not select raw sockets directly.

Immediately change the default S-expression deserializer to bind:

(let ((*read-eval* nil))
  (read-from-string string))

This removes reader evaluation⁸¹ but does not make arbitrary S-expressions a complete untrusted-data format.

Add a production serializer using an explicit schema⁸², bounded nesting, bounded collection sizes, and a type allowlist.

Remote peers must not address every local actor path.

Add an export registry containing exported logical name, local actor reference, allowed message types, allowed peers or peer capabilities, maximum payload size, maximum concurrent asks, queue policy, and audit hook.

Remote references resolve exported names rather than arbitrary internal paths unless an explicit development-only option enables path routing.

When TLS is enabled, map the authenticated certificate identity⁸³ to a peer principal⁸⁴.

A policy decision receives the principal, exported target, message type, payload metadata, current quota, and connection metadata. It returns allow or deny plus a structured reason.

Extend the envelope with protocol version, source actor-system identifier, source component identifier, destination export name, message identifier, correlation identifier, trace identifier, deadline, attempt number, content type, and principal metadata supplied by the transport.

Carry the caller deadline over the network. Reject expired requests before dispatching them.

Use structured error envelopes for target not found, target not exported, access denied, unsupported message type, serializer failure, message too large, receiver overloaded, actor stopped, handler failure, timeout, and protocol mismatch.

Document the default semantics:

• remote tell: at-most-once⁸⁵
• remote ask-s: at-most-once request attempt with one correlated response
• remote ask: at-most-once request attempt with one future result

Automatic retries are disabled by default.

A caller that enables retries must provide an idempotency key⁸⁶ or explicitly accept duplicate processing.

ZeroMQ is an optional transport backend and process bridge.

ZeroMQ does not replace:

• local Sento actor mailboxes
• per-domain dispatchers
• Sento supervision
• the component registry
• local managed routers
• the Star Router client boundary

ZeroMQ transports messages between processes, languages, or runtime components after a component handle selects the ZeroMQ adapter.

A ZeroMQ context⁸⁷ may be shared between threads, but most classic ZeroMQ sockets are not thread-safe⁸⁸. A socket must be created, used, and closed by its owning thread.

Sento actors on shared dispatchers may execute on different worker threads. They must never call a classic ZeroMQ socket directly.

The runtime therefore introduces a ZeroMQ reactor component that owns all socket calls on one dedicated thread.

Each process contains:

Sento actor system
└── /internal/transports/zeromq
    ├── context-supervisor
    ├── zap-handler
    ├── monitor-collector
    └── domain reactors
        ├── humint
        ├── socmint
        ├── sigint
        ├── cyber
        ├── bbp
        └── threat-intel

One process-wide ZeroMQ context is the default.

A domain may create one reactor for the whole domain or separate reactors for subdomains when isolation, socket count, endpoint ownership, or measured load justifies it.

Multiple contexts require an explicit reason because every context owns its own internal ZeroMQ I/O threads and socket set.

A ZeroMQ reactor component contains:

• one supervisor actor on the domain control dispatcher
• one bounded outbound command queue⁸⁹
• one dedicated reactor thread
• one or more sockets owned only by that reactor thread
• one poll loop⁹⁰
• one pending-request table
• one endpoint registry
• one connection-monitor collector
• one serializer
• one policy adapter
• metrics and lifecycle state

The supervisor actor owns the reactor lifecycle. The reactor thread owns the sockets.

The supervisor and ordinary domain actors never call zmq_send, zmq_recv, zmq_close, zmq_bind, or zmq_connect directly.

1. A domain actor sends a normal Sento message to the ZeroMQ bridge actor.
2. The bridge validates the component handle, schema, deadline, payload limit, and policy.
3. The bridge places a transport command into the bounded outbound command queue.
4. The reactor thread drains commands and performs socket operations.
5. A send result or overload result is returned through the original Sento sender or correlation map.

1. The reactor poll loop receives a ZeroMQ message.
2. The reactor validates frame count and hard size limits before allocation or decoding.
3. The reactor decodes only the fixed transport header.
4. The reactor submits the envelope to a domain ingress actor.
5. The ingress actor performs schema validation, authorization, deadline checks, and target resolution.
6. The ingress actor sends the payload to the destination component.
7. Replies travel through the same reactor using the stored routing envelope and correlation identifier.

The first implementation uses a dedicated reactor thread with a bounded command queue and a finite ZeroMQ poll timeout.

The loop alternates between:

• polling owned ZeroMQ sockets
• draining a bounded number of outbound commands
• expiring timed-out pending requests
• publishing metrics snapshots
• checking the stop flag

A later implementation may add a platform wakeup descriptor⁹¹ to interrupt the poll immediately when a new outbound command arrives.

A normal Sento pinned actor receive function must not block forever in zmq_poll because that would prevent its Sento mailbox from processing lifecycle commands.

• inproc://: internal ZeroMQ control, ZAP, proxy control, and socket-monitor channels inside one process
• ipc://: same-host cross-process communication when the operating system supports Unix-domain-style endpoints¹⁰²
• tcp://: communication across hosts or containers

Normal same-process Sento actors use Sento messages, not inproc:// ZeroMQ, unless the message must cross into a ZeroMQ-owned reactor or external library.

The ROUTER routing identity stays outside the application envelope.

Application multipart frame layout:

Frame 0: protocol magic and version
Frame 1: message kind
Frame 2: message identifier
Frame 3: correlation identifier or empty
Frame 4: trace identifier or empty
Frame 5: source node and component
Frame 6: target component export
Frame 7: operation or event topic
Frame 8: deadline
Frame 9: content type and schema identifier
Frame 10: flags
Frame 11: payload

The transport layer rejects unexpected frame counts, oversized frames, unsupported versions, and malformed fixed-width fields before payload deserialization.

Supported message kinds:

• tell
• ask
• reply
• error
• event
• work
• cancel
• heartbeat

ZeroMQ is a transport, not a serializer.

The ZeroMQ adapter uses the same safe schema serializer defined for Sento remoting.

Never pass an untrusted network frame directly to Common Lisp read or read-from-string with reader evaluation enabled.

Create sento-zmq as a small ASDF system using CFFI¹⁰³ against a pinned stable libzmq package.

The binding exposes only the reviewed functions and options used by this design.

The existing orivej/pzmq project may be used as a bootstrap reference or fork, but it must not be accepted without a compatibility layer and complete tests for the used surface. Its latest reviewed commit is from 2021, and its README states that functions outside examples and tests may be untested.

Required binding surface:

• context create, configure, shutdown, and terminate
• socket create and close
• bind, unbind, connect, and disconnect
• multipart message send and receive
• poll
• socket options
• socket monitor
• CURVE key and authentication options
• error-number and error-string access
• version query

The binding must represent byte vectors without converting binary payloads through strings.

Every socket specification declares:

• socket type
• bind or connect endpoints
• routing identifier
• send high-water mark
• receive high-water mark
• send timeout
• receive timeout
• immediate-connect behavior
• router-mandatory behavior
• linger deadline
• heartbeat settings
• reconnect settings
• maximum frame size
• security mechanism
• monitor events

Recommended runtime defaults:

• finite ZMQ_LINGER rather than infinite linger
• non-zero ZMQ_SNDHWM and ZMQ_RCVHWM
• ZMQ_IMMEDIATE enabled for outbound sockets where queuing before a connection would hide unavailability
• ZMQ_ROUTER_MANDATORY enabled on ROUTER sockets so unroutable messages return an error rather than disappearing silently
• non-blocking sends or finite ZMQ_SNDTIMEO
• finite receive polling intervals
• explicit heartbeat and reconnect policy

An EAGAIN¹⁰⁴ result maps to a structured overload result. An EHOSTUNREACH¹⁰⁵ result maps to a route-unavailable result.

For tcp:// production endpoints, use CurveZMQ¹⁰⁶ and ZAP¹⁰⁷.

Each process runs one ZAP handler bound to:

inproc://zeromq.zap.01

The ZAP handler maps a client public key to:

• principal
• node identifier
• allowed component exports
• allowed operations
• tenant or organization
• quota class
• audit metadata

The ZAP handler starts before any accepting ZeroMQ socket.

For ipc:// endpoints, also apply file ownership and permission controls. IPC permissions do not replace application-level target and operation policy.

Do not use the PLAIN mechanism¹⁰⁸ on an untrusted network because it does not provide confidentiality.

ZeroMQ backpressure is coordinated with Sento backpressure.

The path contains at least:

1. Sento sender mailbox
2. component ingress mailbox
3. bridge command queue
4. ZeroMQ per-peer send queue
5. remote receive queue
6. remote ingress mailbox

Every layer is bounded and has a declared policy.

High-water marks limit queued ZeroMQ messages per peer. Reaching a high-water mark may block, return EAGAIN, or drop messages depending on socket type and options.

The adapter must never assume that a successful local enqueue means the remote component processed the message.

ZeroMQ queues are memory-based and are not a durable message log¹⁰⁹.

Default semantics:

• ROUTER/DEALER tell: at-most-once transport attempt
• ROUTER/DEALER ask: at-most-once transport attempt with application correlation
• PUSH/PULL work: at-most-once transport attempt
• PUB/SUB event: best-effort¹¹⁰ and may be missed by disconnected or late subscribers

Automatic retries are disabled by default.

A retry requires an idempotency key and a declared duplicate-handling policy.

A component that needs durable replay uses a database, event log, RabbitMQ¹¹¹, or another declared durable broker rather than pretending ZeroMQ is durable.

Enable zmq_socket_monitor for connection-oriented sockets.

A dedicated monitor collector receives monitor events over an internal PAIR socket and converts them into typed Sento runtime events.

Monitor at least:

• connected
• connect delayed
• connect retried
• listening
• bind failed
• accepted
• accept failed
• closed
• close failed
• disconnected
• handshake succeeded
• handshake protocol failure
• handshake authentication failure

Do not expose native file descriptors from monitor events as stable actor state.

A steerable proxy may be used for:

• XPUB/XSUB event distribution
• ROUTER/DEALER broker topologies
• traffic capture for metrics or testing

Every proxy runs in a dedicated thread or process and has:

• frontend socket
• backend socket
• optional capture socket
• control socket
• supervisor child specification
• finite shutdown deadline

The control channel supports pause, resume, and terminate.

The ZeroMQ reactor supervisor treats these as failures:

• reactor thread exit
• context termination outside shutdown
• socket bind failure
• repeated authentication failure above policy threshold
• repeated poll failure
• unrecoverable serializer failure
• command queue corruption
• monitor channel failure

Restart rules:

1. Stop component admission.
2. Mark transport not ready.
3. Fail or cancel pending requests with structured transport errors.
4. Close sockets on the owning reactor thread.
5. Join the reactor thread.
6. Increase transport generation.
7. Recreate sockets and endpoints.
8. Wait for bind, connect, and authentication readiness.
9. Reopen admission.

Replies carrying an old transport or component generation are rejected as stale.

1. Reject new transport work.
2. Stop subscriptions and external admission.
3. Drain the bridge command queue until the deadline.
4. Resolve or cancel pending asks.
5. Pause and terminate proxies.
6. Close sockets on their owner threads using finite linger.
7. Join reactor and monitor threads.
8. Stop the ZAP handler after accepting sockets are closed.
9. Shut down and terminate the process-wide ZeroMQ context.
10. Continue normal Sento component and actor-system shutdown.

The context must never terminate while live sockets remain.

A ZeroMQ component handle contains:

• transport kind :zeromq
• local reactor identifier
• remote node identifier
• remote component export
• endpoint identifier
• security policy identifier
• serializer identifier
• current component generation
• current transport generation

Sending through the handle resolves to the local domain reactor. The application actor never receives a raw socket pointer.

• no classic ZeroMQ socket is called from more than one thread
• all socket creation and closure occur on the owner reactor thread
• one domain reactor failure does not stop sibling domains
• one subdomain reactor may restart without restarting the whole domain
• ROUTER mandatory mode returns structured route-unavailable errors
• high-water saturation returns structured overload results
• finite linger prevents shutdown from blocking forever
• malformed multipart messages are rejected before payload decoding
• old-generation replies are rejected
• expired deadlines are rejected before actor dispatch
• unauthorized CURVE keys are denied by ZAP
• allowed CURVE keys map to the correct principal and capabilities
• socket monitor events become typed runtime events
• proxy pause, resume, and terminate work under load
• disconnected PUB/SUB subscribers are documented as missing events
• process restart leaves no socket, context, or reactor thread leak
• component handles behave consistently across local, Sento-remoting, ZeroMQ, and Star Router adapters

• pin the reviewed Sento commit
• pin a stable libzmq package
• run Sento core tests
• run Sento remoting tests
• build a minimal CFFI ZeroMQ probe
• record thread counts and benchmark baseline
• add regression fixtures for discovered behavior

• add failure-policy hook
• add failure classifier
• add structured termination record
• add actor generation
• update watching
• preserve compatibility mode
• test handler failure on shared and pinned dispatchers

• expose mailbox metrics
• add overload policies
• add drain and deadline stop modes
• add structured overload events
• test bounded queues under shutdown and restart

• implement child specifications
• implement supervisor actor
• implement restart classes
• implement one-for-one, one-for-all, and rest-for-one
• implement restart windows and backoff
• implement dependency startup and reverse shutdown

• implement domain dispatcher declaration
• implement subdomain dispatcher declaration
• implement thread-budget validation
• expose dispatcher metrics
• test domain saturation isolation

• add routee removal and replacement
• add message-aware strategy protocol
• implement pool manager
• implement keyed routing
• implement draining scale-down
• implement routee failure replacement

• implement component definition
• implement component handles
• implement registry
• implement scoped event buses
• implement readiness and health

• expose typed lifecycle events
• expose metrics snapshots
• add trace-context propagation
• add benchmark instrumentation

• disable reader evaluation
• add schema serializer
• add actor export registry
• add peer policy
• require TLS in production mode
• add deadlines and structured errors
• document delivery semantics
• add quotas and cancellation

• create sento-zmq
• bind the required libzmq API through CFFI
• implement process context supervisor
• implement domain reactor and bounded command queue
• implement poll loop and socket ownership assertions
• implement ROUTER/DEALER component transport
• implement socket monitoring
• implement structured overload and route errors

• implement CURVE key loading
• implement ZAP handler and principal mapping
• implement explicit component export policy
• implement XPUB/XSUB event bridge
• implement steerable proxy supervision
• implement optional PUSH/PULL work bridge
• implement IPC endpoint permissions

• consume component definitions from actor manifests
• create per-domain dispatcher trees
• start six domain components
• start selected domain or subdomain ZeroMQ reactors
• expose domain ingress handles
• select local, Sento remoting, ZeroMQ, or Star Router through component handles