app.agent-host

LSSM OS Agent Host

@lssm-tech/app.agent-host is the single deployable host for governed agent applications. Its first production vertical is Release Steward, but the host is shared by the wider CommunicationOS and CompanyOS omnichannel program.

Run bun run test for the complete package suite. It runs test files sequentially in fresh Bun processes so native/WASM and HTTP state cannot leak between suites. Test helpers use .test-support.ts names and are imported by actual test files. The Release Steward replay qualification intentionally takes over 200 seconds; its declared 270-second timeout remains in force.

The host claims strict Durable Queue V2 envelopes, passes each exact claim to an injected Runtime Node V3 service, and acknowledges transport only from the service's durable operation receipt. Queue fences never authorize effects. Indeterminate work remains unacknowledged and is reconciled from SQL before a retry. Shutdown stops new claims and drains bounded in-flight work.

The application lifecycle is install_disabled -> configured -> qualified -> active, with paused, revoked, and uninstalled safety states. Readiness requires active lifecycle, a recent queue cycle, and exact qualified component bindings for Runtime Node, queue, topology state, durable agent state, task graph, CommunicationOS gateway, and organizational policy.

startAgentHostApplicationV1 is the deployable composition boundary: it starts the governed consumer, serves liveness/readiness, forwards cancellation, and drains bounded in-flight work.

Production entrypoint and readiness matrix

src/server.ts (what build and start target) calls startAgentHostServerV1, which parses explicit AGENT_HOST_* keys, loads the qualified deployment document and, only when every binding is present, composes the PostgreSQL T1 host (composeAgentHostT1ServerV1): verified queue/topology profiles, the installation lifecycle, Runtime Node V3 with the Postgres dispatch authority, a verify-only Connect authority whose policy is the standing mandate, pinned component qualifications and registered effect providers. Otherwise it serves /healthz (live) and a /readyz 503 whose body names each blocking capability; a bootstrap artifact is never usable.

Connect evidence (createPostgresConnectAuthorityStoreV1) and standing mandates (createPostgresAgentStandingMandateStoreV1) are read from @lssm-tech/integration.lssm-os-state-postgres through the runtime role; apply its LSSM_OS_POSTGRES_CONNECT_AUTHORITY_MIGRATION_V1 and LSSM_OS_POSTGRES_AGENT_STANDING_MANDATE_MIGRATION_V1 first. Windowed mandate grants reserve their slot atomically per exact Connect request digest.

Request-driven duties (single effect path)

• POST /v1/communication/runtime-node/delivery-effects (communication.runtime-node.delivery-effect.v1, bearer workload token, required Idempotency-Key equal to the outbox record key) admits one delivery through the Connect-side effectAdmission binding and the durable queue, then answers a CommunicationDeliveryEffectResult from the Runtime Node operation and provider receipt. Not admitted → retryable rejected; admitted but unobservable → indeterminate with the work-order digest.
• POST /v1/agent-host/protocol-runs (lssm.agent-host.protocol-run-admission.v1) admits or exactly resumes a protocol run for the installed application. Application, compiler and model route are host-bound (protocolRuns binding); artifacts persist in the canonical Postgres protocol artifact store.
• createAgentHostCodingAgentControlPortV1 implements the S08 CodingAgentControlPortV1 over the same admission path; anything unproven throws AgentHostCodingControlUncertainError and is never re-sent.

Each duty has its own optional readiness row (delivery_effects, coding_control, protocol_runs, bounded_agent_runs) and never blocks worker readiness.

Bounded agent runs

createAgentHostBoundedAgentRunnerV1 composes the @lssm-tech/lib.ai-agent bounded-epoch runner for a ContractSpecAgent (any target with its generate), so a run is bounded by a host-owned epoch policy (per-epoch token, wall-time and tool-call budget, finite renewals, a no-progress stop and maxResumes) and not only by the agent's maxSteps. Each generate call is capped at the remaining tool-call budget, receives the epoch abort signal and runs as one write-ahead journaled effect (agent-host:generate:<epoch>:<step>): a restarted host replays recorded calls without sending them again, and the open epoch's token and tool-call spend continues from its persisted value. A call that fails, is cancelled or reaches the wall-time budget after its journal entry is written, or that a crash interrupts, stops the run as effect_indeterminate; it is never sent again. That holds when the host restarts after the epoch's wall time has run out: the call's journal entry admitted its step, so the restarted epoch reaches the entry without a budget check. The run result's stopDetail names the call and a redacted failure class (the abort reason or the error's class name, never its message). generate takes no token cap, so tokens are checked between calls: one call can overrun the epoch token budget. Runs are keyed by tenant, workspace and runRef. The runner refuses at composition a policy the epoch contract rejects and an approval_required policy without a renewal approver.

In the server, the optional boundedAgentRuns binding supplies the agent id, policy and approver; the duty stores runs in the canonical PostgreSQL agent checkpoint table of the runtime role (apply migratePostgresAgentDurableStore from @lssm-tech/integration.agent-durable-store/postgres/migrations first) and exposes the runner as duties.boundedAgentRuns. Its row is disabled until bound, and invalid for a binding that throws or a refused policy.

