# Deployment and handoff: operator sample

Internal repo artifact · Inspired by Frustration · 2026-10-21 snapshot

Source commit: `c9cd4790e42c99b35eed3731bd2c6a5a44c941d8`

Not a client outcome or a model-quality benchmark.

These are real source extracts from our own application. No customer data, credentials or generated screenshots are included. Checksums identify the complete source files at the snapshot; excerpts below are unmodified.

## What to inspect

Our release recipe promotes a prebuilt image after migration and secret sync. The deploy stage names the public smoke URL and the API version URL. Deck reconciliation and edge-cache purging follow deployment. The internal release documentation also names the recovery route for a failed project-data snapshot.

## Receiving-engineer checklist

This checklist is an explanatory handoff sample derived from the controls below; it is not a signed record of a customer handover.

1. Know the two application boundaries and the one combined release image.
2. Identify the release commit and artifact in Agentic Pipeline; the required PR check is the Agentic Pipeline check.
3. Inspect the smoke and version checks and the post-deploy reconciliation/purge results. A merge check alone does not establish live behavior.
4. Exercise the changed customer workflow and compare it with the agreed acceptance criteria.
5. On a project-snapshot failure, diagnose the API or payload and rerun the normal artifact build after recovery. Do not bypass the capture by writing database rows.
6. Record the owner, remaining risks and live verification before the receiving engineer takes over. A real handover also needs a walkthrough and an observed recovery exercise.

## Limits

This is configuration and an operator sample, not an executed deployment report, a rollback rehearsal or proof that a customer team has operated the system. The referenced platform driver implements the smoke checks outside this repository; the excerpt only proves which URLs this recipe supplies. No release credentials, vault identifiers or customer inputs are included.

## Source extracts

Source: `.slipstream-deploy.json`
SHA-256: `3f3a475649cfcd72eb7ec083381ec833531e4db2ea3e3fb727a65511e6b1c62a`

```json
    {
      "name": "deploy",
      "cmd": "bash /app/drivers/native-fly-deploy.sh",
      "env": {
        "SMOKE_URL": "https://inspiredbyfrustration.com/",
        "SMOKE_VERSION_URL": "https://api.inspiredbyfrustration.com/api/version"
      },
      "needs": [
        "secrets-sync"
      ],
      "timeout_s": 180,
      "if_changed": [
        "apps",
        "packages",
        "scripts",
        "content",
        "supabase",
        "public",
        "docker",
        "Dockerfile",
        "Dockerfile.prebuilt",
        ".dockerignore",
        "fly.toml",
        "bun.lock",
        "package.json",
        "turbo.json",
        ".npmrc"
      ]
    },
```

Source: `docs/ACTIONS.md`
SHA-256: `d5116907b1582500e4a95dd6ff807bcacb77ce651093a9469982d24df49a38d6`

```text
**Project snapshot (HO-18779, 2026-10-18):** the artifact build must run through `bun run build:artifact -- turbo run build …`. Before Turbo hashes or restores anything, the runner captures and validates `https://api.inspiredbyfrustration.com/api/projects` within 10 seconds (headers and body), 5 MiB and 100 rows. Capture errors, empty/incomplete/malformed payloads and exceeded limits stop the release before packaging; there is no previous-file or bundled-fixture fallback. Only the marketing task hashes the snapshot digest; its list, detail and static-parameter reads consume those same verified bytes, while runtime reads retain API behavior. This represents current published API state, including its cache behavior, not transactionally latest database state. On capture failure, diagnose the API or payload and rerun the normal artifact build after recovery; do not bypass it with manual database writes or revalidation. Guard: `scripts/project-build-snapshot.test.mjs`.
```