Deploy

This skill sets hoistable up before it reports hoistable is up

You are about to bring hoistable up from a recipe, not from a finished instance. The skill ships hoistable 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 hoistable 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 hoistable 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 hoistable, or an honest reason it could not, never a silent success.

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

1. Cache / idempotency. If hoistable 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 hoistable'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 hoistable, 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 hoistable. Acceptance transferred N of M on this target. Ready."
• "Built hoistable, but N of M acceptance checks did not transfer here: [the specific checks]."
• "Cannot build hoistable: this target is missing [the named bind or substrate strength]."
• "Reusing the hoistable setup from earlier this session. Ready."

The failure to avoid: reporting hoistable 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)

{
  "_authored_by": "hoist author (self-hosting reference: hoistable's own Layer 2 config)",
  "app": "hoistable",
  "binds": [
    {
      "name": "git",
      "probe": "git --version",
      "required": true
    },
    {
      "name": "python3",
      "probe": "python3 --version",
      "required": true
    }
  ],
  "default_profile": "default",
  "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": {
    "default": {
      "acceptance": [
        {
          "check": "python3 tests/test_author.py",
          "name": "test_author"
        },
        {
          "check": "python3 tests/test_envelope.py",
          "name": "test_envelope"
        },
        {
          "check": "python3 tests/test_hoist.py",
          "name": "test_hoist"
        },
        {
          "check": "python3 tests/test_builder.py",
          "name": "test_builder"
        }
      ],
      "bringup": [
        {
          "name": "no-build",
          "run": "true"
        }
      ],
      "health": [
        {
          "check": "test -e .",
          "name": "clone-present"
        }
      ],
      "isolation": {
        "none": true,
        "why": "hermetic: runs the project's own tests in a throwaway clone; starts no daemons, binds no host ports, writes no shared state"
      }
    }
  },
  "source": {
    "clone": "https://github.com/3dl-dev/hoistable.git",
    "dir": "hoistable"
  }
}

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

• git (required), probe: git --version
• python3 (required), probe: python3 --version
• isolation substrate: none required, this profile is hermetic (hermetic: runs the project's own tests in a throwaway clone; starts no daemons, binds no host ports, writes no shared state).

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 hoistable's own singular deployment onto a live host.
• No silent success. hoistable 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)

• test_author: python3 tests/test_author.py
• test_envelope: python3 tests/test_envelope.py
• test_hoist: python3 tests/test_hoist.py
• test_builder: python3 tests/test_builder.py