{
  "schemaVersion": "1.0",
  "title": "Run the connector fleet quickstart",
  "description": "In this tutorial, you will start the repository's deterministic connector-fleet topology and route one signed AIP action from aipctl, through a product-neutral aipd gateway, to a standalone Cal.diy connector host. The provider is a controll",
  "canonical": "https://getaip.org/docs/getting-started/connector-fleet-quickstart",
  "route": "/docs/getting-started/connector-fleet-quickstart",
  "source": "docs/getting-started/connector-fleet-quickstart.md",
  "protocol": "Agent Interoperability Protocol",
  "protocolVersion": "1.0",
  "section": "Start Here",
  "documentType": "Getting started",
  "language": "en",
  "downloads": {
    "md": "/docs/download/getting-started/connector-fleet-quickstart.md",
    "txt": "/docs/download/getting-started/connector-fleet-quickstart.txt",
    "json": "/docs/download/getting-started/connector-fleet-quickstart.json",
    "pdf": "/docs/download/getting-started/connector-fleet-quickstart.pdf"
  },
  "content": {
    "format": "text/markdown",
    "markdown": "---\ntitle: Run the connector fleet quickstart\ndescription: Route one signed AIP action through the deterministic connector fleet\nkind: tutorial\naudience: developer\nappliesTo: \"1.x\"\nwritingStandard: \"aip-docs/1.0\"\nlastReviewedRevision: \"97be86e9efedf07ecf1783b03800f683f107fb04\"\n---\n\n# Run the connector fleet quickstart\n\nIn this tutorial, you will start the repository's deterministic connector-fleet\ntopology and route one signed AIP action from `aipctl`, through a\nproduct-neutral `aipd` gateway, to a standalone Cal.diy connector host. The\nprovider is a controlled local fixture, so the exercise needs no external Cal\naccount or product credential.\n\nThis is a learning path for the fleet process boundary. It is not a production\ndeployment or a qualification run. The reviewed source is commit\n`97be86e9efedf07ecf1783b03800f683f107fb04`.\n\n## What you will observe\n\nBy the end of the tutorial, you will have observed:\n\n- source-derived container image and connector release identities;\n- registry admission before a connector host starts;\n- two product-neutral gateway replicas and one lifecycle control plane;\n- one healthy Cal.diy connector replica for `tenant-acme`;\n- a signed call to `cap:cal_diy:profile.get` with status `completed`;\n- durable action lookup through either gateway replica;\n- bounded removal of only the named tutorial stack and its volumes.\n\nThe reference Compose file also defines deterministic hosts for Hermes Agent,\nChatwoot, Dify, and CrewAI. This tutorial builds those images but starts only\nthe Cal.diy product path. Twenty is one of the six maintained connectors, but\nit has no service in this deterministic fixture and follows its own deployment\nand qualification path.\n\n## Prerequisites\n\nYou need:\n\n- a clean checkout at the reviewed source revision;\n- Docker Engine with Docker Compose v2 and BuildKit;\n- enough local CPU, memory, and disk for a source-based multi-image build;\n- TCP port `18443` free on the loopback interface;\n- a POSIX-compatible shell and `lsof` for the port preflight.\n\nRun every command from the `aip-core` repository root. The first preparation\ncan take substantially longer than the native quickstart because it builds the\ngateway, control plane, fixtures, and five product-host images.\n\nThe Compose project has the fixed name `aip-connector-fleet-qualification`.\nDo not use this tutorial while another run is using that project or while its\nvolumes contain evidence you need to retain.\n\n## 1. Verify the source and Docker boundary\n\nConfirm the exact source revision, a clean worktree, and an available Docker\ndaemon:\n\n```sh\nexport AIP_SOURCE_REVISION=97be86e9efedf07ecf1783b03800f683f107fb04\n\ntest \"$(git rev-parse HEAD)\" = \"$AIP_SOURCE_REVISION\"\ntest -z \"$(git status --porcelain)\"\ndocker info >/dev/null\ndocker compose version\n```\n\nAll four checks must exit with status `0`. If the worktree is not clean, use a\nseparate clean checkout instead of hiding changes: the preparation script\nderives image and release identities from the complete workspace content.\n\nCheck that the fixed host port is unused:\n\n```sh\nif ! command -v lsof >/dev/null; then\n  echo \"lsof is required for the port preflight\" >&2\n  exit 1\nfi\nif lsof -nP -iTCP:18443 -sTCP:LISTEN | grep -q .; then\n  echo \"Port 18443 is already in use\" >&2\n  exit 1\nfi\n```\n\nExpected result: the command prints nothing and exits with status `0`.\n\n## 2. Prepare source-derived images\n\nBuild the exact images and write their immutable image IDs to the generated\nCompose environment:\n\n```sh\n./deploy/connector-fleet/prepare.sh\ntest -s deploy/connector-fleet/.env.qualification\n```\n\nExpected result: the script ends with a line beginning\n`connector fleet preparation: PASS`. The generated file contains source,\nimage, and release metadata for this workspace. At the reviewed revision it\ndoes not contain product credentials.\n\nDefine a short shell helper for the remaining commands:\n\n```sh\ncompose() {\n  docker compose \\\n    --profile products \\\n    --env-file deploy/connector-fleet/.env.qualification \\\n    -f deploy/connector-fleet/compose.yml \\\n    \"$@\"\n}\n```\n\nInspect the fixed Compose project before changing it:\n\n```sh\ncompose ps --all\n```\n\nIf this lists containers from another investigation or qualification run, stop\nhere and preserve that run first. This tutorial deliberately does not rename\nthe project because the source-owned volume and evidence tooling use its fixed\nidentity.\n\n## 3. Start one product path\n\nStart the Cal.diy host and its declared dependencies, and wait for running\nservices to become healthy:\n\n```sh\ncompose up --detach --wait --wait-timeout 300 cal-acme-a\n```\n\nExpected result: the command exits with status `0`. Compose runs short-lived\ninitializers and admission jobs before it reports the long-running services as\nhealthy. The dependency graph starts:\n\n- PostgreSQL and registry initialization;\n- deterministic identity, policy, secret, and product fixtures;\n- the connector lifecycle control plane;\n- the TLS edge;\n- `aipd` and `aipd-b` against shared durable state;\n- the controlled product upstream;\n- `cal-acme-a` as a standalone connector host.\n\nThe setup graph also creates qualification-only admission artifacts. They are\ninternal test infrastructure, not additional public product connectors, and\ntheir host services are not part of this tutorial outcome.\n\nInspect both completed setup jobs and running services:\n\n```sh\ncompose ps --all\n```\n\n`cal-acme-a`, `aipd`, `aipd-b`, `control-plane`, `edge`, `postgres`, and\n`product-upstream` should be running and healthy. Initialization and admission\nservices may be exited with status `0` because they are one-shot jobs.\n\n## 4. Route one signed read\n\nRun `aipctl` inside the isolated fleet network. The command mounts the\nsource-generated client key, gateway DID, and local TLS authority from the\nCompose volumes:\n\n```sh\ncompose run --rm --no-deps \\\n  --entrypoint /usr/local/bin/aipctl \\\n  -e AIPCTL_NATIVE_PRINCIPAL_ID=service:aipctl:qualification-acme \\\n  -e AIPCTL_NATIVE_TRUST_DOMAIN=fleet.test \\\n  -e AIPCTL_NATIVE_SIGNING_SEED_FILE=/fleet-state/secrets/client-acme-signing-seed.hex \\\n  -e AIPCTL_NATIVE_PEER_DID_FILE=/fleet-state/public/gateway.did \\\n  -e AIPCTL_NATIVE_TLS_CA_FILE=/caddy-data/caddy/pki/authorities/local/root.crt \\\n  qualification action call \\\n  https://aipd.fleet.test:8443 \\\n  cap:cal_diy:profile.get \\\n  --action-id act_connector_fleet_quickstart_001 \\\n  --input '{}'\n```\n\nExpected result: the response is an AIP action result whose `action_id` is\n`act_connector_fleet_quickstart_001` and whose status is `completed`. The\noutput contains the deterministic Cal.diy profile returned by the controlled\nupstream.\n\nThis completion demonstrates the configured local path: signed client request,\ngateway authentication, tenant-scoped capability routing, connector-host\nexecution, and a product-shaped fixture response. It does not demonstrate\nbehavior against a live Cal.diy deployment.\n\n## 5. Read the action through the second gateway\n\nQuery the shared durable action state through `aipd-b` without replaying the\nprovider operation:\n\n```sh\ncompose run --rm --no-deps \\\n  --entrypoint /usr/local/bin/aipctl \\\n  -e AIPCTL_NATIVE_PRINCIPAL_ID=service:aipctl:qualification-acme \\\n  -e AIPCTL_NATIVE_TRUST_DOMAIN=fleet.test \\\n  -e AIPCTL_NATIVE_SIGNING_SEED_FILE=/fleet-state/secrets/client-acme-signing-seed.hex \\\n  -e AIPCTL_NATIVE_PEER_DID_FILE=/fleet-state/public/gateway.did \\\n  -e AIPCTL_NATIVE_TLS_CA_FILE=/caddy-data/caddy/pki/authorities/local/root.crt \\\n  -e AIPCTL_NATIVE_BEARER_TOKEN_FILE=/fleet-state/secrets/native-bearer-token \\\n  qualification action status \\\n  https://aipd-b.fleet.test:8443 \\\n  act_connector_fleet_quickstart_001 \\\n  --include-result \\\n  --include-receipts\n```\n\nExpected result: the lifecycle view identifies the same action and capability,\nreports a terminal state with `result_status` set to `completed`, and includes\nthe stored result. A successful lookup shows that the two gateway replicas use\nthe same durable runtime state; it is not a failover or recovery test.\n\n## 6. Verify the tutorial outcome\n\nRepeat a non-mutating status lookup and require both the connector host and\ngateways to remain healthy:\n\n```sh\ntest \"$(compose ps --status running --services | grep -cx 'cal-acme-a')\" -eq 1\ntest \"$(compose ps --status running --services | grep -Ec '^aipd(-b)?$')\" -eq 2\n\ncompose run --rm --no-deps \\\n  --entrypoint /usr/local/bin/aipctl \\\n  -e AIPCTL_NATIVE_PRINCIPAL_ID=service:aipctl:qualification-acme \\\n  -e AIPCTL_NATIVE_TRUST_DOMAIN=fleet.test \\\n  -e AIPCTL_NATIVE_SIGNING_SEED_FILE=/fleet-state/secrets/client-acme-signing-seed.hex \\\n  -e AIPCTL_NATIVE_PEER_DID_FILE=/fleet-state/public/gateway.did \\\n  -e AIPCTL_NATIVE_TLS_CA_FILE=/caddy-data/caddy/pki/authorities/local/root.crt \\\n  -e AIPCTL_NATIVE_BEARER_TOKEN_FILE=/fleet-state/secrets/native-bearer-token \\\n  qualification action status \\\n  https://aipd.fleet.test:8443 \\\n  act_connector_fleet_quickstart_001 \\\n  --include-result >/dev/null\n```\n\nAll three commands must exit with status `0`. You have now observed admission,\nregistration, signed routing, standalone execution, and shared durable lookup\nfor one low-risk product capability.\n\n## Stop and clean up\n\nBefore deletion, capture diagnostics if any step failed:\n\n```sh\ncompose ps --all\ncompose logs --no-color --tail 200 aipd aipd-b control-plane cal-acme-a\n```\n\nWhen no retained state from this named project is needed, remove its containers,\nnetwork, and volumes:\n\n```sh\ncompose down --volumes --remove-orphans --timeout 30\ntest -z \"$(compose ps --all --quiet)\"\n```\n\nThe first command deletes the project volumes, including PostgreSQL state,\ngenerated keys, and any qualification evidence stored there. It does not prune\nunrelated containers, images, build cache, or volumes. Keep the images if you\nintend to repeat the tutorial; remove them only through a separately reviewed\ncleanup decision.\n\n## Resolve common failures\n\n| Symptom | Decision |\n|---|---|\n| Preparation reports that Docker is unavailable | Start or repair the Docker daemon, then rerun the same source check before preparation |\n| Port `18443` is already in use | Identify the owning process or existing fleet run; do not stop or delete it without confirming ownership |\n| An image build fails | Preserve the build output, confirm disk and tool availability, and rerun `prepare.sh` from the same clean revision |\n| A one-shot admission job exits nonzero | Inspect `compose ps --all` and that job's logs; do not bypass admission or start the host manually |\n| A service does not become healthy | Inspect the named service, its dependency state, and bounded logs before cleanup |\n| The signed action is rejected | Confirm that the command uses the generated principal, key, peer DID, CA, and `tenant-acme` fixture unchanged |\n| The action completes but the second lookup fails | Preserve gateway and PostgreSQL logs; this tutorial does not authorize recreating shared state as a repair |\n\n## What happened internally\n\nThe fixture generated trust material and immutable admission packages, migrated\nthe connector registry, and admitted the Cal.diy connector version before its\nhost process started. The host then registered a tenant-scoped replica and\nrenewed its lease with the lifecycle control plane.\n\nThe signed `aipctl` request reached the product-neutral gateway. The gateway\nselected an eligible Cal.diy replica from the registry and sent the action to\nthe standalone host. That host resolved its fixture credential, called the\ncontrolled upstream, and returned a typed result. Both gateways used the same\nPostgreSQL-backed runtime state, so the second gateway could read the completed\naction without repeating the product call.\n\nThe repository's full product-fleet qualification exercises all five fixture\nhosts, governed mutations, tenant isolation, durable replay, outages, restarts,\nand failover. Those checks belong to the qualification documentation and are\nintentionally outside this quickstart.\n\n## Next steps\n\n- [Understand connector-fleet architecture](../architecture/connector-fleet.md)\n- [Adopt the Cal.diy connector](../connectors/cal-diy.md)\n- [Deploy a connector fleet](../guides/deploy-connector-fleet.md)\n- [Run connector-fleet qualification](../testing/connector-fleet-qualification.md)\n- [Follow the separate Twenty path](../connectors/twenty.md)\n",
    "text": "Run the connector fleet quickstart\n\nIn this tutorial, you will start the repository's deterministic connector-fleet\ntopology and route one signed AIP action from aipctl, through a\nproduct-neutral aipd gateway, to a standalone Cal.diy connector host. The\nprovider is a controlled local fixture, so the exercise needs no external Cal\naccount or product credential.\n\nThis is a learning path for the fleet process boundary. It is not a production\ndeployment or a qualification run. The reviewed source is commit\n97be86e9efedf07ecf1783b03800f683f107fb04.\n\nWhat you will observe\n\nBy the end of the tutorial, you will have observed:\n• source-derived container image and connector release identities;\n• registry admission before a connector host starts;\n• two product-neutral gateway replicas and one lifecycle control plane;\n• one healthy Cal.diy connector replica for tenant-acme;\n• a signed call to cap:caldiy:profile.get with status completed;\n• durable action lookup through either gateway replica;\n• bounded removal of only the named tutorial stack and its volumes.\n\nThe reference Compose file also defines deterministic hosts for Hermes Agent,\nChatwoot, Dify, and CrewAI. This tutorial builds those images but starts only\nthe Cal.diy product path. Twenty is one of the six maintained connectors, but\nit has no service in this deterministic fixture and follows its own deployment\nand qualification path.\n\nPrerequisites\n\nYou need:\n• a clean checkout at the reviewed source revision;\n• Docker Engine with Docker Compose v2 and BuildKit;\n• enough local CPU, memory, and disk for a source-based multi-image build;\n• TCP port 18443 free on the loopback interface;\n• a POSIX-compatible shell and lsof for the port preflight.\n\nRun every command from the aip-core repository root. The first preparation\ncan take substantially longer than the native quickstart because it builds the\ngateway, control plane, fixtures, and five product-host images.\n\nThe Compose project has the fixed name aip-connector-fleet-qualification.\nDo not use this tutorial while another run is using that project or while its\nvolumes contain evidence you need to retain.\n1. Verify the source and Docker boundary\n\nConfirm the exact source revision, a clean worktree, and an available Docker\ndaemon:\n\nexport AIPSOURCEREVISION=97be86e9efedf07ecf1783b03800f683f107fb04\n\ntest \"$(git rev-parse HEAD)\" = \"$AIPSOURCEREVISION\"\ntest -z \"$(git status --porcelain)\"\ndocker info >/dev/null\ndocker compose version\n\nAll four checks must exit with status 0. If the worktree is not clean, use a\nseparate clean checkout instead of hiding changes: the preparation script\nderives image and release identities from the complete workspace content.\n\nCheck that the fixed host port is unused:\n\nif ! command -v lsof >/dev/null; then\n  echo \"lsof is required for the port preflight\" >&2\n  exit 1\nfi\nif lsof -nP -iTCP:18443 -sTCP:LISTEN | grep -q .; then\n  echo \"Port 18443 is already in use\" >&2\n  exit 1\nfi\n\nExpected result: the command prints nothing and exits with status 0.\n2. Prepare source-derived images\n\nBuild the exact images and write their immutable image IDs to the generated\nCompose environment:\n\n./deploy/connector-fleet/prepare.sh\ntest -s deploy/connector-fleet/.env.qualification\n\nExpected result: the script ends with a line beginning\nconnector fleet preparation: PASS. The generated file contains source,\nimage, and release metadata for this workspace. At the reviewed revision it\ndoes not contain product credentials.\n\nDefine a short shell helper for the remaining commands:\n\ncompose() {\n  docker compose \\\n    --profile products \\\n    --env-file deploy/connector-fleet/.env.qualification \\\n    -f deploy/connector-fleet/compose.yml \\\n    \"$@\"\n}\n\nInspect the fixed Compose project before changing it:\n\ncompose ps --all\n\nIf this lists containers from another investigation or qualification run, stop\nhere and preserve that run first. This tutorial deliberately does not rename\nthe project because the source-owned volume and evidence tooling use its fixed\nidentity.\n3. Start one product path\n\nStart the Cal.diy host and its declared dependencies, and wait for running\nservices to become healthy:\n\ncompose up --detach --wait --wait-timeout 300 cal-acme-a\n\nExpected result: the command exits with status 0. Compose runs short-lived\ninitializers and admission jobs before it reports the long-running services as\nhealthy. The dependency graph starts:\n• PostgreSQL and registry initialization;\n• deterministic identity, policy, secret, and product fixtures;\n• the connector lifecycle control plane;\n• the TLS edge;\n• aipd and aipd-b against shared durable state;\n• the controlled product upstream;\n• cal-acme-a as a standalone connector host.\n\nThe setup graph also creates qualification-only admission artifacts. They are\ninternal test infrastructure, not additional public product connectors, and\ntheir host services are not part of this tutorial outcome.\n\nInspect both completed setup jobs and running services:\n\ncompose ps --all\n\ncal-acme-a, aipd, aipd-b, control-plane, edge, postgres, and\nproduct-upstream should be running and healthy. Initialization and admission\nservices may be exited with status 0 because they are one-shot jobs.\n4. Route one signed read\n\nRun aipctl inside the isolated fleet network. The command mounts the\nsource-generated client key, gateway DID, and local TLS authority from the\nCompose volumes:\n\ncompose run --rm --no-deps \\\n  --entrypoint /usr/local/bin/aipctl \\\n  -e AIPCTLNATIVEPRINCIPALID=service:aipctl:qualification-acme \\\n  -e AIPCTLNATIVETRUSTDOMAIN=fleet.test \\\n  -e AIPCTLNATIVESIGNINGSEEDFILE=/fleet-state/secrets/client-acme-signing-seed.hex \\\n  -e AIPCTLNATIVEPEERDIDFILE=/fleet-state/public/gateway.did \\\n  -e AIPCTLNATIVETLSCAFILE=/caddy-data/caddy/pki/authorities/local/root.crt \\\n  qualification action call \\\n  https://aipd.fleet.test:8443 \\\n  cap:caldiy:profile.get \\\n  --action-id actconnectorfleetquickstart001 \\\n  --input '{}'\n\nExpected result: the response is an AIP action result whose actionid is\nactconnectorfleetquickstart001 and whose status is completed. The\noutput contains the deterministic Cal.diy profile returned by the controlled\nupstream.\n\nThis completion demonstrates the configured local path: signed client request,\ngateway authentication, tenant-scoped capability routing, connector-host\nexecution, and a product-shaped fixture response. It does not demonstrate\nbehavior against a live Cal.diy deployment.\n5. Read the action through the second gateway\n\nQuery the shared durable action state through aipd-b without replaying the\nprovider operation:\n\ncompose run --rm --no-deps \\\n  --entrypoint /usr/local/bin/aipctl \\\n  -e AIPCTLNATIVEPRINCIPALID=service:aipctl:qualification-acme \\\n  -e AIPCTLNATIVETRUSTDOMAIN=fleet.test \\\n  -e AIPCTLNATIVESIGNINGSEEDFILE=/fleet-state/secrets/client-acme-signing-seed.hex \\\n  -e AIPCTLNATIVEPEERDIDFILE=/fleet-state/public/gateway.did \\\n  -e AIPCTLNATIVETLSCAFILE=/caddy-data/caddy/pki/authorities/local/root.crt \\\n  -e AIPCTLNATIVEBEARERTOKENFILE=/fleet-state/secrets/native-bearer-token \\\n  qualification action status \\\n  https://aipd-b.fleet.test:8443 \\\n  actconnectorfleetquickstart001 \\\n  --include-result \\\n  --include-receipts\n\nExpected result: the lifecycle view identifies the same action and capability,\nreports a terminal state with resultstatus set to completed, and includes\nthe stored result. A successful lookup shows that the two gateway replicas use\nthe same durable runtime state; it is not a failover or recovery test.\n6. Verify the tutorial outcome\n\nRepeat a non-mutating status lookup and require both the connector host and\ngateways to remain healthy:\n\ntest \"$(compose ps --status running --services | grep -cx 'cal-acme-a')\" -eq 1\ntest \"$(compose ps --status running --services | grep -Ec '^aipd(-b)?$')\" -eq 2\n\ncompose run --rm --no-deps \\\n  --entrypoint /usr/local/bin/aipctl \\\n  -e AIPCTLNATIVEPRINCIPALID=service:aipctl:qualification-acme \\\n  -e AIPCTLNATIVETRUSTDOMAIN=fleet.test \\\n  -e AIPCTLNATIVESIGNINGSEEDFILE=/fleet-state/secrets/client-acme-signing-seed.hex \\\n  -e AIPCTLNATIVEPEERDIDFILE=/fleet-state/public/gateway.did \\\n  -e AIPCTLNATIVETLSCAFILE=/caddy-data/caddy/pki/authorities/local/root.crt \\\n  -e AIPCTLNATIVEBEARERTOKENFILE=/fleet-state/secrets/native-bearer-token \\\n  qualification action status \\\n  https://aipd.fleet.test:8443 \\\n  actconnectorfleetquickstart001 \\\n  --include-result >/dev/null\n\nAll three commands must exit with status 0. You have now observed admission,\nregistration, signed routing, standalone execution, and shared durable lookup\nfor one low-risk product capability.\n\nStop and clean up\n\nBefore deletion, capture diagnostics if any step failed:\n\ncompose ps --all\ncompose logs --no-color --tail 200 aipd aipd-b control-plane cal-acme-a\n\nWhen no retained state from this named project is needed, remove its containers,\nnetwork, and volumes:\n\ncompose down --volumes --remove-orphans --timeout 30\ntest -z \"$(compose ps --all --quiet)\"\n\nThe first command deletes the project volumes, including PostgreSQL state,\ngenerated keys, and any qualification evidence stored there. It does not prune\nunrelated containers, images, build cache, or volumes. Keep the images if you\nintend to repeat the tutorial; remove them only through a separately reviewed\ncleanup decision.\n\nResolve common failures\n\n| Symptom | Decision |\n\n| Preparation reports that Docker is unavailable | Start or repair the Docker daemon, then rerun the same source check before preparation |\n| Port 18443 is already in use | Identify the owning process or existing fleet run; do not stop or delete it without confirming ownership |\n| An image build fails | Preserve the build output, confirm disk and tool availability, and rerun prepare.sh from the same clean revision |\n| A one-shot admission job exits nonzero | Inspect compose ps --all and that job's logs; do not bypass admission or start the host manually |\n| A service does not become healthy | Inspect the named service, its dependency state, and bounded logs before cleanup |\n| The signed action is rejected | Confirm that the command uses the generated principal, key, peer DID, CA, and tenant-acme fixture unchanged |\n| The action completes but the second lookup fails | Preserve gateway and PostgreSQL logs; this tutorial does not authorize recreating shared state as a repair |\n\nWhat happened internally\n\nThe fixture generated trust material and immutable admission packages, migrated\nthe connector registry, and admitted the Cal.diy connector version before its\nhost process started. The host then registered a tenant-scoped replica and\nrenewed its lease with the lifecycle control plane.\n\nThe signed aipctl request reached the product-neutral gateway. The gateway\nselected an eligible Cal.diy replica from the registry and sent the action to\nthe standalone host. That host resolved its fixture credential, called the\ncontrolled upstream, and returned a typed result. Both gateways used the same\nPostgreSQL-backed runtime state, so the second gateway could read the completed\naction without repeating the product call.\n\nThe repository's full product-fleet qualification exercises all five fixture\nhosts, governed mutations, tenant isolation, durable replay, outages, restarts,\nand failover. Those checks belong to the qualification documentation and are\nintentionally outside this quickstart.\n\nNext steps\n• Understand connector-fleet architecture (../architecture/connector-fleet.md)\n• Adopt the Cal.diy connector (../connectors/cal-diy.md)\n• Deploy a connector fleet (../guides/deploy-connector-fleet.md)\n• Run connector-fleet qualification (../testing/connector-fleet-qualification.md)\n• Follow the separate Twenty path (../connectors/twenty.md)\n"
  },
  "integrity": {
    "algorithm": "sha256",
    "sourceDigest": "8f024f0cd5652686849d837794c65c8c3343c1155320edf6213af974b33244c5"
  }
}