Thin daily-live lane LL-3

Date: 27 August 2026

Target live date: Tuesday 15 September 2026

Status: LL-3 code-complete and fail-closed; real trading remains impossible until the owner seals the account-specific rehearsal, graduation, and post-graduation arm evidence described below

Fail closed: the owner-sealed order is mandatory—sizing_approval → rehearsal_receipt → live_graduation → post-graduation arm—and submit also requires a fresh kill-switch daemon heartbeat.

What LL-3 executes

LL-3 retains the LL-2 close-t → next-open path and adds the authority and supervision required before any real order. AlpacaLiveBroker is shared by paper and live; only ALPACA_BASE_URL selects the account. It accepts the canonical Alpaca HTTPS origins on their default ports, sets redirect: error, and rejects live construction unless LIVE_LANE_ARMED is exactly yes. For the live origin, that value is ignored unless one exact sealed live_graduation matches the loaded policy SHA/pin; normal live construction refuses before the graduation’s calendar-derived first session. Planning, daemon startup, and submit additionally require the live arm to be sealed after that graduation. Unit tests inject fetch; the spawned real-CLI seam uses a file-backed 127.0.0.1 fetch transport and opens no socket.

Every submit, paper or live, requires a self-hashed daemon heartbeat no older than twice its recorded interval and bound to the same account, origin, policy SHA, and policy pin. Freshness additionally requires the matching daemon lease to be held by its live PID and fencing token, the latest sealed ledger heartbeat to match the file's exact sequence and hash, and lastDecision:'continue'. submit --live repeats the exact account-bound graduation check after reading /v2/account; constructor-time environment checks are not treated as sufficient authority.

The only production-selectable StrategySpec is momentum-12-1-long-only-v1, pinned to pre-registration rule hash bcf45aad640b041e17f5660225976e20dacc875c536f57f86248959c948ff796. At an exact exchange-calendar month-end it forms on Sharadar SEP US common stocks with unadjusted close ≥ $10 and trailing-20-session dollar ADV ≥ $10m; ranks closeadj(m−1) / closeadj(m−12) − 1 at exact month-end anchors; and equal-weights the long-only top decile. Entry is the next adjusted open, exit the next rebalance adjusted open, and delisting exits at the last observed close. No current TICKERS classification is eligible input. A non-month-end plan cannot recompute the signal: it requires --rehedge-from-plan-hash naming a prior sealed pinned month-end plan and may only re-size that frozen ticker set. The LL-1 fixed-session fixture selector remains test-only and fails the production-strategy assertion.

Plans use exact broker positions. A fractional, short, unexpected, or post-plan changed position is a reconciliation failure, never rounded away. One immutable content-addressed plan is allowed per as-of; a different regeneration refuses, and submit loads the exact stored hash. The receipt binds broker account/origin/mode, the owner-approved arm, the sizing approval, the pinned StrategySpec, and either the current month-end formation or the referenced immutable formation-plan hash. Approved GBP sizing is capped by the pinned policy’s £10k sleeve and per-name 1% ADV limits, converted with the sealed GBPUSD snapshot to whole target shares, and sent as market-on-open opg deltas.

Whole-share implementability is a separate, non-configurable planner assertion. MIN_IMPLEMENTABLE_NAME_FRACTION and MIN_DEPLOYED_FRACTION are exported code constants fixed at 0.90; no environment variable or risk-policy field can weaken them. After computing the unchanged floor(perTickerNotionalUsd / referencePrice) targets, the planner seals these receipt fields:

perTickerNotionalUsd
deltas[].referencePrice
implementability.thresholds.min_implementable_name_fraction
implementability.thresholds.min_deployed_fraction
implementability.metrics.applicable
implementability.metrics.managed_names
implementability.metrics.names_with_qty
implementability.metrics.deployed_fraction       sum(targetQty × referencePrice) / sum(perTickerNotionalUsd)
implementability.metrics.min_price_headroom      min(perTickerNotionalUsd / referencePrice)
implementability.passed
implementability.refusal_reasons

The assertion applies only when the plan intends positive exposure: total intended per-ticker notional is positive and at least one managed name has positive intended notional. An intentionally flat plan records applicable:false, zero names with quantity, deployed_fraction:null, and min_price_headroom:null, and passes without manufacturing a 0/0 refusal. An applicable plan is implementable only when at least 90% of managed names receive a positive whole-share target, at least 90% of intended notional is deployed, and every managed name has price headroom for one share. A failure seals the immutable plan receipt with submitEligible:false, records every applicable reason, and throws PlanImplementabilityError; the plan CLI persists the content-addressed refusal, prints its reason codes and receipt hash, and exits non-zero. No broker call or order submission follows. Because a zero target necessarily has headroom below one, the name-fraction and per-name-headroom reasons may correctly appear together. Broker-side sub-$1 order skipping remains defense in depth, not a sizing mechanism.