Connect-side effect admission

With AGENT_HOST_CONNECT_DATABASE_URL (the lssm_os_connect role), AGENT_HOST_CONNECT_SIGNING_KEY_FILE (mounted PKCS#8 Ed25519 key, never an inline value) and deployment effectProfiles, the host composes the issuing Connect authority (admitConnectEffectV1 from @lssm-tech/lib.contractspec-connect): the standing-mandate policy decides, Connect signs the Runtime V3 lifecycle, the operation and its envelope are admitted co-atomically (admitPostgresOperationAndQueue), the qualification authority records the orders and the operation is queued after verifyAdmission. Admission is idempotent per request (time-anchored replay); a different request for the same idempotency key is denied.

Standing mandates must carry ownerSignature over mandateDigest, verified against an active human key registered to the owner (createPostgresPrincipalKeyStoreV1); a delegate key never authenticates. Mandate exceptions are lifted only by a Connect operation-approval receipt (createAgentHostMandateApprovalsV1): human approver other than the delegate, single-use nonce, re-verified (not re-consumed) for the same request.

When the deployment declares routes.operationStatus: "required" (RT-009), the operation_status row becomes required and stays missing until an operationStatus authorization binding is supplied.

Readiness rows (configuration, runtime_database, authority_database, deployment, durable_queue, application_lifecycle, runtime_node, effect_providers, connect_verifier, standing_mandate, component_qualification, worker_cycle) fail closed individually; operation_status is optional and disabled until an authorization port is bound. Connect authority stores, the standing-mandate store and the CommunicationOS outbox dependencies are injected through AgentHostServerBindingsV1 by their owners; until bound they stay missing. SIGTERM/SIGINT stop claims, drain, stop HTTP and close both pools. A restart resumes from SQL: unacknowledged claims are redelivered after lease expiry and Runtime Node replays durable receipts instead of repeating effects.

Standing mandate to typed permits

lssm.agent-host.standing-mandate.v1 records the owner, delegate actor, installation scope, granted action classes (sender accounts, target prefixes, permit lifetime, optional rate window), exception rules and contract-required human-decision classes. createAgentHostStandingMandatePolicyV1 is the Connect policy: on issuance and again at dispatch it resolves the current revision into a typed expiring permit, deny, or require_review. Revocation, expiry, a changed sender/target, an exhausted window or an unresolved exception stops the action; a review is lifted only by an approval bound to the exact Connect request digest. Issuers encode actions with encodeAgentHostMandateConnectTargetV1 so sender and target are part of the signed request.

The same application can expose authenticated durable operation status at /v1/lssm-os/operations/{tenant}/{workspace}/{environment}/{operation} by injecting operationStatus. Authorization is bounded and exact-scope before the PostgreSQL/SQLite operation adapter is read; denied identities receive a non-disclosing 404. Successful responses return the canonical Runtime Node REST projection unchanged, including HTTP 202 for every nonterminal state and the exact request, receipt, and projection digests. Responses are private and no-store; malformed, substituted, timed-out, or unavailable dependencies fail closed without returning bearer material.

Application shells that need only this boundary may import @lssm-tech/app.agent-host/operation-status without loading queue, provider, or state-adapter compositions. The integrated F3 proof drives that REST handler through the canonical SDK, CLI, MCP, and React UI projections and requires one identical projection digest on every surface.

The PostgreSQL application-installation lifecycle is tenant/workspace/ environment/product scoped and revision-CAS guarded. Apply AGENT_HOST_POSTGRES_LIFECYCLE_MIGRATION_V1 through an owner connection, provision the initial disabled installation through the owner-only helper, and give the runtime only SELECT plus the guarded transition function. Raw runtime INSERT/UPDATE/DELETE stays revoked. The state machine and its validators are owned by @lssm-tech/lib.agent-protocol-spec/protocol/application-lifecycle, and the adapter and migration by @lssm-tech/integration.lssm-os-state-postgres/agent-application-lifecycle (and -migration); the host root re-exports them under the existing names.

Release Steward uses one frozen application profile through T1, T2, and T3. T2 requires a separately qualified distributed-cache binding and T3 a separately qualified event-stream binding; both retain the same SQL durable queue and Runtime Node authority components. Its first channels are web and in-app, its default is single-agent, and merge/release authority is hard-disabled until branch protection is independently qualified.

createAgentHostWakeAcceleratedQueueV1 is the app-local T2/T3 composition seam. It retains PostgreSQL as the complete Durable Queue V2 and claimed-envelope authority while routing admission, claim, acknowledgement, and reconciliation through a qualified event-stream wake accelerator. Capability, renewal, redrive, health, and envelope reads remain directly SQL-backed. A T2 host must also inject an actual distributed-cache port matching its qualified component; a component label alone is rejected. The Release Steward T2 walking skeleton uses the real Redis integration with an independently qualified cache and Streams binding, then makes Redis unavailable during claim and acknowledgement. SQL still completes and acknowledges exactly one effect, and a stale wake hint cannot create a second effect after Redis recovers. This is credential-free fallback evidence, not live Redis/Valkey failover or performance qualification.

T3 additionally requires an injected event-stream port whose exact component, capability, adapter, server, client, topology, and generation bindings match the qualified topology. The Release Steward T3 walking skeleton uses the real SQS wake integration over the same PostgreSQL queue. It admits co-atomically in SQL, publishes one opaque SQS hint, makes SQS unavailable during claim and acknowledgement, and still completes exactly one authorized effect through SQL. After SQS recovers, the stale broker hint observes an empty SQL queue and cannot repeat the effect. This is credential-free fallback evidence; AWS/Scaleway live failover, visibility-expiry, scale, cost, and performance qualification remain blocked.

The same Release Steward T3 path is qualified with the real RabbitMQ wake adapter and an independently bound quorum-queue capability profile. Publisher confirms only accelerate a co-atomically admitted SQL operation; broker loss during claim and acknowledgement falls back to SQL, and the recovered stale delivery cannot repeat the durable Runtime Node effect. This remains a credential-free simulation. Live RabbitMQ quorum failover, publisher-confirm ambiguity, consumer death, prefetch/backpressure, DLQ redrive, scale, cost, and performance qualification remain blocked.

GCP Pub/Sub and Cloud Tasks use the same Release Steward T3 proof with separate, exactly qualified transport profiles. Both publish only after durable SQL operation and outbox admission. Transport failure during claim and acknowledgement cannot prevent SQL completion or repeat the provider effect; after recovery, a stale Pub/Sub delivery or Cloud Tasks callback remains a non-authoritative hint and observes an empty SQL queue. This is credential-free simulation evidence only. Live GCP redelivery, acknowledgement deadline, callback authentication, regional failover, scaling, cost, and performance qualification remain blocked.

MQTT remains an ingress/fan-out protocol rather than an Agent Host work queue. The CommunicationOS credential-free walking skeleton authenticates and normalizes one MQTT 5 publication, derives a source-bound outbox identity, and admits it into the real PostgreSQL Durable Queue V2 before Agent Host can claim it. The existing CommunicationOS Runtime Node path then produces one governed audit, one reply event, one durable effect, and one queue acknowledgement; duplicate MQTT publication before or after completion replays the SQL admission and cannot repeat the effect. This is simulated product evidence only. Live broker ACL, mTLS/token, QoS/session reconnect, retained-message, shared- subscription, broker-failover, scale, cost, and performance evidence remains blocked.

qualifyReleaseStewardApplicationV1 is the host-owned proof boundary for the first vertical. It requires an active durable installation and runs the real filesystem-authored Release Steward application through bounded injected execution. The v0 gate records 100 production-shaped, credential-free runs, including approval, exactly-once replay, checkpoint/resume, dead-letter, and local-harness evidence. The report remains candidate, keeps merge and release authority disabled, and explicitly requires separate live qualification.

Release Steward now opts into Protocol V1 compilation. A signer is an injected port and never exposes its private key to Agentpacks or Agent Host. Agent Host verifies the canonical application signature with an Ed25519 first-party trust root, binds its publisher/key/policy and artifact digests, then advances the durable installation through install_disabled -> configured -> qualified -> active with revision CAS. Replayed activation is idempotent only for the exact configuration and qualification. The credential-free keypair used by tests is ephemeral and is not production trust evidence.

./t1 provides the PostgreSQL infrastructure factory. It creates the real Durable Queue V2, topology-state, and V3 operation adapters and only reports verified after their owner-provisioned queue and topology profiles match the exact active binding. It does not provision profiles, mint authority, or bridge the legacy V2 worker. The T1 Runtime Node bridge reloads the exact claimed envelope, durable operation, and signed standard or cleanup V3 order; keeps the queue fence distinct from the Runtime Node authority fence; and delegates at most one effect to an injected V3 execution service. It creates a queue acknowledgement only after rereading the exact terminal operation receipt. Terminal retries replay that receipt without repeating the effect, while missing, substituted, timed-out, or indeterminate results stay unacked. Production activation still requires static composition of the concrete V3 execution service and a durable application lifecycle adapter.

createAgentHostCommunicationOsT1RuntimeV1 is the production composition seam for CommunicationOS provider execution. It accepts a qualified provider binding plus injected durable payload, delivery, and execution-custody ports, then returns only the governed Runtime Node port. The concrete provider is not exposed, so a worker or product cannot call it as ambient send authority.

admitAgentHostContextV1 is the fail-closed AI context boundary. It accepts only the exact qualified context_compiler binding for the active topology, returns a typed block reason when required context is unavailable, and keeps retrieved or channel content non-instructional even when it contains prompt-like text. The baseline effect worker remains backward compatible and cannot use context admission to expand Runtime Node authority.

admitAgentHostProtocolRunV1 composes that exact context boundary with the durable AgentProtocolRuntimeV1. Admission requires qualified, topology-matched context_compiler, protocol_runtime, agent_durable_store, and baseline Agent Host bindings. It also re-materializes the exact signed first-party application through an injected qualification authority on every admission and resume. The manifest, permission summary, policy bindings, installation revision, lifecycle digests, release SHA, application/prompt/model/tool/policy/ context/evaluator versions, and sandbox digest must all match before context is compiled or durable state is returned. Revoked, paused, stale, unsigned, non-first-party, substituted, or tool-widened applications fail closed. Admission also stores an immutable run-scoped application binding, preventing a same-version requalification or policy change from silently altering a resumed run. It independently validates and persists the exact model routing V2 capability profile, invocation profile, route, qualification, evaluation decision, selection, and optional canary artifacts before context compilation, after an exact Connect route decision and connection verification. The selection must use the installed application's model policy; live_verified routes require an exact production-canary binding. Resume (resumeAgentHostProtocolRunV1) takes the same V2 route plus authority and connection ports, re-verifies Connect authority and route expiry at resume time, never recreates missing model artifacts, and requires a replan when the persisted selection changes.

Model routing V1 admission, V1 checkpoint fallback, and the V1 resolver are retired; a V1 route supplied to admission is rejected. A run persisted under model routing V1 is upcast deterministically on resume. V1 records carry no model author, serving identity, invocation profile, evaluation decision, dataset, qualification expiry, or Connect decision, so the upcast never invents them: classifyAgentHostPersistedModelRoutingV1 verifies the persisted run state and every bound V1 profile, route, qualification, and selection (digest-bound, schema-strict, via the contracts-spec planAgentModelRoutingV2Migration plan), and upcastAgentHostModelRoutingV1ToV2 accepts only a requalified V2 route for the same run, plan, selection policy, model id/version, route version, and region. The full V2 admission (Connect authority, connection verification, expiry, budget) re-runs and persists the V2 artifacts before the run state is rebound to the V2 selection with model_routing.v1_upcast.<selection> evidence; a second resume sees a V2 run. Unknown, malformed, or tampered V1 state, a terminal, in-flight, reconciling, or fallback-active V1 run, a resume expectation that does not bind the run, and a non-corresponding route block with agent_host.model_route_upcast_rejected (model_routing.upcast_rejected:<code>, AgentHostModelRoutingUpcastError) before any V2 artifact is written; a denied or failed V2 admission blocks with agent_host.model_route_untrusted and leaves the run on V1. Re-admitting an existing V1 run blocks with model_routing.v1_resume_required:<selection>; resume performs the upcast. Checkpoint fallback (admitAgentHostModelFallbackV2) re-materializes the active signed application, verifies the admitted run binding, and permits only an equivalent eligible route. It never falls back from an indeterminate provider outcome, and exact retry returns the same durable decision without another transition. The Host-owned resolver reloads that persisted selection/fallback before every model execution, canonical-verifies the active V2 candidate, rechecks the run budget, and requires an exact Connect decision before requesting a lease. It also loads the current IntegrationConnection, hashes only an adapter-allowlisted secret-free projection, and rejects version, configuration, deployment, gateway, adapter, policy, or connection substitution. Route/profile/invocation/current qualification/evaluation/current canary artifacts and exact route cost are reconstructed directly from the Host artifact store. A changed qualification or canary head invalidates the selection binding before authority or lease resolution; callers do not provide candidate artifacts to the production resolver.

Qualification and canary lifecycle writes use artifact-head CAS and retain historical revisions. A model reselection is accepted only after the active route has a persisted evidence-backed rolled-back canary. Agent Host verifies the replacement baseline and its Connect/connection bindings before the Protocol runtime atomically activates the new plan, validation, and selection and clears stale fallback state. Admission persists the immutable compiled context manifest and idempotently resumes an exact already-admitted run instead of duplicating its plan.

respondToAgentHostProtocolHelpV1 accepts a waiting-run response only through an exact qualified organizational-policy authority port. That port must verify the responder and evidence against the pending request. Conversation text and model output are never treated as approval or authority.

The governed automation runtime materializes only an exact automation definition listed by the active signed application manifest and bound to its current qualification digest. Injected authority and scheduler ports control materialization, pause/resume/revoke/expiry, claims, and background follow-ups. State uses revision CAS; occurrence and run identities are deterministic; active claims survive lease loss as resume_required; receipt-first completion recovers after process interruption without inventing another run. An indeterminate result keeps its claim in reconciliation_required and cannot create a follow-up. Agent Host persists coordination artifacts but never sends the follow-up or performs the scheduled run's external effects.

createAgentHostV3ExecutionServiceV1 is that frozen execution composition (owned by @lssm-tech/lib.lssm-os-runtime/runtime-node/v3-execution-service as createRuntimeNodeV3ExecutionServiceV1; ./t1 re-exports it). It projects the signed V3 one-step authority into the provider lifecycle, independently persists the exact provider receipt, and completes the durable operation before the queue can acknowledge. A running retry without durable provider evidence never repeats the effect; it enters indeterminate custody. When an exact provider receipt supplies sanitized diagnostic evidence for that ambiguity, custody persists those refs alongside its deterministic recovery ref without inventing an external delivery reference. Those diagnostics support reconciliation and operator help but never authorize retry, fallback, or a terminal outcome. The provider-receipt adapter remains an injected persistence boundary so T0 and T1 state packages can preserve their own atomic transaction semantics.

The GitHub T1 walking skeleton composes the actual GitHub provider lifecycle, PostgreSQL qualification authority, V3 operation and provider-receipt stores, and Agent Host execution service. Its credential-free PGlite qualification proves one draft effect across 100 concurrent host calls plus exact restart replay. It is production-shaped candidate evidence, not live GitHub evidence; credentialed canary create, observe, compensate, teardown, and billing proofs remain required before live activation.

The Vercel T1 walking skeleton reuses that same PostgreSQL authority and Agent Host execution boundary with the actual Vercel Runtime Node provider. Its credential-free structural project command proves one effect across 100 concurrent host calls and exact terminal replay after reconstructing the host and provider composition. The Vercel qualification row remains blocked until credentialed create, observe, compensate, teardown, billing, and 24-hour observation evidence is attached.

The Railway T1 walking skeleton exercises the provider API ownership mode with an exact service-update command through the same PostgreSQL authority and Agent Host execution boundary. One of 100 concurrent calls performs the effect, and a reconstructed host/provider composition replays the terminal receipt without another mutation. Railway remains blocked until credentialed lifecycle, teardown, billing, and 24-hour observation evidence is attached.

The Supabase T1 walking skeleton routes an exact private storage-bucket command through the management-driver side of the actual Supabase Runtime Node provider. The PostgreSQL authority permits one effect across 100 concurrent Agent Host calls, and reconstructed composition replays the durable terminal receipt. Supabase remains blocked until credentialed lifecycle, teardown, billing, and 24-hour observation evidence is attached.

The Neon T1 walking skeleton binds an opaque project, branch, parent branch, role profile, and region into a branch-create command. The actual Neon Runtime Node provider performs one effect across 100 Agent Host races and replays its durable receipt after reconstruction. Neon remains blocked until credentialed branch lifecycle, teardown, billing, and 24-hour observation evidence exists.

The Resend T1 walking skeleton binds only opaque message, recipient, sender-profile, template, and encrypted-content references into the actual Resend Runtime Node provider. The PostgreSQL authority permits one send across 100 Agent Host races, and reconstructed composition replays the durable receipt without another effect. No credential or email body enters the order. Resend remains blocked until credentialed delivery, observation, billing, and 24-hour evidence is attached.

The Release Steward T1 walking skeleton additionally crosses the complete product-shaped path: co-atomic accepted operation and Durable Queue V2 admission, real Agent Host claim and V3 execution, one structural GitHub draft effect, durable provider and operation receipts, exact queue acknowledgement, then 100 consecutive post-effect acknowledgement interruptions across fresh host/runtime/provider composition. Every five failed claims follows the declared attempt ceiling into DLQ and uses a digest-bound redrive receipt before continuing. The final delivery acknowledges the original terminal operation with exactly one provider effect. This remains credential_free_simulation evidence and does not promote any provider, product, or channel row to live qualification. The paired real-PostgreSQL completion-boundary command additionally SIGKILLs 100 worker processes after terminal operation/receipt verification but before queue acknowledgement. Fresh processes reclaim every expired lease and commit 100 exact acknowledgements while the durable effect table remains exactly 100. This is local-live completion-boundary evidence; the remaining boundaries are tracked below and independent production-host audit remains blocked. The T1 outbox-boundary command separately SIGKILLs 100 workers immediately after co-atomic operation, outbox, and queue admission. A fresh worker exact- replays every request, and the final database inventory must contain exactly 100 operations, 100 outbox rows, and 100 messages with no provider effect. The authority command separately SIGKILLs 100 workers after atomic lifecycle issuance; the same public issuance call exact-replays in fresh processes without charging budget or inserting again. The dispatch command kills 100 workers after the running-operation and normal-reservation CAS; fresh workers recognize the exact durable authority tuple without redispatching. The effect-boundary command kills 100 workers after one durable simulated provider mutation but before any receipt. Fresh workers reconcile the existing effect into one terminal operation receipt without reinsertion. The receipt- boundary command kills after immutable provider receipt append and recovers that exact receipt into terminal completion. Both finish with 100 effects and zero duplicates. Cleanup then kills 100 workers after permit-bound teardown effects and recovers signed absence completion. Settlement kills 100 workers after evidence commit and exact-replays the same public settlement call. All eight local PostgreSQL crash boundaries pass; independent production-host audit remains required.

The CommunicationOS in-app T1 walking skeleton uses the same authority path without making Agent Host a channel sender. CommunicationOS owns the approved delivery command, exact context resolution, approveAndSend reconciliation, event, and audit. Its public ./agent-host adapter binds that command to a Runtime Node provider lifecycle receipt, while ./agent-host-admission creates the strict Queue V2 handoff consumed by Agent Host. The credential-free proof covers PostgreSQL admission, V3 execution, the real CommunicationOS approved-send orchestrator, governed audit persistence, one reply event, durable receipts, failed first ack, restart/redelivery, and exactly one in-app delivery. Product and channel rows remain blocked until credentialed provider and full omnichannel qualification exists.

The ContractSpec T1 walking skeleton runs the real workspace Connect service for a safe governed contract edit, persists its context, plan, and permit verdict, binds their exact digests into the accepted operation, queue envelope, outbox, signed V3 GitHub draft order, and provider evidence, then crosses the same Agent Host restart/replay boundary without a second effect. This advances the ContractSpec product journey with credential-free CLI-service evidence; The integrated operation proof now covers API, MCP, SDK, CLI, and React UI projection parity. Credentialed GitHub and live product qualification remain release blockers.

The Managed CompanyOS T1 walking skeleton composes its real deterministic workspace, fail-closed policy decisions, replay, executable proof, and evidence receipt with an actual ContractSpec Connect permit. Those exact digests bind a draft-only GitHub V3 order before co-atomic PostgreSQL admission, Agent Host execution, durable receipts, failed acknowledgement, restart, and exact replay. Managed CompanyOS remains the policy/control-plane owner; Connect and Runtime Node remain effect authority. This is credential-free simulated product evidence, not a live provider or production qualification claim.

The Pactena T1 walking skeleton binds its standalone founder-suite meeting projection to a real Connect permit. The AI projection may edit but cannot approve, publish, or dispatch; the human projection retains those actions. Their exact digest enters a draft-only V3 order, PostgreSQL admission, Agent Host execution, durable receipts, failed acknowledgement, restart, and replay. This is simulated product evidence only; complete Pactena omnichannel and live provider qualification remain blocked.

The HCircle T1 walking skeleton executes the real subject-bound personal community contract for a private, non-discoverable profile draft. A human-required decision receipt, exact idempotent replay, and real Connect permit bind the draft-only V3 order, PostgreSQL admission, Agent Host execution, failed acknowledgement, restart, and durable replay. This remains credential-free simulated evidence; HCircle live provider and complete omnichannel qualification remain blocked.

Provider adoption qualification also verifies that GitHub, Docker, Vercel, Railway, Supabase, Neon, and Resend expose and advertise the canonical ./runtime-node production boundary in workspace, published, and ContractSpec catalog metadata. Offline discoverability does not satisfy credentialed provider lifecycle or 24-hour observation gates; every provider row remains blocked until those external proofs exist.

The Docker T1 walking skeleton now binds a Docker-specific V3 work order and payload to the production Runtime Node adapter, persists authority and receipts in the PostgreSQL state boundary, races 100 host executions, and replays after a fresh host/provider composition without a second Docker effect. The driver is a credential-free structural simulation; the Docker provider row therefore remains blocked for isolated live lifecycle and 24-hour observation evidence.

./t0 provides the embedded single-node infrastructure factory. It composes the real SQLite-backed Durable Queue V2, topology-state, and V3 operation adapters, validates the exact T0 topology and queue qualification, and proves that admitted work survives a process restart. Qualification-order reads and provider-receipt persistence remain explicit injected authority boundaries; the factory neither substitutes in-memory authority nor claims that the current SQLite state package can issue signed V3 orders. T0 activation stays closed until those durable boundaries and the application lifecycle are statically composed.

qualification:generate materializes the one-time LSSM OS v0 requirements genesis at generated/qualification/lssm-os/v0/<release-sha>/requirements.json. The inventory covers retained v3 authority, Agent Host, Release Steward, T0-T5, each mandatory database/cache/broker/replica transition and rollback path, cache, brokers, providers, products, channels, topology, scale, chaos, disaster recovery, and canary proof. Evidence must be tracked and is SHA-256 bound into the deterministic ledger. Required rows cannot be omitted or promoted to live_verified without provider-live, canary, and authority evidence. Local tests therefore never inflate the production denominator. Genesis is accepted only on the commit that introduces the generator. The repository CLI intentionally has no continuation mode until a trusted lineage verifier is statically composed. Integrations may use the public builder for continuation only by injecting independent lineage and requalification verifiers that authenticate the prior ledger as an exact ancestor artifact and retain that verifier identity in the new ledger. Any changed scope, topology, adapter/client/server version, policy requirement, authority binding, product contract, rollback rule, dependency, blocker, or evidence digest is emitted as requalification_required with freshness: invalidated. The generator reads evidence from the selected Git commit object and refuses a dirty worktree, so working-copy bytes cannot masquerade as evidence for HEAD. Invalidation is sticky across repeated generations; it cannot be cleared by presenting the invalidated ledger again. A separately governed, validated requalification transition is required before such a row may become fresh.

Memory import HTTP boundary

The application factory accepts optional memoryImports dependencies. When present and the lifecycle is active, POST /v1/agents/memory-imports accepts a bearer-authenticated JSON request and dispatches agent.memory.import.submit@1.0.0 through the supplied canonical registry. Use createMemoryImportOperationRegistry with real Runtime Node verification, restricted artifact readers and the durable submission adapters. The authenticator must return server-owned identity and permissions; body fields never establish the actor. Disabled/unconfigured hosts return 503.

Bodies are capped at 64 KiB; authentication, body reading and execution are bounded. Responses are private/no-store and expose only submission status, proposal digest and operation reference. A timed-out dispatch is indeterminate, not failed or successful. This boundary does not mint work orders or promote memory. Production authentication/authority configuration and console route wiring remain required.

Memory import transports can use createAgentMemoryImportAuthenticator with a trusted deployment origin serving AuthOS and CompanyOS authority. It verifies the bearer session, explicit current fleet-review permission, tenant binding, active organization/workspace, response freshness and authority revisions, then rechecks the session. The HTTP handler refreshes authority after reading input; workspace changes or revoked permission stop dispatch. No role-derived grant or deployment permission is produced. Production still requires configured runtime authority and durable ports plus live session qualification.

createAgentHostMemoryImports composes AuthOS/CompanyOS authentication, the canonical command registry and the V3 memory-import verifier. Pass its result as startAgentHostApplicationV1({ ..., memoryImports }). The composition requires explicit runtime order/payload/operation readers, Connect verification, restricted artifact readers, content/owner policy verification and an artifact store. It cannot accept a replacement command registry or a shortcut operation verifier.

The application checks fresh lifecycle state and current readiness before import authentication and dispatch. Paused, unavailable, unready or shutting-down hosts reject new imports. Shutdown does not grant authority to finish an uncertain external effect; Runtime Node reconciliation and durable state still own recovery.

The database composition proof exercises this application path with synthetic AuthOS/CompanyOS responses and an injected Connect signature-verification fixture, including permission revocation, runtime denial, pause, shutdown and database reopen/replay. Production ports, credentials and live qualification remain required.

Internal supervised provider processes

createSupervisedProvider can adapt a statically configured, trusted POSIX child entrypoint to the existing provider lifecycle port. Compose it in the exact provider router consumed by createAgentHostV3ExecutionServiceV1; V3 dispatch and SQL receipt persistence remain authoritative. The child receives one bounded execution JSON document on stdin and must emit one canonical receipt on stdout. An independent receipt verifier must accept that receipt before it can return. The executable and working directory must be absolute, environment is explicit with production mode, and no shell or ambient credentials are inherited.

Timeout, cancellation, excessive output, nonzero exit, or an unconfirmed process group exit yields an error for the existing V3 indeterminate-custody path. A partial stdout receipt never establishes success. Local tests exercise real child processes plus synthetic provider receipts; they do not qualify live Builder inference, a production child entrypoint, or host-crash recovery. Windows needs a qualified Job Object/container implementation and is currently rejected. This is supervision of trusted host code, not containment for hostile code, escaped process groups, or arbitrary external effects. The adapter is internal and is not activated by the default host binary.

Static Builder child composition

The canonical @lssm-tech/app.agent-host/t1 surface exports createAgentHostBuilderChild, serveSupervisedProviderChild and createSupervisedProvider. The child factory composes the real Git patch adapter with the governed Builder patch service and existing Runtime Node provider. Deployment configuration must supply exact provider binding, repository/checkout/ artifact roots, qualified generation providers, Connect packet authority, QA, clock, approved payload reader, active-claim coordinator and durable receipt writer/verifier. None has a permissive default. The app does not accept this configuration from a submitted intent or choose a model from ambient login state.

A deployment-owned entrypoint statically imports its configuration and calls await serveSupervisedProviderChild(createAgentHostBuilderChild(configuration)). The supervising host configures that exact executable and entrypoint, routes it through V3 authority, and independently verifies its returned receipt. There is no dynamic plugin/configuration-module path in the submitted JSON protocol.

The composition integration test produces a real Git candidate, verifies retained artifacts and exact receipt replay. Authority signatures, claim coordination, model output and receipt persistence in this test are fixtures. Provider credentials, independent QA and live deployment qualification remain activation blockers. Same-host process custody is described below. The default binary is unchanged and does not claim to generate applications yet.

After a termination request the supervisor observes closure for at most two more seconds. Unconfirmed processes retain their host handles until actual close; operator inspection through unresolvedSupervisedProcesses never authorizes a retry. Escaped descendants with inherited pipes are covered by a real subprocess test. Deadline expiry is never treated as proof that an executor stopped.

Builder V3 PostgreSQL receipts

createAgentHostBuilderPostgresChild accepts the admitted operation's exact scope/order reference and a restricted runtime PostgreSQL pool. It composes the existing issued-order reader and V3 provider receipt store, then supplies them to the Builder child. Operators no longer need a V2 receipt/claim-store adapter. createBuilderV3ReceiptWriter is the lower-level composition for qualified V3 ports. Neither function issues orders, authorizes dispatch, runs migrations or provides an active-claim coordinator.

Each read/write reloads the issued standard order and binds all execution fields to its canonical V3 execution. SQL rejects receipt writes before dispatch. A receipt returns only after exact persisted readback; replay requires the same candidate and evidence. The existing Agent Host V3 service owns terminal operation completion and skips provider execution when its durable receipt already exists.

A file-backed embedded PostgreSQL test now closes and reopens the database, creates fresh writer/host instances, and verifies receipt/terminal replay with one generation. It also rejects pre-dispatch writes, cross-workspace execution and altered replay results. Generation, signature-verification and connection-role metadata remain explicit fixtures; live PostgreSQL role isolation and production execution fencing still require qualification. No default host activation or live inference is implied.

Local/personal Builder process custody

createAgentHostBuilderLocalPostgresChild supplies the same-host coordinator as well as concrete V3 SQL receipt persistence. Configure a stable custody directory, the admitted node identity and a bounded maximum duration. Run this provider in the supervised child process with a supervisor timeout no greater than that maximum. Generation still requires configured Connect packet authority, a qualified model provider and independent QA.

The coordinator verifies the issued order and current running SQL claim before reserving an operation and again around its callback. Its filesystem reservation is keyed by tenant/workspace/environment/operation, so a new attempt cannot erase an unresolved previous executor. Only one actual process can reserve that local operation. Roots and ancestors must be owned/trusted, cannot traverse symlinks, and must remain disjoint from repository and checkout roots. Reservation and outcome markers plus their directory entries are flushed durably.

A throw, lost acknowledgement or dead owner leaves custody in place. Expiry or a missing PID never releases it. After restart the existing V3 service can replay a verified SQL receipt without dispatching the provider again; absent such evidence, operator reconciliation is required. Never delete custody to force a retry. This is local POSIX process exclusion, not distributed/cloud fencing or automatic recovery of arbitrary external effects. Windows and cross-host coordination remain unqualified.

Tests race two real processes, kill an owner after durable reservation, and reject fresh-process/expired-custody reuse. The SQL/host proof now loses acknowledgement after a real receipt append, retains unknown custody, closes/reopens the database, and completes by receipt replay with exactly one generation. Policy signatures, model output and SQL connection-role metadata in that proof remain fixtures.

Private provider failure diagnostics

Supervised process configuration accepts an optional diagnostic port. Host-owned compositions can use createPrivateProviderDiagnostics with a stable run reference and a private directory. Failed process stdout/stderr share the configured byte budget; known environment secrets and recognizable bearer/key tokens are redacted. Files are created exclusively with mode 0600 under a checked trusted directory, flushed and read back before returning an opaque diagnostic reference. Arguments, environment maps and credential files are not copied into diagnostic records.

Failure objects expose only the reason, numeric exit/signal when observed, whether stream closure was confirmed, the diagnostic reference and availability status. Raw child output stays in the private artifact. An exited parent with an unclosed inherited pipe remains explicitly unconfirmed even if its exit code was zero. Diagnostic persistence is observed for at most five seconds; unavailable or uncertain logging never converts a failed/unknown execution into success. Existing V3 custody and reconciliation remain authoritative. Diagnostic artifacts need host-authorized access and operator retention/cleanup; they are not public release evidence.

Local Builder with SQLite

createAgentHostBuilderLocalSqliteChild on ./t0 composes the existing Builder child with concrete SQLite issued-order reads, V3 provider receipt persistence, operation state and same-host custody. Configure one migrated SQLite driver, the admitted operation's exact order reference, trusted clock, protected custody location, qualified generation provider, Connect packet authority and QA.

The owner runs migrateSingleNodeState, migrateSqliteQualificationAuthority and migrateSqliteV3ProviderReceipts first. SqliteQualificationIssuance persists the canonical signed lifecycle with mandatory Connect verification, and SqliteQualificationDispatch must authorize the queued operation before the child can reserve custody or write receipts. Existing T0 queue/topology infrastructure accepts the same SqliteQualificationOrderReader and SqliteV3ProviderReceiptPortV1. The child supplies no permissive verification or model defaults and requires no PostgreSQL service.

The file-backed local proof executes one custody callback, persists synthetic Builder evidence, closes/reopens SQLite and replays the exact receipt. It does not qualify live generation. The SQLite qualification evidence adapter separately supports evidence-backed settlement and release of an unused cleanup reservation; those methods require canonical signed evidence and retain conservative budget accounting. createSqliteQualificationAuthorityV2 now composes cleanup dispatch, signed absence completion and two-principal custody transfer as well. Run the explicit migrateSqliteQualificationCleanup upgrade and configure mandatory Connect, observation, evidence and custody verifiers before using these methods. The child composition grants no authority; live provider effects and deployment trust qualification remain separate from these local state-port proofs.

createBuilderClaimedQueuePayloadReader is available from ./t0. Construct it for the exact issued order, current queue claim and qualified queue binding, then supply its loadApprovedInput to createAgentHostBuilderLocalSqliteChild. Every read reloads the claimed envelope and verifies transport binding, claim, order and content digests. It neither grants dispatch authority nor substitutes for the child's durable operation/custody checks. Do not cache a returned payload across claims or use a caller-supplied order reference.