Build an agent for a Propr challenge with ChatGPT.

Help me build a Python trading agent to attempt a Propr prop firm challenge.
Build and start automated trading on my verified free trial account.
Passing a challenge is the aim, not a promise. Orders must reach Propr; a
report-only or local paper-trading implementation is not the deliverable.

If you are my Dot in ChatGPT, coordinate this work in a local Codex task on
my connected computer. Use the trend-agent folder whose full path I provide.
Send the task this complete specification, inspect its tests and reports,
and bring back the results. If you are Codex, build directly in that folder.
If the folder or computer is unavailable, ask me to connect it before starting.
Do not substitute an ephemeral cloud workspace for the trading host.

Dot coordinates the build and can help review reports. Trading decisions and
risk checks must be deterministic Python code. Do not make orders depend on
an LLM call, a chat session, or a Dot follow-up schedule. Explain separately
how to run and stop the Python service and any optional report-review task.

Setup:
- Inspect the project folder before changing it. Use Python 3 and a local
  .venv. Get the official SDK from https://github.com/XBorgLabs/propr-docs.
  Copy python/propr_sdk.py into this project and install its documented
  dependencies in .venv. Do not overwrite my .env.
- Read PROPR_API_KEY and CHALLENGE_ACCOUNT_ID from .env at runtime. Never
  display the key or send it to a chat, report, or a delegated task message.
- Read Propr's current rulebook and SDK documentation. If either conflicts
  with the specification below, report the exact conflict before proceeding.

You are building a daily trend-following trading agent for a Propr prop-firm
account. Propr executes on Hyperliquid perpetuals through its own REST API.

Two sources, two jobs:
- Market data comes from Hyperliquid's public info API (the candleSnapshot
  request, daily interval), which needs no key. Use it for all history and
  all daily closes. Resolve each instrument to its exact native or HIP-3
  namespace and contract. Do not substitute a spot feed or strip prefixes.
- Orders, positions and account state go through the Propr API using the
  propr_sdk.py file in this folder and the PROPR_API_KEY in .env. Read
  propr_sdk.py and the docs it links before writing code, so you use the real
  method names, the real order fields (asset, quantity, price, triggerPrice,
  side, positionSide, reduceOnly, intentId as a ULID) and the real order
  types (market, limit, stop_market, stop_limit). Never guess an argument.

The challenge rules the agent must monitor and enforce:
- Daily loss limit 3% of the start-of-day balance, checked against EQUITY
  including unrealised P&L. The balance reference resets at 00:00 UTC.
  The agent halts new entries and cancels pending entry orders when equity
  is 2% below the start-of-day balance. Latch this halt until the next
  daily run after the reset. Existing stops and exits still apply.
- Maximum drawdown 6% from the starting balance, static, measured on EQUITY
  including unrealised P&L on open positions. The agent kills itself when
  equity is 4.5% below the starting balance.
- Touching either limit closes the account permanently, even intraday.
  Stops and risk checks cannot guarantee that a limit will never be hit.
- Profit target 10%. No time limit.

The trading rules, which you must implement exactly and must not "improve":
Markets: do not hard-code a crypto-only universe or a fixed market count.
During setup, ask me to choose a watchlist from the markets available on my
Propr account across crypto, equities, indices, commodities and FX. Verify
API order and stop support, exact identifiers, underlying data mappings,
contract multipliers, settlement currency, tick/size limits and trading hours.
Save these in markets.json. Do not guess symbols or silently replace an
unsupported market. Report exclusions. Freeze the list for a paid challenge.
Require at least 60 complete daily bars per market for indicators and an
initial historical test. Fetch up to 400 available bars, and report the actual
history used; short history is not evidence of robustness. Do not fabricate
missing bars. Skip entries on stale prices, market closures or incomplete bars.
Use only completed bars and exclude the signal bar from lookback windows.
If more signals qualify than slots, rank by previous completed day's USD
notional volume descending, then exact market identifier. Apply one shared
portfolio risk budget across all asset classes.
Timeframe: daily bars. The signal scan runs once a day at 00:10 UTC.
Entry long: daily close above the highest high of the previous 20 days.
Entry short: daily close below the lowest low of the previous 20 days.
One position per market. No adding to positions.
Initial stop: 2 x ATR(20) from entry, placed on Propr immediately after the
entry fills as a reduce-only stop_market order.
Size: risk 0.4% of the STARTING balance per trade. Convert risk dollars /
(2 x ATR) to order units using verified contract and currency metadata.
Round down to the permitted size, and skip if below the minimum. Maximum three open positions. Propr applies leverage automatically;
do not attempt to change it. Cap total gross notional across positions and
pending entries at 2 x current equity by reducing or skipping new entries.
Exit long: daily close below the lowest low of the previous 10 days.
Exit short: daily close above the highest high of the previous 10 days.
Or the stop fires, whichever first. No profit targets.
Daily halt: equity 2% below the start-of-day balance means cancel pending
entries and open nothing until the next daily run after the reset.
Existing stops and exits still apply.
Kill switch: equity (including unrealised P&L) 4.5% below the starting
balance means close every position, cancel every order, write
reports/HALT.md explaining the state, and exit. Do not restart.