Receipt replay recomputes the complete implementability audit and target quantities from the receipt-owned per-ticker notionals and reference prices through the exported planner kernel; stored metrics are never trusted as independent authority. This mandatory replay input cuts the execution-plan receipt to live-lane-execution-plan/v4. Producers, submit, reconciliation, and rehearsal replay accept v4 only; v3 and unknown plan versions fail closed before receipt replay. The 4–11 September paper rehearsal ledger and artifacts must therefore start fresh with v4 plans—do not reuse any earlier v3 plan, submit, or reconciliation chain.

The CLI refuses a second submit event for an as-of date. At the broker boundary it lists open orders and all orders from as-of through the later of execution day and today, refusing any matching ll2-YYYYMMDD- prefix. An ambiguous POST is looked up by deterministic ID: new, accepted, partially_filled, and filled succeed only when symbol/side/qty match; rejected, canceled, expired, and replaced are typed terminal failures; 404 retries the same ID. Submit and every hard action acquire the same account-derived mutation fence. Immediately before every strategy or emergency order POST, while still inside that fence, the broker revalidates lease ownership and re-reads daemon/hard-action kill priority. A kill that gets the fence first prevents the POST; a POST already inside the fence finishes before the daemon seals its kill.

No real order, credential, production database, deployment, or scheduler was used to build or test this packet.

Corporate actions

• Dividend cash requires allowlisted Alpaca DIV/DIVNRA evidence, a broker activity per-share rate, and sealed positive holdings over the ex-date; amount must remain within $0.01 + 0.1% of rate × quantity. DIVNRA is the only explicit debit type. Any linked announcement must match; its identity, the entitlement arithmetic, and the globally unique consumed activity ID are hash-chained before reconciliation, and reuse refuses.
• A split changes expected quantities only when the observed broker position equals the broker record’s exact ratio. Each transform is sealed before drift checks; submit refuses any fetched-but-unapplied action and re-reads positions after transforms before calculating order deltas.
• Split, dividend, and cash-in-lieu evidence uses a canonical hash of each broker row’s semantic fields, so wider date/symbol queries, response ordering, pagination, and unrelated rows cannot change an existing attribution. The whole-response hash remains transport audit evidence only and is never compared across calls.
• Immediately before every strategy-order POST, submit reads positions, then the plan-symbol corporate-action set, then positions again under the account fence. The position quantities must be identical across both reads; any position change, evidence-set/row-hash change, or effective split not reflected in the second adjusted position snapshot refuses without a POST.
• A fractional remainder requires one CIL activity explicitly linked to the split, with cash exactly equal to its broker rate × fractional entitlement. Missing CIL, target-share residue, duplicate evidence, or any nonzero economic residual refuses.
• Reconciliation receipts cut over exclusively to live-lane-reconciliation/v4: paper rehearsals from 4–11 September 2026 use v4 throughout, and daemon/submit reject mixed, legacy, unknown, or broken prior-receipt lineage. Every v4 receipt after the first account/origin receipt binds the immediately preceding v4 receipt hash; there is no legacy acceptance path.
• Accepted residual: a corporate action that becomes effective after submit’s final snapshot but before the OPG fill is not observable pre-POST; the next reconciliation detects the changed broker state and refuses.

Single hard-action coordinator

Every hard source—H1 day loss, H2 drawdown, long-only breach, reconciliation mismatch, fractional/unexpected position, refresh/staleness/calendar failure, or policy expiry—uses risk/executeHardAction. There is no second flatten path.

Before every phase, the coordinator atomically writes <LIVE_LANE_STATE_DIR>/hard-action/<incidentHash>.json. The journal has a canonical self-hash, its sealed disarm event ID, and a monotonically increasing CAS generation. For a reconciliation that observes a same-binding post-submit reset while positions remain, the coordinator first fsyncs a reset-keyed prepared journal containing the exact reconciliation draft, then appends the v4 receipt, and only then starts broker cleanup. Every newly produced v4 receipt explicitly hash-binds postSubmitResetHash as either the exact reset event hash or null. There is no current production lineage-free producer; legacy no-submit v4 receipts remain readable only when the canonical scan from the earliest earlier same-binding submit proves that no reset preceded the receipt and the reset field is absent or null. Restart resumes a prepared state even when the receipt append never happened, and also scans an explicit reset-bound receipt to recreate a missing journal before the ordinary state-file cleanup pass. Receipt replay verifies the field against the exact account/origin/policy reset sealed after submit and before the receipt, so a forged or cross-binding reset hash refuses. Replaying either crash window uses the same incident identity, appends the receipt at most once, and never repeats a completed flatten. All content reads, writes, and buffered broker receipts occur under the account fence; stale-generation writes refuse. Each replacement uses a unique temporary file and rename, retaining .prev. A malformed, forged, or unanchored state is moved to hard-action/quarantine/, seals state_corrupt, remains disarmed, and still runs broker cancellation and cleanup from the trusted ledger/account binding. A completed zero_verified incident is short-circuited and never replayed.

