How to use it, and what to do when it pushes back

QThe Q2-2026 filing landed on 14 August. What exactly should I do?

This is the moment the whole system exists for, and the sequence is short. Do it during US market hours (9:30–16:00 New York), because prices outside them are stale and the plan will refuse to build.

1. Check that the cloud saw it. On the dashboard, the Filings table should show Q2-2026 with the filed date, and you should have received a "filing detected" push notification. If neither is true, the watcher missed it — see watcher silence.
2. Read the targets before anything else. Book against targets now shows the new target weights next to what you hold. Ask the boring questions: how many names, does the top name look right, did anything drop to cash for lack of a ticker (Capital not deployed lists it). Locally, hr-targets writes and prints targets/Q2-2026.json with every excluded line and its reason; commit that file — CI re-derives it from the archived filing and fails if a byte differs.
3. Check that nothing is blocking. Reconciliation should say "no unresolved breaks". The rail should not say HALTED. If a break is open, resolve it first (how) — planning is refused while one exists, by design.
4. Build the plan with the Build rebalance plan button. This reconciles, snapshots equity, prices and validates every name, runs the risk engine, journals the plan, and shows you the preview with a fingerprint and a 20-minute clock. If every order was blocked, the button tells you so; that is a normal outcome, and the ledger shows which rule bound.
5. Read every line of the preview. Side, quantity, limit price, notional, and the risk tag on each. Look at the House limits gauges — expect the basket cap to be close. If anything surprises you, press Discard; nothing has been sent and nothing will be.
6. Type the phrase — CONFIRM REBALANCE Q2-2026, exactly, by hand (paste is refused) — and press Confirm. Submission, settlement and reconciliation run in one request; the result line tells you what filled and whether reconciliation was clean. You will also get push notifications at each stage.
7. Read the result. "reconciliation clean" means the cycle is complete and — for the first time — the web gate has run end-to-end in one go, which is the exit criterion for retiring the laptop's scheduled jobs. "found breaks" means read the break procedure and do not build another plan until it is clean.
8. Afterwards: the plan status on the gate card should read submitted. Press Recompute so the analytics panels reflect the new book. Expect the 10:00 "autonomy disabled — a cycle is queued" notification to keep arriving every weekday until you clear the queue (see why).

QWhy do I get a notification every weekday at 10:00 saying "autonomy disabled — a cycle is queued"?

When the watcher detects a filing it writes a queue document (ops/pending_cycle). Every weekday at 10:00 the autonomous job looks at that queue; because autonomy is not armed, it sends that notification instead of trading, and it will keep doing so — even after you have rebalanced through the web gate, because the web gate does not clear the queue. To stop the reminder, delete the ops/pending_cycle document in the Firebase console (or arm autonomy, which you should not do yet — see Autonomy). This is a small wart worth fixing in code; until then, treat the reminder as harmless.

QWhat am I looking at when I sign in?

A single page called the house ledger. It reads a handful of Firestore documents that Cloud Functions write, and it redraws live when they change. It holds no broker keys and cannot place an order by itself; the only things on it that can move toward a trade are the two buttons in The gate, and both call server functions that re-check who you are.

QWhy do I have to sign in with Google?

Because the page shows account equity and positions. Reading requires a signed-in, email-verified Google account on a hard-coded allowlist — Firestore's security rules enforce it, and every callable function enforces it again on the server. "Signed in with Google" alone is not authorization; only the allowlisted address gets data. About and FAQ (these pages) are static and public because they contain nothing about the account.

QWhat is the difference between "paper" and "live"?

A paper account is a simulator run by a real broker (Alpaca): real prices, real order acceptance and fills, a real account balance that goes up and down — but no actual money. Live means real dollars. This system only knows how to talk to paper. The line paper=True is written into the broker adapter; asking for live is refused rather than quietly running paper.

QIs any real money at risk right now?

No. Not one dollar has ever been placed by this system, and it is not currently capable of doing so. See what has to be true first.

