Build a Safer AI Trading Execution Bot

Create a system generated API key in the exchange API management area. Configure it as follows:

You are helping me create a local AI trading execution layer.

The architecture is:
1. You are the local reasoning and instruction interface.
2. The exchange supplied MCP server is the connection layer.
3. My paper trading account or isolated subaccount is the execution layer.
4. Local Markdown files contain context, instructions, trade history, and reviewed lessons.

Work in small, verifiable steps.

Requirements:
1. Inspect this machine and determine whether the required Node environment is installed. Explain any missing dependency before installing it.
2. Create the local folder structure specified below.
3. Help me connect the official native MCP server for my selected exchange. Use the current configuration method available in the installed MCP package or its official setup material. Do not invent commands, package names, environment variable names, or endpoints.
4. Pause when I must create an API key or enter a secret. Do not ask me to paste secrets into a normal chat message. Help me store them in the local secret mechanism required by the MCP.
5. Ensure withdrawals are not required. The key should have only account reading and trading permissions.
6. Add secret files and local MCP configuration containing credentials to .gitignore where applicable.
7. After configuration, tell me whether the client must be restarted.
8. Test read access first by requesting a current BTC price.
9. Test authenticated read access by retrieving the connected account mode and balance.
10. Do not submit an order until I provide an exact instrument, side, order type, quantity or maximum notional value, and explicit confirmation.
11. Default to paper trading or an isolated subaccount.
12. After every submitted order, update the local ledger. After a trade closes, draft a learning entry for my review.
13. Never turn one losing trade into a permanent strategy rule. Record observations and require my approval before changing strategy instructions.
14. If a step fails, diagnose the actual error, show the likely cause, and propose the smallest fix. Do not repeatedly retry an order when its status is uncertain.

First, inspect the environment and create the folder structure. Then stop and show me what you created.

trading-bot/
├── context.md
├── instructions.md
├── memory.md
├── strategy.md
├── ledger.md
├── learnings.md
├── reflections.md
└── .gitignore

## Account purpose

Account type: [paper trading or isolated subaccount]
Primary assets: [assets]
Trading horizon: [intraday, swing, or long term]

## Objectives

Primary objective: [objective]
What I am testing: [experiment]
What success means: [measurable definition]

## Risk context

Maximum capital allocated to this experiment: [amount]
Maximum acceptable loss per trade: [amount or percentage]
Maximum total exposure: [amount or percentage]
Assets or products that must never be traded: [list]

## Personal constraints

Times I can review trades: [times]
Situations in which the bot must not trade: [conditions]
Other relevant positions or constraints: [details]

## Operating rules

1. Treat this system as an execution assistant, not an authority to invent trades.
2. Never place a live order without explicit confirmation.
3. Before requesting confirmation, restate the instrument, direction, order type, size, maximum notional value, thesis, and invalidation.
4. If any required field is missing or ambiguous, ask for clarification.
5. Use paper trading or the designated isolated subaccount unless told otherwise.
6. Never request, enable, or use withdrawal permission.
7. If order status is uncertain, query the exchange before retrying.
8. Log every order request and exchange response in ledger.md.
9. When a trade closes, draft a plain English review in learnings.md.
10. Do not modify strategy rules because of one trade.
11. Label possible patterns as observations until they recur and receive manual approval.
12. Never claim a strategy is profitable without relevant test results.

## Strategy name

[Name]

## Status

[Draft, back test, forward test, paper trading, or live]

## Instrument and timeframe

Instrument: [symbol]
Timeframe: [timeframe]

## Entry conditions

All required conditions:
1. [condition]
2. [condition]
3. [condition]

## Invalidation

The trade thesis is invalid when:
[objective condition]

## Exit and profit management

Stop condition: [condition]
Profit condition: [condition]
Time based exit, if any: [condition]

## Position constraints

Maximum notional value: [amount]
Maximum concurrent positions: [number]
Additional restrictions: [restrictions]

## Testing evidence

