Deploy

This skill sets honcho up before it reports honcho is up

You are about to bring honcho up from a recipe, not from a finished instance. The skill ships honcho as source: a carried recipe plus the pin to the code that runs it, like a self-extracting archive that carries both its contents and the unpacker. Before you tell anyone honcho is running, deploy it against this target and GRADE it honestly. You do the work in-loop; nobody runs a command line. The material is the carried recipe, the binds, the checks, and the acceptance in the sections below.

Two roles run through this. The author packaged honcho as this skill on their machine. The receiver is whoever installs it, a different target, whose substrate, secrets, and paths you resolve here. You work so the receiver reaches a real, graded honcho, or an honest reason it could not, never a silent success.

Recipe (run before your first report that honcho is up)

1. Cache / idempotency. If honcho is already up on this target in this session (a prior graded namespace exists, or a resolution is recorded here), reuse it, emit the Reusing line, and skip to step 6. Do not re-deploy over a live instance.

2. Resolve the binds. For each entry in the binds section, probe this target for the matching capability, and resolve the isolation substrate to the required strength the carried recipe names. If a required bind has no match here, or no substrate meets the required strength, STOP, deploy nothing, and report cannot-build naming the missing one. Never guess and never substitute. If you cannot positively confirm a required bind, treat it as missing.

3. Self-extract the runtime (the bootstrap). The carried recipe carries a pin under operators (version, url, sha256), but the code that runs the deploy lives inside that kit, so you unpack it yourself first, and only after verifying it. Do exactly this: (a) fetch the tarball at the pin url; (b) compute its sha256 and confirm it equals the pin's sha256, if it does not, STOP and report cannot-build (tampered or wrong kit), and never unpack or run an unverified tarball; (c) extract the verified tarball, that unpack IS the self-extraction, and it yields the runtime: hoist/pins.py (fetch and verify), envelope/ (the enforced grader: isolation, honest grade, teardown), and the operator steps. From here the extracted runtime drives the graded pass and re-verifies the kit into its cache. Because you checked the sha256 by hand before unpacking, nothing unverified executes.

4. Know early, then deploy. Run the pre-check first, it deploys nothing. If it says cannot-build, stop at the door and give the user the named reason. Otherwise run the full graded pass through the extracted grader, which enforces the invariants: a runner-owned isolated namespace (non-destructive), and teardown. You never re-run honcho's own singular deployment onto a live host.

5. Grade. The acceptance checks rebuild on THIS target. Compute the honest transfer score, how many of the acceptance checks passed, N of M, and name every check that did not transfer.

6. Report the outcome in one line, using one of the templates below. Never let a design read as a running system; if it did not transfer, say what did not.

7. Hand off. Point the user at any follow-up the carried recipe includes (how to extend it, operate it, or keep it running), so they can use honcho, not merely have it installed.

Before your first report, state in one line what happened, only one line, and do not narrate the loop, using one of these templates:

• "Built honcho. Acceptance transferred N of M on this target. Ready."
• "Built honcho, but N of M acceptance checks did not transfer here: [the specific checks]."
• "Cannot build honcho: this target is missing [the named bind or substrate strength]."
• "Reusing the honcho setup from earlier this session. Ready."

The failure to avoid: reporting honcho is up because the recipe looks right. It is up only when it deployed and its acceptance transferred on this target. Grade it, then report what you measured.

The carried recipe (the authority; the operators pin travels with it)

{
  "app": "honcho",
  "binds": [
    {
      "name": "docker",
      "probe": "docker version --format '{{.Server.Version}}'",
      "required": true
    }
  ],
  "default_profile": "minimal",
  "operators": {
    "sha256": "8b1c4b72964d190f65fac09d0ef31611fbab6e4ba5d2dd17b9de985028fb7225",
    "url": "https://github.com/3dl-dev/hoistable/releases/download/operators-v0.7.0/hoistable-operators-0.7.0.tgz",
    "version": "0.7.0"
  },
  "profiles": {
    "minimal": {
      "acceptance": [
        {
          "check": "curl -fsS http://localhost:8000/health | grep -qi ok",
          "name": "health-reports-ok"
        },
        {
          "check": "curl -fsS http://localhost:8000/openapi.json | grep -q '\"openapi\"'",
          "name": "openapi-served"
        },
        {
          "check": "curl -fsS -X POST http://localhost:8000/v3/workspaces -H 'Content-Type: application/json' -d '{\"name\":\"hoist-smoke\"}' | grep -q hoist-smoke",
          "name": "workspace-crud-roundtrip"
        }
      ],
      "bringup": [
        {
          "name": "copy-compose",
          "run": "cp docker-compose.yml.example docker-compose.yml"
        },
        {
          "name": "copy-env",
          "run": "cp .env.template .env 2>/dev/null || true"
        },
        {
          "name": "compose-up-minimal-3",
          "run": "docker compose up -d --build --wait --wait-timeout 600 database redis api"
        }
      ],
      "health": [
        {
          "check": "docker compose exec -T database pg_isready -U postgres",
          "name": "database"
        },
        {
          "check": "docker compose exec -T redis redis-cli ping",
          "name": "redis"
        },
        {
          "check": "curl -fsS http://localhost:8000/health",
          "name": "api-health-endpoint"
        }
      ],
      "isolation": {
        "require": "environmental",
        "why": "honcho is an external app we have never packaged; a fresh clone is not a clean target. Run it where a deploy cannot reach host state, whatever its compose declares (fixed project name, loopback ports, named volumes)."
      },
      "preflight": [
        {
          "name": "docker-daemon-reachable",
          "probe": "docker info >/dev/null 2>&1",
          "required": true
        }
      ]
    }
  },
  "source": {
    "clone": "https://github.com/plastic-labs/honcho",
    "dir": "honcho"
  }
}

Binds (resolve these on the target; a missing required one is cannot-build)

• docker (required), probe: docker version --format '{{.Server.Version}}'
• isolation substrate (required): a rung of at least environmental strength must resolve on the target, or this is cannot-build.

Checks (invariants every deploy obeys)

• Non-destructive. The deploy lands in a runner-owned isolated namespace (its own name, ports, storage); a profile that declares no isolation is refused; teardown always runs. It never re-runs honcho's own singular deployment onto a live host.
• No silent success. honcho is graded on the real target; a run that cannot say it worked says what did not transfer. A design never reads as a running system.
• Verified runtime. The fetched kit is run only after its sha256 matches the carried pin; a tampered or unreachable kit is cannot-build, named.

Acceptance (the held-back transfer test; the honest score)

• health-reports-ok: curl -fsS http://localhost:8000/health | grep -qi ok
• openapi-served: curl -fsS http://localhost:8000/openapi.json | grep -q '"openapi"'
• workspace-crud-roundtrip: curl -fsS -X POST http://localhost:8000/v3/workspaces -H 'Content-Type: application/json' -d '{"name":"hoist-smoke"}' | grep -q hoist-smoke