Every CLI command scans phase filenames before doing its own work. The daemon and resume resume those records under the account fence; strategy-advancing commands also resume first and refuse while cleanup remains pending. status --json is strictly read-only: it reports the pending incident from the ledger/journal without attempting broker mutation, changing the journal, or appending a ledger event. Failed ledger appends are buffered in the fenced phase record and retried after broker cleanup and on resume.

The fenced sequence is:

1. Journal disarm_sealed, then append the hash-chained armed:false disarm.
2. Journal cancel_requested, cancel all open orders, and poll with 250ms → 500ms → 1s → 2s → 4s → capped-5s backoff for at most five minutes. Each non-empty poll re-cancels every remaining order ID. Only an empty open-order snapshot proves cancellation; otherwise journal cancel_unproven, retain hard_action_pending, and still flatten current longs.
3. Snapshot account and exact broker positions.
4. Seal an incident containing the trigger, policy file SHA and operator pin, intended positions, broker positions, open orders, watermark, and snapshots. The matching loaded thresholds are included when available; receipt-only recovery after a policy rotation preserves the historical SHA/pin and records thresholds:null plus historical_policy_snapshot_not_sealed instead of falsely attributing the current thresholds.
5. Re-read the complete broker position and all-order sets. One flattenGate(symbol) controls every emergency POST. It first requires every earlier emergency order for that symbol—BUY or SELL—to be individually GET-proven canceled, filled, expired, or rejected; absence from an open-order response is not terminal proof. After cancel_unproven, an outstanding non-emergency OPG BUY does not block flattening an already-long position because a late fill can only create another long for the pending cleanup to remove. Outstanding non-terminal non-emergency SELL leaves are subtracted exactly: flattenQty = currentLongPosition − sum(sellQty − filledQty), clamped at zero, so the emergency SELL can never over-sell. Open orders are read before the exact position immediately preceding POST, and the durable hard_action_pending latch remains set until a later resume proves cancellation and two stable zero snapshots. Thus a short-cover BUY can never overlap a still-live emergency SELL, and a replacement SELL can never race a late predecessor fill across zero. A negative position is itself short_detected and is covered with an exact market BUY to zero; the coordinator remains disarmed and repeats until flat. Fractional emergency quantities remain exact. This emergency action works on the already-constructed configured paper or live origin.
6. Require two consecutive complete snapshots, at least two seconds apart, with both zero positions and zero open orders. Each snapshot also seals fills plus all-order activity; any new order, fill, quantity/status change, long, short, or open order resets proof. Only then journal zero_verified and seal flatten_complete; otherwise seal flatten_incomplete, remain disarmed, and resume later.

Cancellation, snapshot, flatten, or post-broker submit-receipt persistence failures are recorded only as {class,status,code}. They do not re-arm the lane. Operational-ledger writes use an atomic populated lock with bounded contention retry and same-host dead-PID recovery, so a transient or crash-stale ledger writer cannot prevent the coordinator’s first sealed disarm.

Normal ledger-lock release is always contention, never corruption: a contender that observes EEXIST and then receives only ENOENT from its single lock-record read retries through the existing bounded path, while any present malformed record or other read failure remains fail-closed and expiry/dead-PID recovery is unchanged. The operator sees no corruption incident for an ordinary owner release; persistent contention still reports trial ledger is locked, and a present malformed record still reports trial ledger is locked by an invalid lock record.

Once a submit receipt is durably sealed, reconciliation authority comes from the immutable owner-approved arm→plan→submit lineage for the exact policy, account, origin, and broker mode, not from whether that arm is still current. A later disarm therefore does not strand the accepted broker side effect: reconcile still seals its v4 receipt and, when positions remain, invokes the same hard-action/flatten coordinator; it never re-arms and cannot authorize another submit. Any later re-arm requires a new matching owner approval sealed after the most recent same-account disarm or hard kill; an older approval cannot cross that authority epoch. The operator sees the earlier disarm followed by the lineage-bound reconcile receipt, remains disarmed in status --json, and sees any unresolved flatten work in pendingHardActions; a new submit continues to refuse on the unresolved disarm without another broker POST.