Back test period: [period]
Forward test period: [period]
Known limitations: [limitations]

## Trade ledger

| Trade ID | Opened | Closed | Account | Instrument | Side | Order type | Size | Entry | Exit | Thesis | Invalidation | Status | Result | Exchange reference |
|---|---|---|---|---|---|---|---:|---:|---:|---|---|---|---:|---|

## Reviewed learnings

### Trade [ID]

Date closed: [date and time]
Outcome: [profit, loss, or flat]
Original thesis: [thesis]
What happened: [factual description]
What execution handled well: [details]
What execution handled poorly: [details]
Possible observation: [observation]
Evidence from similar trades: [none or references]
Proposed rule change: [none or proposal]
Manual review status: [pending, accepted, or rejected]

## Personal trade reflections

### Trade [ID], before entry

Why am I entering this trade?
[answer]

What evidence supports it?
[answer]

What would prove the idea wrong?
[answer]

Am I following the documented strategy or acting on impulse?
[answer]

### Trade [ID], after exit

Did I follow the original plan?
[answer]

Was the result caused by strategy, execution, or normal variance?
[answer]

What should I observe across future trades?
[answer]

Do not place or modify any order.

Use the exchange MCP to retrieve the current BTC market price. Report:
1. The exact symbol queried.
2. The returned price.
3. The exchange timestamp, if available.
4. The MCP tool that supplied the result.

If the tool fails, diagnose the connection without attempting a trade.

Do not place or modify any order.

Verify the authenticated exchange connection. Report:
1. The connected account or subaccount identifier, without exposing secrets.
2. Whether it is paper trading or live.
3. The balances visible to the API.
4. Whether trading permission is available.
5. Whether withdrawal permission is disabled, if the API can verify this.

Stop if the connected account is not the intended test account.

Prepare an order preview only. Do not submit it.

Account: [paper account or subaccount]
Instrument: [exact symbol]
Side: [buy or sell]
Order type: [market or limit]
Quantity: [quantity]
Maximum notional value: [amount]
Limit price, if applicable: [price]
Thesis: [reason for the trade]
Invalidation: [condition that proves the thesis wrong]
Planned exit: [exit condition]

Before asking for confirmation:
1. Verify the instrument and account.
2. Retrieve a current price.
3. Calculate the estimated notional value.
4. Explain any missing or ambiguous field.
5. Show the complete order payload in plain English.
6. Confirm that no withdrawal capability is involved.

Wait for my explicit confirmation.

I confirm submission of the exact order previewed in your previous response. Submit it once.

After submission:
1. Return the exchange order reference and status.
2. Query the exchange to verify that the order exists.
3. Do not retry automatically if the status is uncertain.
4. Add the order and its rationale to ledger.md.

Review closed trade [trade ID] using the exchange record, ledger.md, strategy.md, and reflections.md.

Update the ledger with the final exit and result. Then draft a learning entry containing:
1. The original thesis and invalidation.
2. Whether execution matched the instructions.
3. A factual explanation of what happened.
4. What went well.
5. What went poorly.
6. A possible observation for future review.
7. References to similar trades, if any.

Do not create or modify a permanent strategy rule based on this trade alone. Mark any proposed change as pending manual review.

Add a Telegram interface to this existing trading execution project.

Requirements:
1. Accept messages only from my configured Telegram chat ID.
2. Store the bot token using a local secret mechanism, never in Markdown files or source control.
3. Reject all unauthorized chat IDs and log the rejection without logging message secrets.
4. Treat Telegram messages as untrusted input.
5. Allow read only requests, such as balances, positions, and market prices.
6. For any order, return a complete preview and require a separate explicit confirmation message.
7. Do not allow withdrawals, API key changes, permission changes, or arbitrary terminal commands through Telegram.
8. Prevent duplicate order submission.
9. If an order status is uncertain, query the exchange rather than retrying.
10. Explain how to start, stop, and verify the relay.

First, propose the architecture and security controls. Do not begin implementation until I approve the plan.