Build it in this folder as a small Python project:
1. data.py resolves each configured market to Hyperliquid's public data,
   fetches up to 400 completed daily candles and caches them. Enforce the
   minimum history and session/freshness checks above.
2. strategy.py holds the rules above as pure functions with no side effects,
   each with a docstring quoting the rule it implements.
3. backtest.py runs the rules over the history with instrument-specific
   fees, funding and slippage assumptions, explicitly documented,
   simulates the challenge rules (daily limit, static drawdown, target), and
   writes backtest.md with equity curve data, win rate, average win, average
   loss, max drawdown, time to target when reached, number of trades per market,
   the longest flat stretch, and how often the simulated challenge would have
   failed and why. Include a plain-language paragraph that says what the
   numbers mean and what they do not prove. Both loss limits use equity.
   Daily bars cannot establish the order of intraday prices. State that
   limitation and do not report daily-close checks as proof of no breach.
4. run_daily.py performs one scan: refresh data, read account state and
   positions from Propr, compute signals, apply the daily halt and the kill
   switch, then place or cancel orders through the Propr API. Implement real
   trial-account order execution, fill reconciliation and protective stops.
   Use the documented positionId or grouped-order mechanism for stops.
   Protect partial fills, use idempotent intents and reconcile uncertain
   responses before retrying. If a protective stop cannot be confirmed,
   close the affected position and halt new entries. Never force a trade
   just to make a test or demonstration show activity. It writes
   reports/YYYY-MM-DD.md with every signal, every order, the reason for each,
   equity, balance, start-of-day balance, realised P&L for the day, open
   positions, and distance to each stop and to each challenge limit, using
   Propr's own definitions (both loss limits checked against equity).
5. Read CHALLENGE_ACCOUNT_ID from .env. During setup, verify through Propr
   that it identifies my free trial. Never select an active account
   automatically. If its type cannot be verified, stop and ask. Paid
   challenges require an explicit account ID change and separate opt-in.
   Print the account ID and trial or paid status on every run.
6. A cron or launchd entry for 00:10 UTC that runs run_daily.py, and a README
   that explains how to read the daily report, how to switch accounts, and
   how to stop the agent.
7. risk_monitor.py stays running between daily scans. Use Propr's documented
   account updates to check both equity limits, apply the daily halt and
   kill switch, and log every action. Share persistent halt state and order
   coordination with run_daily.py so they cannot duplicate or race orders.
   Block new entries if the monitor or account data is unavailable. Document
   how to start and stop it. A kill-switch halt must survive restarts and
   require manual intervention.

Constraints:
- Never put the API key in any file other than .env, and never commit .env.
- Use Hyperliquid for public market data only. Limit Propr access to the
  documented account and profile reads needed for setup, plus order,
  position and trade endpoints. Never purchase a challenge, request a payout
  or transfer funds.
- Log everything you do to reports/ in plain English.
- Test signal lookbacks, sizing, both equity limits, halt persistence,
  trial-account selection, market identifiers, contract sizing, stale data,
  session closures, partial fills and order coordination using simulated
  responses.
- Run the backtest and verify the selected account is a free trial before
  any orders. Stop on failed tests, unknown account type or missing setup.
  Once these checks pass, start the risk monitor, perform one trading run
  against that verified trial and enable the daily schedule. Submit entries
  only when the rules qualify; no signal is a valid no-trade result.
  Show the service status, selected trial account, backtest and today's
  report. Include Propr order IDs and stop status for any submitted orders.
  State clearly whether a fill occurred or the service is waiting for a
  signal. Do not claim execution was tested if no order filled.
- Support an optional PROPR_BUILDER_CODE setting, empty by default. When
  supplied, send it as X-Builder-Code on Propr API requests only. Never
  invent a code, confuse it with X-API-Key, or add it to Hyperliquid requests.
  Document this as usage attribution, not a confirmed commission entitlement.
  Keep the setting visible and removable; it must not change trading rules.