Policy authority and expiry

There is no static live-risk policy object. LIVE_LANE_RISK_POLICY_PATH is the sole threshold/sizing authority. The loader requires LIVE_LANE_RISK_POLICY_SHA256 and refuses when the raw file SHA-256 differs. Every operational event records both riskPolicySha256 and riskPolicyPinnedSha256.

The checked-in fixture keeps fixture_only:true. It is accepted only with a loopback broker origin in offline tests; both paper-api.alpaca.markets and api.alpaca.markets reject it.

Session age is never a CLI option and never uses plan as-of. A valid arm references an earlier owner approval event hash with approvedBy:'owner' and the same policy/account/origin. Refresh seals the exact ordered session vector and hashes from two independent sources: Alpaca calendar and distinct dates in the verified Sharadar SEP DuckDB read model, plus the SEP manifest hash. The two sets must agree from arm through the last completed NYSE session at invocation—not the UTC calendar date—and across the 60-session overlay window. Later invocations re-read both sources and refuse/disarm on any omission, disagreement, stale/truncated range, duplicate, impossible, or unordered row. At sessionsSinceArm >= thresholds.operational.valid_sessions_from_arm, the coordinator disarms and flattens.

Sizing approval and volatility overlay

A submit-eligible plan must bind the hash of a sealed sizing_approval event containing:

stageBp
targetGbp
navSnapshotGbp
gbpUsdSnapshot
riskPolicySha256
riskPolicyPinnedSha256
approvedBy
brokerAccountIdHash
brokerOrigin                         paper or live
armEventHash
validFrom / validTo                 inclusive, at most five exchange sessions
navSnapshotAt / gbpUsdSnapshotAt    ISO timestamps, at most one completed session old
priorStageReviewReceiptHash         required for 25/50 bp progression

Only stages 10, 25, and 50 bp exist. The first sealed approval for one account/strategy is 10 bp. Progression is exactly 10→25→50, never lateral, backward, repeated, or skipped; each later approval references an earlier sealed owner-approved stage_review for the immediately prior sizing approval. Without a valid approval, plan may create only a submitEligible:false dry run from explicit --stage-bp, --target-gbp, --nav-gbp, and --gbpusd values. submit refuses it.

The planner, not the CLI caller, applies the preregistered overlay:

scale = min(1.0, thresholds.sizing.volatility_target_annualized / annualised realised volatility)

Volatility uses exactly the strategy’s own preceding 60 completed exchange sessions, strictly before plan as-of. Live sessions come only from sealed EOD daily-NAV reconciliation. Earlier incubation sessions come only from simulate-window --asof <arm-date>, which invokes the canonical daily portfolio kernel—not a second simulator—on the sealed Sharadar read model for the 60 sessions preceding arm. That kernel carries the month-end portfolio from adjusted open to adjusted close, marks overnight gaps before rebalance, charges the frozen 10/25-bp per-side turnover costs, and moves a delisted holding to cash at its last observed close. The command seals one simulated_daily_return per session; every receipt binds the arm, exact refresh receipt/manifests, policy SHA/pin, and StrategySpec hash. As live sessions accrue, their validated realised receipts replace the same-session simulation in the exact window.

The real daily-NAV path reads the actual wall clock and refuses to seal before the exchange calendar’s close for that exact session. It therefore uses 13:00 America/New_York on an attested early-close day rather than assuming 16:00; a deterministic clock seam exists only for loopback tests. Every realised overlay input is an unscaled decimal USD sleeve return: accountNetPnlUsd = endingNavUsd - startingNavUsd, unscaledNetPnlUsd = accountNetPnlUsd / priorVolatilityScale, and unscaledNetReturn = unscaledNetPnlUsd / unscaledSleeveNotionalUsd. H1/H2 separately use actual account return, (endingNavUsd - startingNavUsd) / startingNavUsd, rather than inverse-scaled return.

Each realised daily receipt binds the prior plan hash, post-open reconciliation hash, prior scale, both scaled and unscaled sleeve notionals, non-negative USD costs, currency:USD, and netOfCosts:true; readers recompute both formulas.

An absent session during incubation is not a data failure, but it makes volatilityWindowComplete:false, records incubation_incomplete_dry_run, and forces submitEligible:false; submit refuses. An existing malformed, duplicate, non-finite, wrongly bound, or non-session receipt is a data failure routed through the coordinator. No path may emit NaN or infinity. On or after 2022-01-01, simulate-window additionally requires the hash of a sealed owner-only lockbox_opened event. That event must exist by Thursday 3 September so the plan for Friday 4 September can be sealed after the 3 September close; the Q12 amendment remains pending owner ratification.

