Capstone, Lesson 230 min

Deployment on kinto, and staying isolated from production Impulse

Deployment runs under launchd on kinto, exposed via Reception. The pattern is your existing one: a launchd plist runs the process; Reception’s Caddy routes a path to its port with header_up Host localhost, the load-bearing line. Approval and the live panel reach you over Tailscale.

In your codebase

Production Impulse (~/dev/lumiere/apps/impulse) keeps running untouched. v2 is a parallel build under ~/dev/groundschool/builds/m9-impulse-v2, proving the concepts without risking the real heartbeat. The face-to-action mapping mirrors src/actuators/ark-whisper.ts (faceToWhisperRequest -> /impulse-continue | /impulse-personal | /impulse-wild, POSTed to Ark’s /whisper). In v2 the worker subgraph is what runs that action, and the wild face is the one gated by module 5. Sensors and modulateWeights are unchanged from module 3; the parity guarantee you built there still holds. The cold-mode gate (temperature.level === ‘cold’ plus a 5-minute cooldown, src/heartbeat/cold-mode.ts) is the entry condition. Reception (~/focused/reception) is Caddy on :8080 with tailscale serve terminating TLS; a new conf.d/*.caddy snippet routes the v2 panel and approval endpoints.

Practice

Try it yourself

Recall

Where the checkpointer becomes load-bearing for approval

This is the seam where two modules depend on each other. Trace one roll end to end before answering.

Tracing one wild roll through all seven modules, at which point does the module 4 checkpointer become load-bearing for the module 5 approval, and why?

Reveal answer

The checkpointer becomes load-bearing at the moment interrupt() fires and the graph pauses. Without a checkpoint of the state at that exact point, there would be nothing to resume into when your approval decision comes back (possibly much later, from Discord or the panel) -- the pause would just lose the in-flight roll. The checkpointer is what makes "pause now, resume whenever a human responds" survivable rather than instantaneous-or-lost.

Quiz

What keeps v2 isolated from production Impulse

"Runs alongside production Impulse without touching it." What concretely keeps v2 isolated, at the data layer and the process layer?

Av2 shares the production database but writes to different table names
Bv2 replaces production Impulse entirely once deployed
CIsolation is achieved only by running v2 at different times of day
Dv2 is a separate process with its own database and directory, isolated from production Impulse

Show answer

Correct answer: D — v2 is a separate process with its own database and directory, isolated from production Impulse

Process-level isolation (a separate launchd-managed process, not sharing memory or a runtime with production Impulse) plus data-level isolation (its own checkpointer / database, its own directory) means v2 can be built, run, and even break without any path back into the real heartbeat's process or state.

Assemble and deploy Impulse v2

Wire modules 3 through 8 into one running system and deploy it on kinto, without touching production Impulse.

Create the build under ~/dev/groundschool/builds/m9-impulse-v2, separate from production Impulse.
Take the m3 dice StateGraph as the core: sense -> modulate -> roll -> route.
Put an m4 PostgresSaver checkpointer under it, using its own database, not production Impulse's.
Gate the wild face behind an m5 interrupt(), approved from Discord or the groundschool panel before the wild action fires.
Stream the whole run into the learning cockpit using m6's config.writer events and graph.stream.
Dispatch the rolled continue/personal/wild face to an m7 worker subgraph (a createDeepAgent) that executes the action, with Command.PARENT handoff back.
Enable m8 tracing: LANGSMITH_TRACING=true plus wrapAnthropic on the deep agent's SDK calls.
Deploy under launchd on kinto and expose the panel/approval endpoints via a new Reception conf.d/*.caddy snippet.
Run one real autonomous roll end-to-end and confirm it survives a kinto restart mid-roll.

Done whenOne real autonomous roll completes end-to-end (sensed, rolled, approved if wild, executed, streamed, traced), the process survives a kinto restart mid-roll by resuming the same thread, and it runs alongside production Impulse without touching it.

Check

Capstone end-to-end roll verified

Confirm the full assembled system on a real roll.

You should see

One real autonomous roll runs end-to-end through all seven modules, a kinto restart mid-roll resumes rather than restarts, and production Impulse is untouched and unaffected throughout.