The five setup questions every new prop-firm trader asks.

The engine enforces three editable rules per session: a dailyLossCap with a negative maxLoss, a maxTrades ceiling, and a consecutiveLoss cooldown — pick a firm template on /templates and these three pre-fill. The founder values for drawdown, profit-target, and max-position sit on the template card as visible thresholds but the engine does not re-route them — you stay in control of the day-to-day caps by tuning the three rule fields above to sit insidethe firm's outer envelope (e.g. an Apex 50K daily-loss floor of −$2,500 becomes a maxLoss of −$2,200 in the builder).

A breach fires the moment a committed, closed tradecrosses one of the three rule thresholds — running-session P&L past your dailyLossCap.maxLoss, your trade count past maxTrades, or your losing streak past consecutiveLoss. Before the trade is committed, the manual-entry form evaluates prospective P&L as you type — if it would breach, a red <Alert /> slides in above the Log trade button listing every tripped rule with its current value vs. its cap. The banner is informational only — pressing Log trade persists the row immediately, with breachAcknowledged: true and the CSV of triggered rule names. The trade still counts on the dashboard as an Overridden breach — never a clean entry — but submission is not blocked, so a deliberate decision has time to happen at the dashboard, not mid-keystroke.

Both paths end up on the same inline-flag pipeline. A manual entry goes through POST /api/trades, runs through evaluateSessionPrefBreaches in rules-engine.ts, then persists. Broker webhooks route to the same handler when an active (firm, accountId) binding matches — neither path skips the rule evaluation. The ActiveSessionBanner on the manual console polls every 3 seconds while a broker binding is live (so the live state shows up at almost-real-time) and falls back to a 30-second cadence once the binding drops. The poll cadence is purely a fetch interval — the breach evaluation is identical either way.

A Monday 09:00 UTC cron entry in polsia.toml runs jobs/weekly-discipline-recap.js. The job walks every user whose last session ended more than six days ago and sends disciplineRecapEmail from src/lib/email/templates.ts through the Polsia email proxy. Delivery is idempotent — a DisciplineRecap row dedupes so each user gets one recap per 7-day window no matter how many times the cron re-fires. The email surfaces session count, breaches caught, total daily-loss prevented, and the last ruleset name you ran.

Hit Clear all in the rule builder. That calls RuleBuilder.handleReset()which does two things: it POSTs an all-null row to /api/session-rules (so your dailyLossCap, maxTrades and consecutiveLoss thresholds all return to their default-empty state) and it PUTs { startedAt: null, endedAt: null, accountId: null } to /api/session-state. The second call wipes the broker binding, so the next inbound webhook will not match an active session and will be rejected at the gate. Start fresh next time by picking a template again on /templates.