The resulting complete-window source is sealed_simulated_and_realised_60_session_lag, and the scale is exactly min(1, target / annualised volatility).

The target must remain within sleeve_cap_gbp and navSnapshotGbp × stageBp / 10,000. Each per-name USD target exposure—not merely the order delta—must remain within adv_participation_cap × trailing ADV20 USD.

Account-scoped lease and broker fence

LIVE_LANE_STATE_DIR is required, absolute, and mode 0700. The submit lease path is derived only as:

LIVE_LANE_STATE_DIR/leases/<sha256(/v2/account.id)>.lease

--out, --lease, and a lease-path environment variable cannot select it. Expiry alone never authorizes takeover: guarded replacement is allowed only when the expired same-host PID is provably dead. The fencing token is local: Alpaca receives only deterministic client_order_id; the token remains in audit receipts and ownership is revalidated immediately before every POST. The file implementation protects schedulers sharing one host/state directory; a DB-backed cross-host fence remains interface-compatible future work.

Every CLI command, including the fixture-era commands, requires and scans this state directory before command work. Cleanup-only live construction requires a verified sealed-disarm ledger anchor for the configured origin before it can bypass ordinary arming; the pending journal is then read only under that anchor's account fence. A reachable /v2/account must match the anchored account before any broker mutation; if the account endpoint is unreachable, the coordinator remains disarmed and attempts only the required resumable cleanup operations. With no matching incident the constructor refuses, and cleanup-only mode cannot submit strategy orders. status --json may use this broker only for allowlisted reads; it never resumes cleanup, seals a receipt, or re-arms the lane.

Data refresh and freshness

refresh calls the existing verified runSharadarIngestCli path for SEP, ACTIONS, and TICKERS, drains verifyTableManifest for all three, records their manifest hashes, and rebuilds only changed DuckDB partitions. Only verified SEP.lastDate is the market-data watermark. More than one completed exchange session after it is a data failure.

Calendar rows use the one lib/live-lane/calendar/ authority for real ISO dates, strict ordering, windows, preceding/next-session selection, snapshot age, and Alpaca↔SEP attestation. Malformed, duplicate, unordered, missing, or source-disagreeing rows are failures routed through the hard-action coordinator; they are never filtered or silently sorted. Snapshot age counts sessions strictly after the last session completed at the snapshot time: a Friday pre-open NAV/FX snapshot used after Monday close is two sessions old (Friday and Monday).

Dependency files are frozen and this checkout has no DuckDB package or executable. Operators must provide an external DUCKDB_BIN; refresh otherwise fails closed and coordinates any existing exposure.

Zero-trial implementability diagnostic

Before approving a live NAV, run:

node scripts/live-lane-implementability-diagnostic.mjs --nav-usd 12700 --leverage 0.428

This command imports and calls the frozen registered momentum selector; it does not duplicate the rule. It reads ~/.local/share/tradegg/sharadar/research/sharadar.duckdb in DuckDB read-only mode, uses memory_limit='4GB', threads=4, and a temporary directory capped at 3GB, and refuses before database access unless df -Pk reports at least 10 GiB free. SEP and ACTIONS reads are hard-capped at 2021-12-31; TICKERS supplies only current scalemarketcap diagnostic metadata, never eligibility. The first 11 screening month-ends are explicitly unavailable because the local SEP history cannot supply the frozen 12-month anchor. No trial-ledger or lockbox row is read or written, no model is called, and no broker or network authority exists.

For every available screening month the JSON looks report records intended names, names with quantity at least one, deployed-capital fraction, minimum price headroom, price tilt, current-scalemarketcap tilt, and the exact USD-cent minimum NAV. It calls the planner's exported implementability kernel, so its verdict and minimum enforce the same 90% name gate, 90% deployment gate, and all-name one-share price-headroom gate. The calculation enumerates whole-share pass intervals and does not assume deployment fraction is monotone. Calendar month ends and anchors come from the canonical live-lane calendar helpers, and report hashing comes from the canonical hash helper. The content-addressed JSON and companion Markdown summary are created under ~/.local/share/tradegg/live-lane/diagnostics/.

Required configuration

Never print or place values in ledger payloads.

