Diary, setups and approvals

The Diary is the record of why, not just what. Fills are facts; the Diary keeps the thesis, the plan and the outcome in one place so a trade can be reviewed months later.

What lands in a day #

Days are browsable on a calendar, with a detail view per day and running statistics — streaks, win rate and PnL over the selected period.

From proposal to order #

A proposal is a card, never an order. The flow is always:

1. Propose — an agent or the CLI files a setup: pair, side, entry, stop, size, thesis.
2. Review — the card appears in the app with the reasoning and the numbers.
3. Approve — approving prefills the trading ticket with those values.
4. Send — you confirm in the ticket, and only then does anything reach the venue.

Nothing is sent by approving a card, and no card can bypass your risk limits. If you decline, the setup stays in the record as a decision you made — which is often the most useful entry in the whole diary.

Writing notes #

Notes are free text per day, in Markdown. Good notes answer three questions:

• What did I expect to happen, and why?
• What actually happened?
• What will I do differently next time?

A note written after a loss is worth more than ten written after a win.

The daily brief #

jw3 daily-prep (or the equivalent action in the app) builds a morning brief: risk header, open positions, funding and open interest, liquidation distance, macro context, regime and per-pair bias. It is recorded as the day's analysis so the day has a starting state to compare against at the close.

Use --dry to preview without writing.

Reviewing a period #

• Calendar — see which days you traded, and how the month went.
• Stats — win rate, average win and loss, expectancy, streaks.
• Filters — by venue, pair or setup type, to answer "does this pattern actually work?"

A diary you never read is a log file. The value comes from the weekly review: what worked, what repeated, and what to stop doing.

Sharing #

A day can be shared as a read-only link. Review what a shared day contains before sending it: pair names, sizes and PnL are usually fine; notes may contain more than you want public.