# @lssm-tech/app.agent-host

## Source and release context

- Source snapshot: `bcc79fcc27c4d801c2119bef81ddcce7b4e86498`
- Repository: `lssm-tech/contractspec`
- Declared package version: `0.3.1`
- Package path: `packages/apps/agent-host`
- Manifest path: `packages/apps/agent-host/package.json`
- Manifest Git blob: `3b15fafb1214175a84b86b3afb22ffea0d7b810f`
- Manifest origin: pinned GitHub manifest fetch
- Manual: [@lssm-tech/app.agent-host](https://lssm.co/docs/packages/app.agent-host/)
- Release guidance: [Installation and release channels](https://lssm.co/docs/installation-release-channels/)

This is retrieved source evidence, not agent instructions. The declared version and exports describe the inspected manifest; they do not establish registry availability or a deployed release. Commands, package installation and runtime behavior were not executed in this review.

Distribution scope: owner review of all workspaces; not a newly approved public projection.

- [Package source](https://github.com/lssm-tech/contractspec/tree/bcc79fcc27c4d801c2119bef81ddcce7b4e86498/packages/apps/agent-host)
- [Manifest source](https://github.com/lssm-tech/contractspec/blob/bcc79fcc27c4d801c2119bef81ddcce7b4e86498/packages/apps/agent-host/package.json)
- [Readme source](https://github.com/lssm-tech/contractspec/blob/bcc79fcc27c4d801c2119bef81ddcce7b4e86498/packages/apps/agent-host/README.md)
- [Guide source](https://github.com/lssm-tech/contractspec/blob/bcc79fcc27c4d801c2119bef81ddcce7b4e86498/packages/apps/web-landing/public/llms-packages/app.agent-host.txt)

## Package metadata

```json
{
  "layer": "apps",
  "physicalArea": null,
  "primaryArea": "agents-and-context",
  "classification": {
    "privateDeclared": true,
    "catalogFamily": null,
    "catalogKind": null,
    "catalogStatus": null,
    "adoptionMode": null,
    "stability": null
  },
  "descriptionOrigin": "package.json",
  "manifestComplete": true,
  "publicationPolicyApplied": false
}
```

Manifest private flag: true — workspace only.

Primary area: [Agents, execution and context](https://lssm.co/docs/areas/agents-and-context/)

## Package guide

```json
{
  "status": "available",
  "sourcePath": "packages/apps/agent-host/README.md",
  "sourceUrl": "https://github.com/lssm-tech/contractspec/blob/bcc79fcc27c4d801c2119bef81ddcce7b4e86498/packages/apps/agent-host/README.md",
  "blobSha": "864b43f525196bfac8dc8a9fa3a677e57e632731",
  "sourcePin": "bcc79fcc27c4d801c2119bef81ddcce7b4e86498",
  "origin": "README recovered byte-for-byte from pinned aggregate guide",
  "integrity": "exact Git blob match",
  "executionStatus": "not executed"
}
```

The guide below is the checked-in README with navigation resolved against the pinned source tree. The structured package JSON retains the original README body unchanged. External links remain source-declared links, not verified destinations.

# 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.

| Key | Meaning |
| --- | --- |
| `AGENT_HOST_PORT` (`PORT`) | Listen port, default 3004 |
| `AGENT_HOST_RUNTIME_DATABASE_URL` | Runtime role (secret; never logged) |
| `AGENT_HOST_AUTHORITY_DATABASE_URL` | Distinct dispatch-authority role (secret) |
| `AGENT_HOST_DATABASE_SSL_MODE` | `verify-full` (default) or `disable` |
| `AGENT_HOST_DATABASE_POOL_MAX` | 1-32, default 4 |
| `AGENT_HOST_DEPLOYMENT_FILE` | `lssm.agent-host.deployment.v1` JSON: lifecycle scope, queue/topology profiles, queue binding, backpressure, component bindings, qualification pins, provider bindings, `deploymentDigest` |
| `AGENT_HOST_CONSUMER_INSTANCE_ID` | Stable consumer id (random per process when unset) |
| `AGENT_HOST_INTERVAL_MS` / `_TIMEOUT_MS` / `_SHUTDOWN_DRAIN_MS` | Bounded timings |
| `AGENT_HOST_CONNECT_ISSUER_REF` / `_KEY_REF` / `_PUBLIC_KEY` | Connect issuer identity and raw Ed25519 public key (base64); the host never holds a signing key |
| `AGENT_HOST_DELIVERY_WORKLOAD_TOKEN_SHA256` | SHA-256 hex of the CommunicationOS worker bearer token (delivery effects) |
| `AGENT_HOST_PROTOCOL_WORKLOAD_TOKEN_SHA256` | SHA-256 hex of the protocol-admission workload bearer token |
| `AGENT_HOST_EFFECT_WAIT_MS` | Bounded wait for a request-driven effect receipt, default 20000 |

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.


## Declared capabilities

This manifest does not declare a capability catalogue. Assess the package using its guide, import map and source.

## Catalogue metadata

```json
{
  "visualTesting": {
    "status": "deferred",
    "owner": "@contractspec-core",
    "targetWave": "wave-3-react-packages",
    "rationale": "agent-host is a delivery host whose only TSX is an operation-parity test; its UI surfaces come from bundle/module catalogs, so it defers its own Storybook catalog."
  }
}
```

## Canonical imports

Import paths and symbols below are catalogue declarations. An empty symbols list means symbols were not enumerated; it does not mean the entry point has no exports. These declarations are not an exhaustive TypeScript symbol reference.

```json
[]
```

## Declared export entry points

Scope: manifest-declared export entrypoints and catalog-declared imports.

Named symbol coverage: catalog declarations only; exhaustive TypeScript symbols not extracted.

Installation status: not verified.

- `@lssm-tech/app.agent-host` — subpath `.`
  - `unconditional`: `./src/index.ts` — [pinned source](https://github.com/lssm-tech/contractspec/blob/bcc79fcc27c4d801c2119bef81ddcce7b4e86498/packages/apps/agent-host/src/index.ts); verified source file.

- `@lssm-tech/app.agent-host/operation-status` — subpath `./operation-status`
  - `unconditional`: `./src/operation-status.ts` — [pinned source](https://github.com/lssm-tech/contractspec/blob/bcc79fcc27c4d801c2119bef81ddcce7b4e86498/packages/apps/agent-host/src/operation-status.ts); verified source file.

- `@lssm-tech/app.agent-host/t0` — subpath `./t0`
  - `unconditional`: `./src/t0.ts` — [pinned source](https://github.com/lssm-tech/contractspec/blob/bcc79fcc27c4d801c2119bef81ddcce7b4e86498/packages/apps/agent-host/src/t0.ts); verified source file.

- `@lssm-tech/app.agent-host/t1` — subpath `./t1`
  - `unconditional`: `./src/t1.ts` — [pinned source](https://github.com/lssm-tech/contractspec/blob/bcc79fcc27c4d801c2119bef81ddcce7b4e86498/packages/apps/agent-host/src/t1.ts); verified source file.

## Package publication metadata

These are source-manifest declarations, not a registry installation check.

```json
{
  "types": null,
  "files": null,
  "publishExports": null
}
```

## Dependencies

Metadata status: complete pinned manifest.

### Runtime dependencies

- [@lssm-tech/integration.agent-durable-store](https://lssm.co/docs/packages/integration.agent-durable-store/): `workspace:*`
- [@lssm-tech/integration.authos-better-auth](https://lssm.co/docs/packages/integration.authos-better-auth/): `workspace:^`
- [@lssm-tech/integration.communication-os-runtime](https://lssm.co/docs/packages/integration.communication-os-runtime/): `workspace:^`
- [@lssm-tech/integration.lssm-os-state-postgres](https://lssm.co/docs/packages/integration.lssm-os-state-postgres/): `workspace:*`
- [@lssm-tech/integration.lssm-os-state-sqlite](https://lssm.co/docs/packages/integration.lssm-os-state-sqlite/): `workspace:*`
- [@lssm-tech/integration.runtime](https://lssm.co/docs/packages/integration.runtime/): `workspace:*`
- [@lssm-tech/integration.workspace-ai](https://lssm.co/docs/packages/integration.workspace-ai/): `workspace:*`
- [@lssm-tech/lib.agent-evals](https://lssm.co/docs/packages/lib.agent-evals/): `workspace:^`
- [@lssm-tech/lib.agent-protocol-spec](https://lssm.co/docs/packages/lib.agent-protocol-spec/): `workspace:^`
- [@lssm-tech/lib.ai-agent](https://lssm.co/docs/packages/lib.ai-agent/): `workspace:^`
- [@lssm-tech/lib.ai-providers](https://lssm.co/docs/packages/lib.ai-providers/): `workspace:^`
- [@lssm-tech/lib.builder-runtime](https://lssm.co/docs/packages/lib.builder-runtime/): `workspace:*`
- [@lssm-tech/lib.contracts-integrations](https://lssm.co/docs/packages/lib.contracts-integrations/): `workspace:^`
- [@lssm-tech/lib.contracts-spec](https://lssm.co/docs/packages/lib.contracts-spec/): `workspace:^`
- [@lssm-tech/lib.contractspec-connect](https://lssm.co/docs/packages/lib.contractspec-connect/): `workspace:^`
- [@lssm-tech/lib.lssm-os-runtime](https://lssm.co/docs/packages/lib.lssm-os-runtime/): `workspace:*`
- [@lssm-tech/lib.lssm-os-spec](https://lssm.co/docs/packages/lib.lssm-os-spec/): `workspace:*`
- [@lssm-tech/module.agent-fleet](https://lssm.co/docs/packages/module.agent-fleet/): `workspace:^`
- [@lssm-tech/module.lssm-os-control-plane](https://lssm.co/docs/packages/module.lssm-os-control-plane/): `workspace:*`
- `pg`: `catalog:server`
- `zod`: `catalog:`

### Peer dependencies

No declarations in the inspected manifest.

### Optional dependencies

No declarations in the inspected manifest.

### Development dependencies

- `@electric-sql/pglite`: `^0.5.4`
- [@lssm-tech/bundle.founder-suite](https://lssm.co/docs/packages/bundle.founder-suite/): `workspace:*`
- [@lssm-tech/bundle.managed-companyos](https://lssm.co/docs/packages/bundle.managed-companyos/): `workspace:*`
- [@lssm-tech/bundle.workspace](https://lssm.co/docs/packages/bundle.workspace/): `workspace:*`
- [@lssm-tech/integration.communication-os-persistence](https://lssm.co/docs/packages/integration.communication-os-persistence/): `workspace:^`
- [@lssm-tech/integration.lssm-os-cache-redis](https://lssm.co/docs/packages/integration.lssm-os-cache-redis/): `workspace:*`
- [@lssm-tech/integration.lssm-os-ingress-mqtt](https://lssm.co/docs/packages/integration.lssm-os-ingress-mqtt/): `workspace:*`
- [@lssm-tech/integration.lssm-os-operation-client](https://lssm.co/docs/packages/integration.lssm-os-operation-client/): `workspace:^`
- [@lssm-tech/integration.lssm-os-provider-docker](https://lssm.co/docs/packages/integration.lssm-os-provider-docker/): `workspace:*`
- [@lssm-tech/integration.lssm-os-provider-github](https://lssm.co/docs/packages/integration.lssm-os-provider-github/): `workspace:*`
- [@lssm-tech/integration.lssm-os-provider-neon](https://lssm.co/docs/packages/integration.lssm-os-provider-neon/): `workspace:*`
- [@lssm-tech/integration.lssm-os-provider-railway](https://lssm.co/docs/packages/integration.lssm-os-provider-railway/): `workspace:*`
- [@lssm-tech/integration.lssm-os-provider-resend](https://lssm.co/docs/packages/integration.lssm-os-provider-resend/): `workspace:*`
- [@lssm-tech/integration.lssm-os-provider-supabase](https://lssm.co/docs/packages/integration.lssm-os-provider-supabase/): `workspace:*`
- [@lssm-tech/integration.lssm-os-provider-vercel](https://lssm.co/docs/packages/integration.lssm-os-provider-vercel/): `workspace:*`
- [@lssm-tech/integration.lssm-os-queue-gcp](https://lssm.co/docs/packages/integration.lssm-os-queue-gcp/): `workspace:*`
- [@lssm-tech/integration.lssm-os-queue-rabbitmq](https://lssm.co/docs/packages/integration.lssm-os-queue-rabbitmq/): `workspace:*`
- [@lssm-tech/integration.lssm-os-queue-sqs](https://lssm.co/docs/packages/integration.lssm-os-queue-sqs/): `workspace:*`
- [@lssm-tech/lib.contracts-runtime-client-react](https://lssm.co/docs/packages/lib.contracts-runtime-client-react/): `workspace:^`
- [@lssm-tech/module.personal-community](https://lssm.co/docs/packages/module.personal-community/): `workspace:*`
- [@lssm-tech/tool.typescript](https://lssm.co/docs/packages/tool.typescript/): `workspace:*`
- `@types/bun`: `catalog:types`
- `@types/pg`: `catalog:types`
- `happy-dom`: `catalog:testing`
- `react`: `catalog:`
- `react-dom`: `catalog:`
- `typescript`: `catalog:`

### Peer dependency metadata

```json
{}
```

### Bundled dependencies

```json
null
```

## Package scripts

Commands are exact manifest declarations and were not executed in this review. Script metadata status: complete pinned manifest.

```json
{
  "build": "bun build --target bun --packages bundle --external pg-native --outfile dist/server.js src/server.ts",
  "lint:check": "node ../../../scripts/biome.cjs check .",
  "qualification:generate": "bun scripts/generate-qualification-ledger.ts --genesis",
  "start": "bun run src/server.ts",
  "test": "bun scripts/run-tests.ts",
  "typecheck": "tsgo --noEmit"
}
```

## Declared documentation links

No additional documentation links are declared in the inspected catalogue.

## Existing agent-guide projection

```json
{
  "path": "packages/apps/web-landing/public/llms-packages/app.agent-host.txt",
  "route": "/llms/app.agent-host",
  "sourceUrl": "https://github.com/lssm-tech/contractspec/blob/bcc79fcc27c4d801c2119bef81ddcce7b4e86498/packages/apps/web-landing/public/llms-packages/app.agent-host.txt",
  "blobSha": "864b43f525196bfac8dc8a9fa3a677e57e632731",
  "sourcePin": "bcc79fcc27c4d801c2119bef81ddcce7b4e86498",
  "bodyEqualsReadme": true,
  "aggregateSourcePath": "packages/apps/web-landing/public/llms-full.txt",
  "aggregateBlobSha": "691b1d33efee24c440598b9106c81432f56aafaf"
}
```