ALPACA_KEY_ID
ALPACA_SECRET
ALPACA_BASE_URL                       https://paper-api.alpaca.markets or https://api.alpaca.markets
ALPACA_DATA_BASE_URL                  optional canonical data origin
ALPACA_DATA_FEED                      defaults to sip
LIVE_LANE_ARMED                       exactly yes; live only, and never sufficient without graduation
LIVE_LANE_RISK_POLICY_PATH            owner-ratified event JSON
LIVE_LANE_RISK_POLICY_SHA256          independently pinned raw-file sha256
LIVE_LANE_STATE_DIR                   required absolute mode-0700 shared state
LIVE_LANE_OWNER_ID                    scheduler/operator identity
LIVE_LANE_SIZING_APPROVAL_EVENT_ID    sealed sizing_approval id for submit-eligible plans
LIVE_LANE_DAEMON_INTERVAL_SECONDS     optional positive integer; defaults to 30
DUCKDB_BIN                            operator-installed DuckDB CLI

Dry-run-only planning additionally accepts LIVE_LANE_DRY_RUN_STAGE_BP, LIVE_LANE_DRY_RUN_TARGET_GBP, LIVE_LANE_DRY_RUN_NAV_GBP, and LIVE_LANE_DRY_RUN_GBPUSD.

CLI

node scripts/live-lane.mjs refresh --ledger "$LEDGER" --out "$ARTIFACTS" --database "$DUCKDB"
node scripts/live-lane.mjs simulate-window --asof "$ARM_DATE" --ledger "$LEDGER" --out "$ARTIFACTS" --database "$DUCKDB" --lockbox-opened-event-hash "$LOCKBOX_OPENED_HASH"
node scripts/live-lane.mjs plan --asof 2026-09-10 --ledger "$LEDGER" --out "$ARTIFACTS" --database "$DUCKDB" --unlock-event-id "$UNLOCK_EVENT" --sizing-approval-event "$SIZING_APPROVAL" --rehedge-from-plan-hash "$AUG31_FORMATION_PLAN_HASH"
node scripts/live-lane.mjs submit --paper --asof 2026-09-10 --ledger "$LEDGER" --out "$ARTIFACTS"
node scripts/live-lane.mjs reconcile --asof 2026-09-10 --ledger "$LEDGER" --out "$ARTIFACTS"
node scripts/live-lane.mjs drill --ledger "$LEDGER" --out "$ARTIFACTS"
node scripts/live-lane.mjs rehearsal-receipt --from 2026-09-04 --to 2026-09-11 --ledger "$LEDGER" --out "$ARTIFACTS"
node scripts/live-lane.mjs live-graduation --effective-from 2026-09-15 --sizing-approval-event-hash "$LIVE_SIZING_HASH" --rehearsal-receipt-event-hash "$REHEARSAL_EVENT_HASH" --owner-approval-reference "$OWNER_LIVE_APPROVAL_HASH" --ledger "$LEDGER" --out "$ARTIFACTS"
node scripts/live-lane.mjs resume --ledger "$LEDGER" --out "$ARTIFACTS"
node scripts/live-lane.mjs status --json --ledger "$LEDGER" --out "$ARTIFACTS"
node scripts/live-lane-daemon.mjs --ledger "$LEDGER" --out "$ARTIFACTS" --interval 30
node scripts/live-lane-implementability-diagnostic.mjs --nav-usd 12700 --leverage 0.428

plan writes dryRun:true into a content-addressed artifact plus an immutable as-of reference. Its one-plan-per-as-of decision is check-and-append atomic inside the same exclusive ledger lock: a concurrent loser receives the winner hash and cannot overwrite either artifact. submit requires the exact stored event payload and artifact hash, approval, account/origin/mode/arm, unchanged positions, no earlier submit event, a ledger-sealed refresh receipt, the account fence, and a clear full-execution-window broker fence. Reconciliation follows the loaded any_failure_kills policy exactly; no CLI or environment tolerance can weaken fill, position, or cash comparisons.

The acceptance seam launches the real CLI and daemon with child_process.execFile against a file-backed loopback-only Alpaca fetch router. It covers accepted-after-timeout recovery and rejected-after-timeout typed failure with exactly one POST, healthy daemon heartbeat creation, an H1 marked-equity breach, durable pending cleanup, submit refusal, daemon-start resume, and two-zero completion. It binds no socket and has no skip path.

Paper dress rehearsal — execution sessions 4 and 8–11 September

Use a dedicated empty paper account. The fixture policy is forbidden.

The execution window is Friday 4 September and Tuesday 8 through Friday 11 September. Saturday 5 September is not an NYSE session and is never counted; Monday 7 September is the Labor Day holiday. A rehearsal session is the execution session whose post-open reconciliation completed, while its plan and paper submit are sealed after the immediately prior attested session's close. The receipt is sealable only after the 11 September reconciliation.