QIf it is a robot, what does it need me for?

Four things, in decreasing order of frequency: reading (the dashboard, once in a while, and every alert), confirming (typing the phrase once a quarter, unless autonomy is armed), resolving (a reconciliation break, a tripped breaker, a stale-data halt — each has a runbook procedure and none is a "just retry"), and deciding (a rule change, a funding decision, whether the strategy continues — one written decision per quarter, at most one rule change).

QWhat should I be doing day to day?

Almost nothing, and that is the point. The scheduled jobs snapshot equity every weekday after the close, poll EDGAR every evening, recompute the panels, and a watchdog checks that they did. Your daily job is to notice alerts. If your phone is subscribed to the ntfy topic you will hear about anything that matters; if it is not, alerts reach nobody, which is a working system but a silent one — subscribe.

QWeekly?

Open the dashboard once. Look at three things: the House limits gauges (is anything critical?), the top of the page (does the equity number look like today's, and is the rail free of HALTED and heartbeat warnings?), and Book against targets (has anything drifted more than a couple of points?). Drift is information, not a call to action — the strategy rebalances quarterly, and a drift alert is deliberately "alert, no trade".

QQuarterly?

Around the 45-day mark after each quarter end (mid-February, May, August, November) the rail shows window OPEN and the watcher starts polling. Our filer files late in the window, so there is no point watching hard early. When the filing lands: run the playbook above. After the cycle: run the review ritual — read the tear-sheet (hr-tearsheet --open), autopsy the worst decision, change at most one rule, write it down. One variable per cycle; revert it next cycle if it did not help.

QShould I use the dashboard's gate or the command line to rebalance?

The dashboard. It runs the identical cycle (same build_plan, submit_plan, reconcile functions) against the cloud journal, which is the system of record for the paper account now. The terminal path still exists and still works against its own local journal, but that journal is permanently behind for this account, so using it would be trading against a wrong picture. The command line remains the right tool for everything that does not trade: targets, backtests, tear-sheets, the risk demo, tax reports.

QShould I still run hr-targets locally if the cloud computes targets?

Yes. The cloud writes its own copy to Firestore, but the committed targets/<quarter>.json is the artifact CI verifies byte-for-byte against the archived filing, and it is the one that survives if the cloud project ever disappears. Both are computed by the same code from the same archived documents; if they ever disagreed that would itself be the finding.

QThe equity number does not match what the Alpaca app shows. Which is right?

Both, at different times. The dashboard shows the last recorded snapshot — normally 16:30 New York time on the last weekday, or the moment you last pressed Refresh. It is not a live tick. Press Refresh to snapshot now; the timestamp in the rail tells you how old the number is.

QWhat are the gauges under "House limits"?

Each is one rule, drawn as "how much of it is spent" against a hard stop at the cap, so "how close" is visible rather than inferred. There are up to four: the largest position against the 25% single-name cap; invested — the share of equity at risk in the market — against the 80% basket cap, because on this book the whole set of positions is effectively one correlated basket; drawdown from the high-water mark against the 25% breaker, which only appears once an equity history exists to measure against; and planned turnover against 100%, which only appears when a plan carries one. A gauge turns red when a rule is at or past its cap. Expect the invested gauge to live near the cap — that is what a concentrated AI-infrastructure clone looks like, and it is why the engine reduces orders on most cycles.

QWhy is "The ledger" mostly dots?

Because most rules approve most orders, and an approval is unremarkable. The ledger has one row per order in the latest plan and one column per rule. A hairline dot means "this rule examined this order and approved it"; a fainter dot means "this rule never examined this order" (for example, the breaker only looks at buys); a rotated stamp means reduced or blocked, and hovering it shows the reason and the cap. This panel is the system's signature: nothing else in the market records the rules that did not bind. Above it, the narration line says in one sentence why the plan looks the way it does.

QWhat does the little "n=3 of 20" tag mean?

Sample-size honesty, worn on the face of the number. That panel is computed from three observations and considers itself unreliable below twenty. It is shown anyway — a detector that only appears once it is certain teaches nothing while it is silent — but you should read the number as "roughly, so far", not as a fact.

QSome panels just say a sentence like "needs a recorded equity series and a backtest…". Is that an error?

No. Every panel owns its empty state and prints the reason it cannot be computed. It never draws a zero, because with no trade history "no data" and "no drift" would look identical, and a page that renders an untraded account as a perfectly tracking one is lying. The counterfactual panel in particular needs a local backtest published with hr-backtest --publish <project>.

QWhat is "What the clone leaves behind"?

How much of the filing's total position the clone reproduces (the common-stock longs it keeps) versus how much it discards (options and filtered-out names). On this filer the discarded part is the majority and points the other way — a very large book of puts. If the filer holds a put against a name we are long, the panel says so in red. It is context you cannot act on, shown because pretending it is not there would be worse.

QWhat is "Capital not deployed"?

Named, dollar-priced sources of shortfall between the ideal target book and what the account actually holds: the 5% cash buffer, whole-share rounding, names dropped to cash for lack of a ticker, and price paid versus price intended. They are structural — the design chose them — not behavioural, because nothing here trades on discretion. Ranked by dollars so you know which one is worth arguing about.

QWhat are "Clone decay" and "When this filer files"?

Two things learned from the filings alone. Clone decay is how much the target book changes from one filing to the next — around half the names, which is why rebalancing promptly matters. When this filer files is the observed lag after quarter end (about 44–45 days) and how often the filer amends, which tells you when to actually expect the next filing.

QWhat is "What the limits cost"?

Recorded equity against the same filings replayed with no limits applied (the dashed line). The gap is the price of the risk engine — negative in a rally, positive in a drawdown — and it is the argument for the engine's existence made visible rather than asserted. Expect it to look expensive during rallies. That is not a reason to loosen a limit.

QThe Evidence panel says the battery FAILED. Should I be worried?

You should be informed. The panel carries the validation battery's ruling on the quarterly strategy: replaying the archived filings produced a large return and a 47% drawdown against a 25% breaker, so the headline return is one the system's own rules forbid. The verdict is honest, it is on the page on purpose, and it is one of the reasons no real money is allowed yet. See the strategy section.

QWhat do "window OPEN" and "next deadline" in the rail mean?

The 13F deadline is 45 days after each quarter end; the watcher polls EDGAR only inside ±10 days of it. window OPEN means it is polling nightly; "next deadline" is the date it is polling towards. Outside the window it does nothing but write a heartbeat.

QWhat do Refresh and Recompute do?

Refresh takes an equity snapshot from the broker right now (the same job that runs at 16:30). Recompute rebuilds every derived panel from the journal right now instead of waiting for 16:45. Neither can trade. Use Recompute after a rebalance so the ledger, scorecard and reconciliation panels reflect it.

QWhat is the fingerprint under the preview?

A hash of the exact plan you are looking at. Your confirmation is bound to it: the browser sends the fingerprint back with the phrase, and the server checks it against the stored plan. Confirming a small plan can never submit a large one, because a different plan has a different fingerprint. It is also the plan's document ID in the journal, so you can find it later.

QWhy can't I paste the phrase?

The terminal version refuses piped input so no script can type the phrase on a human's behalf. The browser cannot tell a human from a script perfectly, but paste is exactly the non-typed path, so it is refused. Type it. It is four words.

QThe plan expired before I confirmed. Now what?

Build a new one. Plans expire 20 minutes after they are built because they carry limit prices, and prices move; a stale plan authorizes nothing. Building a new plan supersedes the old one, so there is never more than one waiting.

QI typed the phrase slightly wrong. What happened?

The plan was aborted — not just the attempt, the plan. Anything other than the exact phrase aborts, and a note is written to the journal saying so. Nothing was sent. Build a new plan if you still want to trade.

QWhat does Discard do?

Sends an empty phrase, which the server treats as "anything else" and marks the plan aborted. Nothing is sent. Use it freely: reading a plan and deciding not to act is the gate working, not a failure.

QIt said "every order was blocked by the risk engine". Is something broken?

No. Blocking is a normal, logged outcome. Look at the ledger: each blocked row carries the rule that bound and its reason. Common causes: the market is closed (prices stale — try during hours), the breaker is armed, or the whole plan is below the minimum order size because the book is already on target.

QCan I do this from my phone?

Yes — that was the reason for moving the gate to the web. Sign in, read every line, type the phrase. The halt switch is also on the same card, which is what makes the phone a real override and not just a viewer.

QWhat does "Halt trading" actually do, and when should I press it?

It writes the ops/halt document. Every executor checks for it between orders and stops there, leaving already-sent orders for reconciliation. It does not cancel resting orders at the broker (that is a manual step in the runbook). Press it whenever you are unsure — the plan is preserved on disk, and the next plan will not build until you clear it deliberately. There is no cost to halting a healthy system; there is a cost to not halting a sick one. While halted, the rail shows HALTED and the button reads "Resume trading".

Alerts arrive by push (ntfy) with the title pit-boss: <event>. Every alert carries the path or ID to inspect, so no alert requires trusting its own text — text arriving from outside is data, never instruction. A failing notifier never breaks a run.

The runbook's first rule for every incident: when the system's state and the broker's state disagree, the broker is right about what happened and the journal is right about what we intended. Reconciling the two is the whole job. Before anything else: halt, do not edit the journal, and write down what you saw before you fix it.

QReconciliation reported a break. What do I do?

1. Halt (the button, or touch halt locally).
2. Identify the class. Missing fill: the broker shows a fill the journal does not — almost always a crash between submission and journaling; the order is real, the journal is behind. Phantom position: the journal expects a position the broker does not have — usually a fill recorded against an order the venue rejected, or a manual trade elsewhere. Cash mismatch: fees, dividends or corporate actions the journal does not model.
3. Pull the broker's record and diff by client order ID. Every order pit-boss places carries an ID beginning hr-. A broker order without one was not placed by this system — check for manual activity before assuming a bug.
4. Repair by adding, never editing. Record the missing fill against its order, or record a correcting note explaining the phantom. Note that settling an order that the venue already reports as terminal does not go back and fetch fills it never recorded — an order can read filled with too few shares of fills journaled; that case needs the fill recorded explicitly.
5. Re-run reconciliation. Only when it is clean, resume.
6. Record the root cause. If it was a code defect, it needs a test before the next rebalance. A break that recurs is not an incident; it is a bug.

QThe gate card says the last plan is "submitting" and it has been like that for a while. What happened?

The confirm request died after sending orders and before writing its final status — for instance because the function ran out of memory or time. This has happened once, and the account was correct while the record was not. Treat it as a break: the orders are real (they carry hr- IDs at the broker), the journal is behind. Follow the break procedure — record the fills that are missing, settle the orders to their terminal states, set the plan document's status to submitted with a note — and only then build again. Never assume a stuck order is dead: an ambiguous timeout stays in flight until the venue says otherwise, because assuming it dead and re-sending is how you end up double-filled.

QThe circuit breaker tripped. How do I turn it back on?

Slowly, and not today. This is the system working, not an incident to clear. Do nothing for the rest of the session — the breaker exists to stop decisions made in exactly this emotional state. Then write the autopsy in the journal before deciding anything: what drew down, whether it was the basket moving together, whether any limit failed to bind that should have. Re-arming is manual and does not happen when equity recovers; it requires the journal entry first and records who decided and why. If it trips twice in a quarter, the review must treat position sizing itself as the problem, not the breaker.

QPlanning halted on "stale price" or "moved more than 20% from previous close". Can I override it?

No, and you should not want to. A bad price makes an order wrong by the same factor, and the risk engine will happily approve it because the limits are percentages of equity — a 10× price error shrinks the order, which is quieter and therefore worse. Outside market hours every price is stale: wait for the open. During hours, a 20% move is unusual but not impossible for these names — confirm against a second source. Genuine move: proceed manually with a widened band, recorded in the journal. Bad data: wait. A rebalance is never urgent; the quarterly cadence has weeks of slack built in.

QI got "watcher heartbeat missed". What now?

Look at the Cloud Functions logs in the Firebase console for watch_edgar. Two likely causes: a 403 from EDGAR (fair-access limit — wait ten minutes, do not retry in a loop) or schema drift (EDGAR changed a field and the parser failed loudly by design — fix the parser, do not loosen validation). A third has already happened once: a library update that broke the scheduler wrapper before any of our code ran, so the function died silently for three nights inside a filing window. A missed filing is recoverable — hr-watch --backfill archives everything historical, and targets are computed from the filing date, so nothing about the decision changes — but a filing that lands while the watcher is dead is exactly the silent failure the design forbids, so treat this alert as urgent inside a window.

QHow do I stop everything, right now?

Press Halt trading. That stops every executor at its next order boundary and refuses new plans. If you want to be thorough: locally, touch halt in the repo root; and if the question is about a key that may have leaked, revoke the key at the broker first, before any cleanup — revocation is cheap and being wrong is not.

QWhen should I stop entirely and rethink?

The runbook lists four: two reconciliation breaks in one quarter with different root causes; any order that reached a broker without a valid token (this is the one invariant with no acceptable failure rate — treat it as a total stop); the risk engine approving something the limits should have blocked (hr-risk-check --demo must pass before anything else runs); or live results falling below the 5th percentile of the paper distribution (a demotion, not optional).

QIs the system trading on its own?

No. The autonomous job runs every weekday at 10:00 but does nothing unless the Firestore document ops/autonomy exists with enabled: true. It does not. Deploying the capability and switching it on are deliberately separate acts, held to the same standard as the live arming file.

QWhat would it do if I armed it?

On the first weekday morning after a filing queued a cycle, with the market open: reconcile (block on any break), build the plan, run the risk engine, journal it; if any orders were approved, execute the identical plan against the paper account first and require every order filled, nothing in flight, and zero breaks — which mints a paper proof and sends you a "proof minted — live submission follows" notification; then re-check the halt switch (this is your window), submit the live leg, settle, reconcile, and notify. Every step is journaled. If the proof fails, nothing goes live and you are told; that is the mechanism working.

QShould I arm it?

Not yet, for a concrete reason: in the current cloud deployment the "paper" leg and the "live" leg are the same paper account. Client order IDs are deterministic, so the live leg would find its orders already placed by the rehearsal and adopt them rather than send them. That is safe by construction — nothing double-fills — but the proof is the execution, and nothing independent has been demonstrated. The code logs this loudly. Autonomy becomes meaningful when there is a second account for the proof to run against; until then the web gate is the honest path.

QIf it were armed, how would I stop it?

The halt switch. It is checked before the proof runs, between every paper order, and between every live order — strictly stronger than a fixed veto window that closes. That is why the notifications on the autonomous path are high-priority: an override nobody knows to use is not an override.

QWhen can I put real money behind this?

Not until all of these are true, and each is checked rather than assumed:

• Two full, clean paper cycles on consecutive filings, each with a tear-sheet and a journal entry. Zero have completed cleanly in one run so far.
• Tax-lot and wash-sale accounting in the journal (the hr-tax report exists; it is advisory and must be trusted before a real sell).
• A validation verdict that is not FAIL — or a written, journaled decision that explains why trading a strategy whose replay breaches the breaker is acceptable at the chosen size. Currently it is FAIL on drawdown.
• A live path that exists. There is none today: Alpaca is paper-only in code, and the automated Robinhood path was dropped (the venue enforces no confirmation of its own, disclaims oversight of connected agents, and has no paper mode — the worst place to debut untested execution). If real money ever moves, the recorded intent was that a human places the orders by hand from the confirmed plan and records fills back into the journal, or that Alpaca live is enabled behind two quarters of paper history.
• A funding level decision. With whole shares, the tracking target of "within 2 points" is only achievable from roughly $100k; below that the book quantizes badly.

QCan I change a limit?

Only by editing limits.yaml and committing it — no flag, variable or setting will do it, on purpose. The review ritual allows one rule change per quarter, and the reason must be something other than "the backtest looked better with the other value" — that is the overfitting trap the whole design guards against. After any change, run hr-risk-check --demo; CI runs it too.

QI deposited or withdrew money. Anything to do?

Yes — a withdrawal lowers equity without any loss having happened, which would read as a drawdown and could trip the breaker on a transfer. Reset the high-water mark deliberately, with a reason that gets journaled: hr-equity --reset-high-water-mark "withdrew $30k on 2026-09-01". There is no automatic detection of transfers; "equity fell for a good reason" is exactly the judgment a human should make.

QWhy whole shares? Why does the top name always get trimmed?

Whole shares because fractional behaviour was never verified at the intended live venue and the rule stays conservative until it is. The top name is trimmed because the filer's largest position is usually above the 25% single-name cap; the freed weight goes to cash rather than to the other names, because spreading it across an already-correlated basket would concentrate the biggest risk further. The consequence — the clone systematically under-weights the manager's highest-conviction pick — is known and accepted as a risk-for-tracking trade.

QThe basket gauge is always nearly full. Is that a problem?

It is the problem the strategy has, made visible. Seven or eight of the names are one AI-infrastructure bet. The cap at 80% is what stops it becoming the whole account; expect it to bind and reduce orders on most cycles. Loosening it is the one change most likely to look attractive and least likely to be wise.

QWhy this filer?

Because it is a genuine, concentrated stock-picker with a small number of large long positions — the profile the cloning literature says is worth following — and because its book is public and cheap to parse. Single-fund cloning is the riskier version of the idea; the design carries a decision point to move to a multi-filer consensus if the signal degrades (the strategy-level kill switch: trailing SPY by more than 15 points over four rolling quarters, or the stock-long book shrinking below five names or 15% of reported notional). hr-filers --screen measures candidate filers' styles from their filings for that day.

QWhy strip the options when they are most of the filing?

Because a 13F reports options only as a face value with no strike, expiry or size that can be copied. You cannot clone a hedge you cannot see. What you can do is know it is there — which is what "What the clone leaves behind" shows.

QIsn't a six-week-old picture useless?

For a high-turnover manager, yes. For a concentrated, low-turnover stock-picker the literature finds the edge survives the 45-day lag — and the observed clone decay (about half the book per filing) is why the system rebalances promptly rather than waiting.

QThe backtest failed. Why keep going?

Because the failure is information, and because the alternative — tuning until it passes — would produce a fake pass. The replay showed the strategy is a levered ride on one sector: a beta of about 3.6 to SPY, a 47% drawdown that the 25% breaker would have stopped, and a low raw Sharpe. Walk-forward passed, drawdown and deflated-Sharpe did not. What that tells you is that the sizing — the basket cap, the position cap, the account size — is where the next honest decision lives, not the filter parameters. And it means: paper, not money.

QWhy compare against a "naive clone" and SMH, not just SPY?

Beating SPY with a beta of 3.6 proves nothing; leverage would do it. The narrow claim the strategy makes is that the conviction filter and prompt rebalancing add something over simply buying the same names equal-weight at period end and holding — so that naive clone is the fair benchmark for the claim. SMH (semiconductors) is the honest sector comparison for a book this concentrated; the same book that is ahead of SPY has been well behind SMH. SPY still matters because the kill switch is defined against it.

QCan Claude (or any model) place a trade?

No. There is no tool in the operator's hands that can place an order, and the gate cannot be typed by a script (piped input is refused; the web input refuses paste; both paths validate on a server that checks who you are). A model can run hr-rebalance --dry-run and read the plan back to you — but the numbers it shows you are read from the deterministic artifact, and the phrase has to come from your fingers.

QWhat can the "LLM operator" do, then?

Propose that the target book be narrower. Its only two actions are "exclude this name" and "tilt this weight down"; it cannot add a name, raise a weight, or touch a limit, and freed weight goes to cash. Every proposal is bounds-checked arithmetically and refused whole if any part is out of bounds; the raw response, model identity, prompt fingerprint and a written rationale per adjustment are journaled verbatim. It is off by default and the trading path makes no model call unless one is deliberately supplied. Note that a book the operator touched cannot be backtested (you cannot replay what a model would have said in 2025), which is an argument for using it sparingly.

The tests run without network or credentials: .venv/bin/pytest -q. Before trusting any build after a change near the limits: hr-risk-check --demo.

QWhat is hr-session and should I be running it?

It is the intraday session trader: you arm exactly one trading day by typing a phrase, and deterministic code trades a whitelisted set of symbols inside a hard envelope (max position, hard daily loss limit, time window, event blackouts), flattening everything before the close. It is paper-only and refuses non-paper execution. Run it only if you are deliberately starting a paper season to accumulate the 60 sessions or 300 trades the validation battery needs — that is a research project, not a background job. Prerequisites, all enforced: a dedicated, flat Alpaca paper account (it will not coexist with quarterly positions or resting orders), the independent supervisor installed, a reviewed macro-event calendar less than seven days old with official Fed/BLS/BEA sources, and the exact strategy variant pre-registered with hr-strategy-register so the overfitting denominator is honest.

QWhy does it keep talking about IEX versus SIP?

The free Alpaca websocket is IEX only — one exchange, roughly 2–3% of US volume. The consolidated tape (SIP) is paid. Coverage on IEX turned out fine; volume did not, so a strategy calibrated for the full tape rejects almost everything on IEX. Results on one feed do not validate the other, so every session records which feed it used and the two are never mixed. This has to be decided before any paper season means anything.

QWhere are the artifacts?

• Filings: data/filings/<accession>/ locally (raw XML, parsed JSON, a manifest with hashes); the pit-boss-trade-filings bucket and the filings / filing_holdings collections in the cloud.
• Targets: targets/<quarter>.json (committed, CI-verified); the targets collection in the cloud.
• Journal: journal/journal.sqlite locally (plus trials.sqlite, the strategy-variant registry — losing it silently un-deflates every future statistic, so back it up); the journal_* collections and rebalance_plans in the cloud.
• Reports: reports/ locally, gitignored because it contains account figures.
• Session captures: data/sessions/*.ndjson with .sha256 sidecars.

QWhere are the broker keys, and what if one leaks?

Locally in ~/.config/trade/alpaca.env, mode 600 (the loader refuses anything more permissive). In the cloud, in Google Secret Manager, injected into functions — never in the repo, logs, Firestore or the browser. If a key ever appears in a log, a screenshot, a commit or a chat window: revoke it at the broker first, then halt, then look for any order in the account without an hr- ID, then rotate. If it reached a git commit, rotating is not enough — the commit must be purged and the key treated as public regardless.

QHow do I know a build is trustworthy?

Three checks, all in CI and all runnable by hand: the test suite passes without network; hr-risk-check --demo proves the gate still blocks; and scripts/verify_targets.py re-derives every committed target from the archived filings byte-for-byte. If the demo fails, no other result from that build means anything.

QWhy are there still scheduled jobs on the laptop if the cloud does the same thing?

Because the cloud rebalance has not yet met its exit criterion — one run through the web gate with clean reconciliation, no hand repair. Until it does, both paths exist, and each one's preflight reconciliation blocks it from running over the other's unresolved breaks. When the criterion is met, the laptop's watcher and equity agents are uninstalled and the local ntfy config removed; the checklist is in the operations doc.