# Trading bot concept report + Drive delivery pattern

Use when the user asks for a comprehensive, outsider-readable trading-bot report covering paper-trade learnings, strategy selection, live-readiness, monitoring, and next steps, especially when the report must be saved to Google Drive.

## Evidence collection before writing

1. Regenerate the latest read-only scorecard from runtime journals, not from memory.
2. Verify active bot processes by inspecting `/proc/<pid>/environ` for exact strategy identity and mode flags:
   - `CTB_STRATEGY_ID`
   - `CTB_RUNTIME_DIR`
   - `CTB_PAPER_TRADING=true`
   - `CTB_DRY_RUN=false` for paper execution
3. Run the relevant focused tests and, when making broad readiness claims, the full test suite.
4. Regenerate the dashboard/scorecard artifacts so the report and runtime UI match.
5. Compute per-strategy journal metrics directly where useful:
   - closed trades, realized PnL, win rate, profit factor
   - top traded/exited coins
   - WLD or largest-coin PnL separately
   - last event timestamp
6. Check true open exposure from `paper_state.json` by counting only non-zero contracts/size, not merely position keys.

## Report structure

For an outsider-readable concept document, include:

- Executive summary with a clear live/no-live decision.
- Evidence inspected: runtime, process modes, tests, generated reports.
- Strategy-family learnings: what worked, what failed, and why.
- Indicator/entry logic summary: squeeze breakout, SMA confirmation, RSI/Bollinger/VWAP where relevant, flash-crash/drop logic, relative strength/breadth guards.
- Exit/risk summary: ATR/hard stop, break-even snap, V-shape trailing, dead-fish time stop, risk-based sizing.
- Coin-leakage analysis, including PnL ex-dominant coin when available.
- Proposed final bot architecture: signal layer, quality gates, risk layer, execution boundary, learning loop, monitoring.
- Explicit live-readiness gates and next steps.
- State clearly that `Live-preview-ready` is not live permission; live requires explicit user approval.

## Interpretation rules

- Do not recommend live if the best strategies are research-samplers, have tiny samples, or are dominated by one coin (for example >70% WLD trades/PnL).
- Treat a previously promising strategy that turns negative after more trades as downranked/blocked; do not preserve old optimism.
- A high score/PnL with extreme coin leakage is a promising research signal, not proof of robust edge.
- Prefer a final blueprint that preserves proven modules (for example squeeze confirmation, V-shape exit, risk sizing) while explicitly adding gates for observed failure modes.

## Google Drive delivery via `gog`

When the generic Google helper reports `NOT_AUTHENTICATED` but the user's environment has `gog -a friday.uplink@gmail.com` configured, use `gog` directly and set `GOG_KEYRING_PASSWORD` in the subprocess environment without printing it.

Typical flow:

1. Locate the target folder with a raw Drive query for exact folder name.
2. Write the final Markdown locally under `/tmp`.
3. Create a native Google Doc from Markdown:
   - `gog -a friday.uplink@gmail.com docs create <title> --parent <folder_id> --file <report.md> --pageless --json --results-only`
4. Upload the Markdown source as `text/markdown` for traceability.
5. Verify by listing the folder and matching exact file IDs, names, MIME types, and parents.
6. In the final response, provide the Google Doc link and the Markdown source link.

Do not print keyring passwords, tokens, exchange credentials, wallet IDs, or raw financial account details in chat or reports.