1. By 3 September — custody and lockbox. Install and independently pin DuckDB, create the shared mode-0700 state directory, pin the merged owner risk event via both path and SHA, set the paper origin, and verify the dedicated paper account is empty. Append the account-specific owner approval and paper arm, run refresh, check all three manifest hashes plus the exchange-calendar attestation, and seal the owner-only lockbox_opened event no later than 3 September. Start the daemon before any paper submit and alert if its live lease or PID disappears, its file or matching sealed heartbeat exceeds twice the interval, or status --json reports fresh:false.
2. Prior-session plans; executions 4 and 8–11 September. After each immediately prior close, seal the plan and paper submit for the next execution: plan on 3 September for execution on 4 September; on 4 September for 8 September; on 8 September for 9 September; on 9 September for 10 September; and on 10 September for 11 September. Reconcile after each execution open. Each chain must be exactly plan→submit→matched reconcile for the same account/origin/policy with all event and receipt hashes cross-bound. Run simulate-window --asof <arm-date> and verify exactly 60 finite hash-bound receipts. The first approval is 10 bp; 25/50 bp remain unavailable without their separate prior-stage review receipts.
3. Hard-kill drill. Run drill on the paper account. It injects a synthetic hard-kill decision into the same coordinator used in production, never a mock flatten path. The drill is acceptable only when its sealed flatten_complete proves cancellation and two consecutive zero position/order/activity snapshots at least two seconds apart.
4. Failure evidence. Exercise cancel-unproven restart, generation-CAS recovery, .prev quarantine, ambiguous POST outcomes, calendar disagreement, stale heartbeat refusal, and account/origin mismatch. Resolve every incident; a hard_action_pending without its later matching flatten_complete makes the rehearsal receipt impossible.
5. After the 11 September post-open reconciliation — seal. Stop neither the evidence chain nor the daemon. The sealer re-derives all five chains from canonical ledger receipts, computes heartbeat coverage only from monotonic lease-bound per-tick ledger heartbeats, and verifies the drill against the actual hard-action state file plus disarm→incident→two-zero hashes. Verify zero unresolved incidents and at least 95% coverage of all attested execution-session minutes. Run rehearsal-receipt --from 2026-09-04 --to 2026-09-11; record its event and receipt hashes. Any missing or unverifiable link refuses with its reason. Seal live_graduation no earlier than 12 September; its effective date and first session remain 15 September.

Any missing approval/arm, unexpected or fractional position, prior submit, broker-prefix collision, stale/malformed data, policy mismatch, lease conflict, incomplete flatten, or failed gate is a refusal.

15 September live arming

The owner-sealed order is mandatory: sizing_approval → rehearsal_receipt → live_graduation → arm. The chain order is checked, not inferred from filenames or timestamps.

1. Prepare live authority while disarmed. Independently verify the real owner-policy bytes; export LIVE_LANE_RISK_POLICY_PATH, its raw-file LIVE_LANE_RISK_POLICY_SHA256, the absolute mode-0700 LIVE_LANE_STATE_DIR, ALPACA_KEY_ID, ALPACA_SECRET, ALPACA_BASE_URL=https://api.alpaca.markets, and the canonical data origin if explicitly configured. Do not set LIVE_LANE_ARMED yet. Never use the checked-in fixture policy.
2. Seal stage 10 first. Append the owner’s live sizing_approval for the SHA-256 of the actual /v2/account.id, brokerOrigin:'live', stage 10 bp, fresh NAV/GBPUSD snapshots, and the required validity window. Its armEventHash is null because the arm must not precede graduation. Record the sealed event hash.
3. Bind rehearsal and owner approval. Use the verified rehearsal_receipt event hash from the five paper sessions. Append approve_live with approvedBy:'owner', the exact https://api.alpaca.markets origin, live account hash, and current policy SHA/pin. Record its event hash.
4. Seal graduation through the read-only bootstrap. Run live-graduation --effective-from 2026-09-15 with the sizing, rehearsal, and owner-approval event hashes. The receipt binds the raw policy SHA and operator pin, strategySpecHash, pre-registration rule hash, sizing approval hash, rehearsal event and receipt hashes, live account hash and canonical origin, owner reference, effectiveFrom, and the first Alpaca calendar session on or after it. A missing, malformed, reordered, wrong-account, wrong-origin, pre-10-bp, pre-15-September, or unverifiable dependency refuses.
5. Arm only after graduation. Append arm after the live_graduation, with armed:true, approvedBy:'owner', the same live account/origin/policy identity, and the sealed owner-approval event hash. A pre-graduation arm cannot authorize planning, the daemon, or submit. Then export LIVE_LANE_ARMED=yes; the value still has no effect before the graduation’s first session.
6. At or after 00:00 America/New_York on 15 September, before the open. Run live refresh, then start scripts/live-lane-daemon.mjs. Wait for a fresh account-bound heartbeat and confirm status --json shows the expected policy SHA/pin, stage 10, live account, current arm, calendar attestation, refresh manifests, zero pending hard actions, and daemon.fresh:true. Run plan --asof 2026-09-14 --rehedge-from-plan-hash <sealed-August-month-end-plan-hash>; it may only resize the frozen formation set. This after-midnight window is deliberate: ordinary live commands refuse on 14 September, while the 14 September close is the last completed session before the 15 September open.
7. Submit once. Run submit --live --asof 2026-09-14 only while the daemon heartbeat is fresh, then reconcile immediately after the open. Any H1/H2/H4, stale-data, calendar, account-origin, or coordinator integrity trigger disarms and runs the same hard-action path. At sessionsSinceArm >= valid_sessions_from_arm, it also disarms and flattens.

