@intentius/chant 0.13.1 → 0.15.0

package/src/components/README.md

@@ -0,0 +1,130 @@
+# Component contract schema
+
+`component.schema.json` is the portable JSON Schema (draft 2020-12) for the
+**Component contract** described in the
+[Components docs](../../../../docs/src/content/docs/components/) —
+specifically
+[`component-contract.mdx`](../../../../docs/src/content/docs/components/component-contract.mdx)
+(fields, archetypes, the JSON projection) and
+[`composition-and-wiring.mdx`](../../../../docs/src/content/docs/components/composition-and-wiring.mdx)
+(the phase grammar, fan-out, and wiring reference forms). Those docs are
+authoritative over this schema's prose; the schema is authoritative over the
+document *shape*.
+
+## This schema is the substrate, not a chant-only type
+
+A component is declarative data. chant's TypeScript authoring form (`Component`,
+`phase()`, capability builders, etc. — tracked separately, see #551 "Chant-native
+plugin" phase) is one typed frontend that **projects to** this JSON document. A
+non-chant or legacy component can hand-write this JSON directly and be driven
+by the same generic orchestrator, with no chant authoring step required. Making
+the contract a portable spec rather than a runtime-only object is what keeps
+walk-away cost low: nothing about participating in the release model requires
+adopting chant.
+
+## What it models
+
+- **Identity and ordering** — `name`, `dependsOn` (ordering only, resolved by
+  `chant graph --stacks`, no logic).
+- **Live name mapping** — `liveNames` (#598), optional: the live lexicon
+  entity/resource name(s) this component owns, when they differ from `name`.
+  `chant components status --live` (`../lifecycle/status.ts`) joins the
+  release ledger against live evidence by name; `liveNames` lets that join
+  work for a component whose own name isn't the entity/resource name it
+  deploys, falling back to `name` itself when omitted. See
+  docs/src/content/docs/components/observability.mdx.
+- **The three archetypes** — service (build → publish → apply → verify),
+  infra (apply → verify, no build), and producer/library (build → publish
+  only, no service apply). `deploy` being a plain composition is what makes
+  build-only and apply-only shapes first-class rather than special cases.
+- **The composition grammar** — `deploy` is an ordered list of `Phase`s;
+  phases carry `steps` (capability invocations), an optional `parallel` flag,
+  and an optional `onFailure` for saga-style compensation. A step may itself
+  be a nested `Phase`, which is how fan-out (e.g. a Neo4j cluster seeding one
+  node then rolling through the rest) is expressed as composition rather than
+  orchestrator knowledge.
+- **Gates** — a distinct step shape (`kind: "gate"`, `signalName`) for a
+  durable, human-approval wait.
+- **Wiring reference forms**, all resolved by the graph, never by orchestrator
+  code:
+  - `$env.<path>` — environment config (e.g. `$env.registry`).
+  - `@<Phase>.<field>` — a prior step's output within the same component
+    (e.g. `@Publish.digest`).
+  - `@<component>.publish.uri|digest|key` — another component's published
+    artifact output (e.g. `@jar-lib.publish.uri`); the referenced component
+    must appear in `dependsOn`.
+  - `{ "stackOutput": { "stack", "name" } }` — a cross-stack
+    CloudFormation/ARM/... output, the JSON-side equivalent of the
+    TypeScript `stackOutput()` mechanism.
+
+Capability-specific step properties (beyond the cross-cutting wiring-typed
+ones like `imageRef`/`jar`/`revision`/`inputs`) are intentionally left open
+(`additionalProperties: true` on `Step`). The capability interface and its
+per-verb input/output types are the subject of a separate spec (#554); this
+schema only needs every capability invocation to be representable as
+`{ kind, ...params }`.
+
+## Versioning
+
+- `$id` is stable: `https://intentius.io/chant/schemas/component/v1/component.schema.json`.
+  A breaking change to the contract gets a new `v2` path; this file does not
+  change shape incompatibly in place.
+- `contractVersion` (currently pinned to `"1.0.0"`) is the document-level
+  version field a hand-written component can assert against.
+
+## Fixtures and tests
+
+`__fixtures__/` holds real components drawn from the epic (#551): an ALB/ECS
+service, a DynamoDB table, a Neo4j fan-out cluster, a JAR producer and its EMR
+consumer, a single-host Docker Compose service, and (#558) a container-image
+Lambda function. `component-schema.test.ts` validates every fixture against
+`component.schema.json` with [ajv](https://ajv.js.org/) (`ajv/dist/2020` — the
+draft 2020-12 build) and exercises the schema's negative cases (missing
+required fields, malformed wiring references, an invalid archetype, a gate
+missing `signalName`, and so on).
+
+## Typed authoring form (`component.ts`, #560)
+
+`component.ts` is the real typed `Component` authoring frontend the docs
+describe: `Component`, `Phase`, `Step`, `Gate`, `BuildSpec`, `Wiring` mirror
+this schema's `$defs` field-for-field, plus the `phase()`/`gate()`/
+`stackOutput()` builders and `projectToJson()` (the mechanical TS → JSON
+projection, filling in `archetype` via `inferArchetype` when a component
+doesn't set one explicitly — see the archetype table above). It supersedes
+the Phase 1 stopgap `pilots/authoring-shape.ts` (deleted), which explicitly
+deferred the real API to this issue.
+
+## Discovery (`discover.ts`, #560)
+
+`discoverComponents(path)` finds every `Component` declared under a
+directory, mirroring chant's existing declarable discovery
+(`../discovery/index.ts`) as closely as a structurally distinct type allows,
+and borrowing its file-suffix convention from Op discovery
+(`../op/discover.ts`'s `*.op.ts`): any `.component.ts` file (excluding
+`.test.component.ts`/`.spec.component.ts`) is scanned, every export
+satisfying `isComponent` is collected (any export name, not just `default`,
+so one file may declare several related components), and a duplicate
+`component.name` across files is a discovery error — the same duplicate-name
+discipline `collectEntities`/`discoverOps` already apply to resources/Ops.
+`*.component.ts` was chosen over reusing the generic `.ts` + `Declarable`
+marker convention because a `Component` has no `lexicon`/`entityType` shape
+to tag; see `discover.ts`'s docstring for the full reasoning.
+
+## Pilots
+
+`pilots/` (#555) authors three of those fixtures — the ALB/ECS service, the
+DynamoDB table, and the Neo4j fan-out cluster — a second way: as TypeScript
+authored against `component.ts`, composed from the real capability verbs in
+`verbs/`. Each pilot's JSON projection is asserted equal to its
+`__fixtures__/*.json` counterpart, so the fixture stays the one authoritative
+JSON document; see `pilots/README.md` for the axis-by-axis mapping (build vs
+no-build, single vs fan-out, sticky vs simple apply, cross-stack wiring, auto
+vs no rollback).
+
+`pilots/lambda.pilot.ts` (#558) adds a fourth component the same way — a
+container-image Lambda function — to validate the sprawl metric holds beyond
+the three pilots that were picked specifically to prove it. See
+[`SPRAWL-VALIDATION.md`](./SPRAWL-VALIDATION.md) for the full write-up: the
+before/after against the ALB/ECS pipeline's `describe-stacks | jq` glue, and
+the per-component scorecard (new pipelines / driver edits / declarations /
+capabilities) the epic's "definition of done" asks for.

package/src/components/SPRAWL-VALIDATION.md

@@ -0,0 +1,181 @@
+# Sprawl metric validation (#558, epic #551)
+
+This validates the sprawl metric epic #551 defines as its "definition of
+done" against the three real pilots (#555) plus a fourth, deliberately
+different component added here. Everything below runs through the one
+generic `runInterpretDriver` (#556, [`../driver.ts`](./driver.ts)), unchanged.
+
+## The metric, from #551
+
+> - Typical new component: 0 new pipelines, 0 orchestrator edits, 0 new capabilities, 1 declaration.
+> - Genuinely novel component: 0 pipelines, 0 orchestrator edits, at most 1 new capability (then reusable), 1 declaration.
+> - Cross-cutting change: 1 capability edited, 0 components touched.
+> - The generic orchestrator contains zero per-component code (no `if component.name === ...`).
+> - Three of our most-different real components run through one driver with no per-component driver code.
+
+## Before / after: the ALB/ECS pipeline glue this replaces
+
+The component model's whole reason for existing is visible in one concrete
+diff. [`examples/gitlab-aws-alb-api/src/pipeline.ts`](../../../../../examples/gitlab-aws-alb-api/src/pipeline.ts)
+hand-rolls a `deployService` job that shells out to CloudFormation and greps
+its own infra stack's outputs before it can deploy:
+
+```ts
+// before — examples/gitlab-aws-alb-api/src/pipeline.ts (deployService job)
+`OUTPUTS=$(aws cloudformation describe-stacks --stack-name ${INFRA_STACK} --query 'Stacks[0].Outputs' --output json)`,
+`PARAMS=$(echo "$OUTPUTS" | jq -r '[(.[] | select(.OutputKey == "ClusterArn") | "clusterArn=" + .OutputValue), (.[] | select(.OutputKey == "ListenerArn") | "listenerArn=" + .OutputValue), ...] | join(" ")')`,
+`IMAGE_URI=$(echo "$OUTPUTS" | jq -r '.[] | select(.OutputKey == "ApiRepoUri") | .OutputValue'):${CI_COMMIT_REF_SLUG}`,
+`aws cloudformation deploy --template-file templates/template.json --stack-name ${STACK_NAME} ... --parameter-overrides $PARAMS image=$IMAGE_URI`,
+```
+
+That `describe-stacks | jq` line is bespoke per pipeline: every component that
+imports another stack's outputs re-derives its own grep. The component-native
+replacement ([`pilots/alb-ecs.pilot.ts`](./pilots/alb-ecs.pilot.ts)) expresses
+the same import as typed cross-stack wiring, resolved by the graph rather than
+scripted in the pipeline:
+
+```ts
+// after — pilots/alb-ecs.pilot.ts
+const sharedAlbOutputs = {
+  listenerArn: { stackOutput: { stack: "shared-alb", name: "ListenerArn" } },
+  clusterArn: { stackOutput: { stack: "shared-alb", name: "ClusterArn" } },
+  subnets: { stackOutput: { stack: "shared-alb", name: "Subnets" } },
+};
+// ...
+{ kind: "cfn-deploy", template: "archive:search.template.json", imageRef: "@Publish.digest", inputs: sharedAlbOutputs }
+```
+
+No `describe-stacks`, no `jq`, no shell string-building. `dependsOn:
+["shared-alb"]` plus three `stackOutput()` references replace the whole glue
+block; `docker build`/`docker push` become the `docker-build`/`publish-image`
+capabilities the driver dispatches to. [`driver.test.ts`](./driver.test.ts)
+and [`pilots/pilots-e2e.test.ts`](./pilots/pilots-e2e.test.ts) exercise this
+exact wiring end to end against a mock `CloudExecutor` — `cfn-deploy`
+resolves the `stackOutput` reference itself; no orchestrator code parses a
+CloudFormation output.
+
+## The three pilots, unchanged, through the one driver
+
+[`driver.test.ts`](./driver.test.ts)'s `"runs the three pilots through one
+driver instance with zero per-component driver code (sprawl metric)"` test
+(pre-existing from #556/#557, still green) and
+[`pilots-e2e.test.ts`](./pilots/pilots-e2e.test.ts)'s first `describe` block
+run Neo4j fan-out, DynamoDB (sticky apply), and ALB/ECS (cross-stack, build)
+through the same `runInterpretDriver` call, dispatching to the real,
+`MockCloudExecutor`-backed capability implementations from #557
+(`docker-build`, `publish-image`, `cfn-deploy`, `ecs-update-service`,
+`code-deploy`, `wait-for-stack`, `wait-steady-state`, `wait-cluster-healthy`).
+Nothing in [`driver.ts`](./driver.ts) branches on which of the three is
+running — dispatch is purely by step `kind` via `CapabilityRegistry.resolve`.
+
+## The fourth component: image-processor-lambda
+
+To validate the metric holds beyond the three pilots that were picked
+specifically to prove it, this issue adds a fourth, deliberately different
+component: [`pilots/lambda.pilot.ts`](./pilots/lambda.pilot.ts) /
+[`__fixtures__/lambda-image-processor.json`](./__fixtures__/lambda-image-processor.json),
+a container-image AWS Lambda function (`image-processor-lambda`).
+
+It was picked over the single-host docker-compose fixture
+([`__fixtures__/single-host-compose.json`](./__fixtures__/single-host-compose.json))
+specifically because compose would have needed four still-stubbed
+capabilities at once (`load-image-on-host`, `copy-to-host`, `remote-exec`,
+`wait-endpoint`) to actually run — busting the "at most 1 new capability"
+bound before it even started. Lambda needed exactly one.
+
+What makes it genuinely different from the three pilots, not a shape
+variation of ALB/ECS:
+
+- **No CloudFormation at all in its apply step.** Every one of the three
+  pilots (and `shared-alb`) applies via `cfn-deploy`. `image-processor-lambda`
+  is the first component in the validation set whose Apply phase contains no
+  `cfn-deploy` — it calls `UpdateFunctionCode` / `PublishVersion` /
+  `UpdateAlias` directly against the function.
+- **Alias-based promotion, not a stack changeset.** Verification/rollback
+  reason about an alias pointer (`live` -> version N), not a stack status or a
+  service's running/desired task count.
+
+What it reuses unchanged (zero new capabilities here): `docker-build` and
+`publish-image` — a container-image Lambda's build/publish story is
+byte-identical to ALB/ECS's (build an image, promote it by digest into the
+registry); the same `@Publish.uri` prior-step wiring form every pilot already
+uses carries the image reference into the apply step.
+
+### The one new capability: `lambda-deploy`
+
+[`verbs/apply.ts`](./verbs/apply.ts)'s `createLambdaDeployCapability` is the
+only new leaf this component required, built the same way #557 built the
+other real leaves: typed input/output, an injectable `CloudExecutor`
+(extended with a `lambda` client — [`verbs/cloud-executor.ts`](./verbs/cloud-executor.ts)),
+a real shell-out implementation for production, and a `MockCloudExecutor`
+implementation ([`verbs/__tests__/mock-cloud-executor.ts`](./verbs/__tests__/mock-cloud-executor.ts))
+for tests. It declares a `rollback` (repoint the alias back to whatever
+version it pointed at before this step ran) — the same best-effort,
+capability-level compensation style `ecs-update-service` uses, since Lambda
+has no native automatic rollback for a code update the way CodeFormation/
+CodeDeploy do.
+
+No other verb was touched or added. `driver.ts` was not edited.
+
+### Proof it runs through the same driver
+
+[`driver.test.ts`](./driver.test.ts)'s `"runs all four components ... through
+one driver instance with zero per-component driver code (sprawl metric,
+extended)"` test and [`pilots-e2e.test.ts`](./pilots/pilots-e2e.test.ts)'s
+second `describe`-block test run all five components (`shared-alb`,
+`orders-table`, `neo4j-cluster`, `search-service`, `image-processor-lambda`)
+through one `runInterpretDriver` call, dispatching `image-processor-lambda`'s
+steps to the real `lambda-deploy` capability against a shared
+`MockCloudExecutor` — no live AWS.
+
+## Scorecard
+
+| Component | New pipelines | Driver edits | New declarations | New capabilities | Reused capabilities |
+|---|---|---|---|---|---|
+| Neo4j fan-out (#555) | 0 | 0 | 1 | 0 (#557 implemented the pilot set together) | `cfn-deploy`, `code-deploy`, `wait-cluster-healthy` |
+| DynamoDB (#555) | 0 | 0 | 1 | 0 | `cfn-deploy`, `wait-for-stack` |
+| ALB/ECS (#555) | 0 | 0 | 1 | 0 | `docker-build`, `publish-image`, `cfn-deploy`, `ecs-update-service`, `wait-steady-state` |
+| **image-processor-lambda (#558, this issue)** | **0** | **0** | **1** | **1** (`lambda-deploy`) | `docker-build`, `publish-image` |
+
+Read row-by-row against the metric: every component is one declaration, zero
+new pipelines, zero driver edits. The fourth component needed exactly one new
+capability — inside the "genuinely novel: at most 1" bound, not the
+"typical: 0" bound the three original pilots hit, which is the honest result
+for a component that introduces a capability family (Lambda code deploy) none
+of the three pilots exercised.
+
+## Blockers found: none
+
+No case forced a per-component branch in `driver.ts`. `driver.ts` was not
+modified by this issue — every dispatch (`runCapabilityStep`, `runPhase`,
+`resolveWiring`) already operates purely on the generic
+`Component`/`Phase`/`Step` shapes and the `kind` string, with no branch naming
+a specific component or capability. The fourth component's differences (no
+`cfn-deploy` in Apply, alias-based promotion) required a new *capability*,
+which is exactly where the epic says new behavior should land — never a new
+capability *forced a driver change* to accommodate it.
+
+If a future component needs multiple new capabilities at once (as
+single-host compose would — four stubs), that is not by itself a driver
+special-case; it just means that component was not the cheapest pick for a
+minimal walkthrough. `load-image-on-host` / `copy-to-host` / `remote-exec` /
+`wait-endpoint` remain typed stubs (`../capability.ts`'s "no cloud
+implementation yet" contract) — implementing them is future capability work,
+out of scope for this validation issue, and does not block the metric: the
+schema/fixture already validates that composition
+([`component-schema.test.ts`](./component-schema.test.ts)), only the cloud
+leaves are unimplemented.
+
+## Assumptions
+
+- `lambda-deploy`'s `codeRef` carries a container image URI (this issue's
+  chosen shape), not a zip/S3 key — `zip-package` stays a stub, so a
+  zip-packaged Lambda was not in scope; a container-image Lambda was the
+  cheaper, still-genuinely-novel choice.
+- `health-gate` in the Lambda pilot's Verify phase remains a typed stub (as it
+  already was for the ALB/ECS pilot) — verifying this issue is about apply
+  dispatch (`lambda-deploy`), not the wait/verify family.
+- The Lambda pilot has no component-level `rollback` field (unlike ALB/ECS):
+  `lambda-deploy`'s own capability-level rollback (restore the alias) is
+  sufficient here, so no explicit compensation phase was added to the
+  declaration.

package/src/components/__fixtures__/alb-ecs-service.json

@@ -0,0 +1,51 @@
+{
+  "$schema": "https://intentius.io/chant/schemas/component/v1/component.schema.json",
+  "contractVersion": "1.0.0",
+  "name": "search-service",
+  "archetype": "service",
+  "dependsOn": ["shared-alb"],
+  "build": { "kind": "docker-build", "context": ".", "into": "archive" },
+  "deploy": [
+    {
+      "phase": "Publish",
+      "steps": [
+        { "kind": "publish-image", "from": "archive", "to": "$env.registry" }
+      ]
+    },
+    {
+      "phase": "Apply",
+      "steps": [
+        {
+          "kind": "cfn-deploy",
+          "template": "archive:search.template.json",
+          "imageRef": "@Publish.digest",
+          "inputs": {
+            "listenerArn": { "stackOutput": { "stack": "shared-alb", "name": "ListenerArn" } },
+            "clusterArn": { "stackOutput": { "stack": "shared-alb", "name": "ClusterArn" } },
+            "subnets": { "stackOutput": { "stack": "shared-alb", "name": "Subnets" } }
+          }
+        },
+        {
+          "kind": "ecs-update-service",
+          "cluster": "$env.cluster",
+          "service": "search"
+        }
+      ]
+    },
+    {
+      "phase": "Verify",
+      "steps": [
+        { "kind": "wait-steady-state", "service": "search" },
+        { "kind": "health-gate", "path": "/healthz" }
+      ]
+    }
+  ],
+  "rollback": [
+    {
+      "phase": "Rollback",
+      "steps": [
+        { "kind": "rollback-previous", "service": "search", "cluster": "$env.cluster" }
+      ]
+    }
+  ]
+}

package/src/components/__fixtures__/dynamodb-infra.json

@@ -0,0 +1,32 @@
+{
+  "$schema": "https://intentius.io/chant/schemas/component/v1/component.schema.json",
+  "contractVersion": "1.0.0",
+  "name": "orders-table",
+  "archetype": "infra",
+  "dependsOn": [],
+  "deploy": [
+    {
+      "phase": "Apply",
+      "steps": [
+        {
+          "kind": "cfn-deploy",
+          "template": "archive:orders-table.template.json",
+          "onReplace": "block",
+          "stageGsi": true
+        }
+      ]
+    },
+    {
+      "phase": "Verify",
+      "parallel": true,
+      "steps": [
+        { "kind": "wait-for-stack", "stack": "orders-table" },
+        {
+          "kind": "run-migration",
+          "script": "archive:migrations/backfill-gsi.sql",
+          "noRollback": "GSI backfill is forward-only; undoing it needs a second, hand-written migration, not automatic compensation"
+        }
+      ]
+    }
+  ]
+}

package/src/components/__fixtures__/emr-job-consumer.json

@@ -0,0 +1,26 @@
+{
+  "$schema": "https://intentius.io/chant/schemas/component/v1/component.schema.json",
+  "contractVersion": "1.0.0",
+  "name": "emr-job",
+  "archetype": "infra",
+  "dependsOn": ["jar-lib"],
+  "deploy": [
+    {
+      "phase": "Submit",
+      "steps": [
+        {
+          "kind": "emr-start-job-run",
+          "jar": "@jar-lib.publish.uri",
+          "args": ["--input", "$env.inputPath", "--output", "$env.outputPath"],
+          "noRollback": "a submitted job run has no automatic undo; cancelling it does not revert data it already wrote"
+        }
+      ]
+    },
+    {
+      "phase": "Verify",
+      "steps": [
+        { "kind": "wait-job", "runId": "@Submit.runId" }
+      ]
+    }
+  ]
+}

package/src/components/__fixtures__/jar-lib-producer.json

@@ -0,0 +1,16 @@
+{
+  "$schema": "https://intentius.io/chant/schemas/component/v1/component.schema.json",
+  "contractVersion": "1.0.0",
+  "name": "jar-lib",
+  "archetype": "producer-library",
+  "dependsOn": [],
+  "build": { "kind": "jvm-build", "context": ".", "into": "archive" },
+  "deploy": [
+    {
+      "phase": "Publish",
+      "steps": [
+        { "kind": "publish-artifact", "from": "archive", "to": "$env.s3" }
+      ]
+    }
+  ]
+}

package/src/components/__fixtures__/lambda-image-processor.json

@@ -0,0 +1,28 @@
+{
+  "$schema": "https://intentius.io/chant/schemas/component/v1/component.schema.json",
+  "contractVersion": "1.0.0",
+  "name": "image-processor-lambda",
+  "archetype": "service",
+  "dependsOn": [],
+  "build": { "kind": "docker-build", "context": ".", "into": "archive" },
+  "deploy": [
+    {
+      "phase": "Publish",
+      "steps": [
+        { "kind": "publish-image", "from": "archive", "to": "$env.registry" }
+      ]
+    },
+    {
+      "phase": "Apply",
+      "steps": [
+        { "kind": "lambda-deploy", "functionName": "image-processor", "codeRef": "@Publish.uri", "alias": "live" }
+      ]
+    },
+    {
+      "phase": "Verify",
+      "steps": [
+        { "kind": "health-gate", "path": "@Apply.functionArn" }
+      ]
+    }
+  ]
+}

package/src/components/__fixtures__/neo4j-fanout.json

@@ -0,0 +1,34 @@
+{
+  "$schema": "https://intentius.io/chant/schemas/component/v1/component.schema.json",
+  "contractVersion": "1.0.0",
+  "name": "neo4j-cluster",
+  "archetype": "infra",
+  "dependsOn": [],
+  "deploy": [
+    {
+      "phase": "Seed",
+      "steps": [
+        { "kind": "cfn-deploy", "template": "archive:neo4j-az0-0.template.json" },
+        { "kind": "code-deploy", "instance": 0, "revision": "@Seed.templateUri" },
+        { "kind": "wait-cluster-healthy", "size": 1 }
+      ]
+    },
+    {
+      "phase": "Node 1",
+      "steps": [
+        { "kind": "gate", "signalName": "approve-neo4j-node-1", "description": "Confirm the seed node is healthy before rolling to node 1", "timeout": "24h" },
+        { "kind": "cfn-deploy", "template": "archive:neo4j-1.template.json" },
+        { "kind": "code-deploy", "instance": 1, "revision": "@Seed.templateUri" },
+        { "kind": "wait-cluster-healthy", "quorum": true }
+      ]
+    },
+    {
+      "phase": "Node 2",
+      "steps": [
+        { "kind": "cfn-deploy", "template": "archive:neo4j-2.template.json" },
+        { "kind": "code-deploy", "instance": 2, "revision": "@Seed.templateUri" },
+        { "kind": "wait-cluster-healthy", "quorum": true }
+      ]
+    }
+  ]
+}

package/src/components/__fixtures__/single-host-compose.json

@@ -0,0 +1,29 @@
+{
+  "$schema": "https://intentius.io/chant/schemas/component/v1/component.schema.json",
+  "contractVersion": "1.0.0",
+  "name": "monitoring-host",
+  "archetype": "service",
+  "dependsOn": [],
+  "build": { "kind": "docker-build", "context": ".", "into": "archive" },
+  "deploy": [
+    {
+      "phase": "Publish",
+      "steps": [
+        { "kind": "load-image-on-host", "from": "archive", "host": "$env.host" }
+      ]
+    },
+    {
+      "phase": "Apply",
+      "steps": [
+        { "kind": "copy-to-host", "from": "archive:compose.yaml", "to": "/opt/monitoring/compose.yaml", "host": "$env.host" },
+        { "kind": "remote-exec", "host": "$env.host", "command": "docker compose -f /opt/monitoring/compose.yaml up -d" }
+      ]
+    },
+    {
+      "phase": "Verify",
+      "steps": [
+        { "kind": "wait-endpoint", "host": "$env.host", "path": "/-/healthy", "port": 9090 }
+      ]
+    }
+  ]
+}