Go-live runbook for the first supervised live order - #116
Closed
eaitbrahim wants to merge 1 commit into
Closed
Conversation
The one path never exercised -- place_order against the real API. Written from VERIFIED v0.1.0 mechanics, not memory, and honest about two things the verification surfaced: 1. CONFIRM MODE PLACES NOTHING. The agent loop runs the executor with no confirmation callback, so mode=confirm fails closed. The only mode that places is `bypass`, which needs an armed token AND the authz passphrase gate. 2. NO RULE CAN REACH `live` THROUGH THE GATE TODAY (Turtle fails the 100- trade floor; DCA cannot be backtested). The agent only trades `live` rules. ⇒ on v0.1.0 a supervised single order requires two deliberate out-of-CLI steps: set the authz passphrase (`authz.set_passphrase` -- no CLI command exists), and insert a tiny DCA rule directly at `live` status (`insert_rule(..., status='live')`). Both are called out explicitly. Vehicle: a ~$5 DCA buy (fixed-cadence market buy -> predictable single order, vs waiting weeks for a Turtle breakout), under $15 caps as a second belt. Full rail checklist (subscription attest, withdrawals attest, kill-switch off, USDC funded), arm -> ONE cycle (not --loop) -> verify on Coinbase -> stand down (disarm, kill, mode back to paper, disable the live rule). Framed throughout as a PLUMBING TEST: it proves the order pipe, NOT the strategy (which still fails its own gate). Ends with a recommendation to build `keel set-passphrase` + a gated `keel place-test-order` so the first live order needs no manual DB/security-file editing -- a small PR that would remove the two ad-hoc steps. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This was referenced Jul 20, 2026
eaitbrahim
added a commit
that referenced
this pull request
Jul 21, 2026
Option A: placing a live order no longer requires bypass mode + the arm-bypass token + the dangerous-action passphrase. In confirm mode the agent now shows the previewed order and asks the operator; it places only on an explicit yes. Bypass mode is UNCHANGED and remains the headless path for future autonomous use.⚠️ THE RAILS ARE UNTOUCHED. Every order still runs the 15 hard rails FIRST; the confirmation is an ADDITIONAL human gate after they pass, never a replacement. A test pins that a vetoed order never reaches the prompt (rails run first, confirmation second). The executor was already built for this (`execute` takes `confirm_fn(preview) -> bool`); the agent just hardcoded it to None. This threads a real `confirm_fn` through `run_once`/`loop`/`_handle_exits` (all default None, so every existing caller and test is unchanged and still fails closed), and `keel agent` passes `_interactive_confirm` in confirm mode / None in bypass. `_interactive_confirm` renders the broker preview and prompts; it FAILS CLOSED on a non-TTY (a script/cron never trades unattended), same posture as everything else. Net: placing an order goes from "set-passphrase -> arm-bypass -> --bypass --passphrase" to "run keel agent, answer y" -- and is arguably safer for supervised use, since a human sees the actual order every time instead of pre-authorising a window. Tests: approved->places the BUY (+ its OCO bracket); declined->nothing; no confirm_fn->still nothing (backward compat); confirm_fn sees the preview; a rail veto never reaches the prompt; _interactive_confirm yes/no/non-TTY; the agent command wires _interactive_confirm in confirm and None in bypass. NOTE: the go-live runbook (PR #116, unmerged) still describes the old bypass/passphrase dance and must be rewritten against this once both land. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Contributor
Author
|
Closing: superseded, not rejected. This runbook documents the A rewritten runbook landed in #119 as Anything from here worth keeping is welcome as a PR against that file. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The one path never exercised —
place_orderagainst the real API. Doc-only. Written from verified v0.1.0 mechanics, not memory, and it surfaced two things worth knowing before anyone tries this.What verifying the mechanics revealed
mode: confirmpreviews then fails closed. The only mode that actually places isbypass— armed token + authz passphrase gate.livestatus through the gate today — the Turtle fails the 100-trade floor, DCA can't be backtested. The agent only tradesliverules.⇒ On v0.1.0 a supervised single order needs two deliberate out-of-CLI steps: set the authz passphrase (
authz.set_passphrase— there's no CLI command for it) and insert a tiny DCA rule directly atlivestatus. Both are called out explicitly in the runbook. The safety architecture intentionally has no "just place a test order" button — that's a feature, but it means this can't be a pure CLI recipe.The shape of the test
A ~$5 DCA buy — a fixed-cadence market buy, so you get exactly one predictable order instead of waiting weeks for a Turtle breakout — under $15 caps as a second belt. Full rail checklist (subscription/withdrawal attestations, kill-switch off, USDC funded), arm → one cycle, not
--loop→ verify the fill on Coinbase → stand down.Framing, throughout
It's a plumbing test, not a strategy test. It proves the pipe; it is not evidence the strategy works — the Turtle still fails its own gate. The runbook says so at the top, the bottom, and in the stand-down step ("do not scale up on the strength of a working pipe").
My recommendation, in the doc
Steps 3(a)/3(b) reach around the CLI. For a money operation that's more fragile than it should be. The runbook ends by recommending a small PR first: a
keel set-passphrasecommand (missing today, needed regardless) and a gatedkeel place-test-orderaffordance — so the first live order is a handful of CLI commands with no manual DB or security-file editing. I'd genuinely suggest doing that before the live test.Verification
1258 tests pass (doc-only).
🤖 Generated with Claude Code