No evidence may be backfilled after the arm. If the narrow pre-open preparation window is missed, do not move effectiveFrom, fabricate a session, or bypass the heartbeat; seal a new owner-authorized graduation for a later actual exchange session.

Daemon operation and alerts

• Start: run exactly one supervised node scripts/live-lane-daemon.mjs --ledger "$LEDGER" --out "$ARTIFACTS" --interval 30 for the account. It owns a distinct daemon lease under the same account fence, validates the policy pin, account/origin, sealed refresh, arm, graduation when live, and Alpaca↔Sharadar calendar attestation, and resumes any durable pending hard action before monitoring.
• Loop: every interval it reloads and revalidates the policy pin, current arm/graduation, exchange calendar and attestation horizon, sessionsSinceArm, sealed refresh, and current SEP data horizon; then reads hard-action state and polls allowlisted account, positions, open orders, and latest-trade fields. It marks positions with the data API’s last trade; evaluates H1 intraday day loss, H2 ledger-derived high-water-mark drawdown, H4 short/buying-power/trading-blocked state, and data freshness; writes atomic self-hashed daemon-heartbeat.json; and seals the exact same monotonic, lease-bound heartbeat to the ledger on every tick.
• Stop: send SIGTERM or SIGINT and wait for clean exit. A stopped daemon does not preserve trading authority: after twice the recorded interval, every submit refuses. Do not delete its heartbeat or lease files to manufacture freshness.
• Breach/startup failure: a risk breach or any per-tick pin, calendar, graduation, account-origin, or data-horizon drift acquires the account fence, persists a non-continuing heartbeat, invokes executeHardAction, and exits non-zero. If a heartbeat-ledger append fails, its draft is buffered in the durable phase file before cleanup continues. The coordinator disarms and flattens when the lane was armed; a startup failure before any arm remains a sealed disarm without strategy authority. A pending incident is resumed on the next daemon start and the process remains non-zero/disarmed after that recovery pass so the operator must review it.
• Alerts: the supervisor must alert on any non-zero exit, missing process, heartbeat age over 2 × interval, daemon.fresh:false, pending hard actions, policy/pin drift, calendar failure, or flatten_incomplete. Page the operator; never auto-arm or auto-restart into strategy submission. The operator verifies a matching flatten_complete with twoConsecutiveZeroSnapshots:true before considering a later owner re-arm.

What the operator sees in status --json

LiveLaneStatusSnapshot is read-only with respect to the broker and ledger: it uses a GET-only no-append client and never resumes or seals. It exposes ledger-armed state and arm hash; current policy SHA/pin; ladder stage; account NAV, gross exposure, and net exposure; today's execution-session plan/submit/reconcile hashes; daemon sequence, timestamp, age, interval, freshness and exact refusal reason; pending-hard-action count; exchange-calendar attestation horizon and hashes; and the last sealed refresh receipt, latest SEP date, and all three manifest hashes. A successful read atomically caches a self-hashed last-known account/position snapshot. During broker outage the command still exits zero and renders broker.status:'broker_unreachable', stale:true, the cached snapshot time/age, and cached values when valid. armed:true never overrides daemon.fresh:false or a non-zero pending count; submit enforces the stricter state.

Boundary and residual scope

The frozen-estate test scans TS/JS/CommonJS/ESM/JSON and tsconfig aliases. It fails closed on any createRequire, Jiti, or dynamic import() reference outside the two explicit CLI loader files, and still rejects module.require, process.getBuiltinModule, every frozen-root string literal, and network-capable imports outside the Alpaca execution adapter. Timestamp-to-session conversion is grep-guarded across all of lib/live-lane and both scripts into the one lib/live-lane/calendar/ authority.

The daemon lease and account mutation fence are host-local file authorities. Cross-host active/active operation remains unsupported; run one daemon and one scheduler against one shared mode-0700 state directory on the same host.