# Trader Tool — roadmap and two-minute walkthrough

## One process, four stages

**Market context → my plan → trade or skip → journal → review.**
Only the limited offline journaling loop is currently demonstrated.

| Stage | Work | One understandable result |
|---|---|---|
| **Today: offline prototype** | Synthetic screenshot → corrections → confirmation → test journal → mocked assistant reply | A repeatable application-workflow demonstration, without real AI or trading data |
| **Next: Claude and workflow value** | With approval, evaluate both Claude workflows, compare the participant's usual logging method, and check a return for another review | One report: errors, corrections, cost, logging comparison and repeated use; a decision on continuing a small pilot |
| **Vision: Analysis beside a plan** | Attach an immutable Analysis snapshot with source and as-of time to a plan and trade/skip record | One traceable story: context → own plan → action → result |
| **Long-term forecasting research** | Evaluate hypotheses in the separate Analysis project on out-of-sample data against a simple baseline, including uncertainty | A research report showing reproducible usefulness, or an honest negative result |

## First connection, not a merger

Trader Tool owns the user's process, confirmed records and journal review.
Analysis owns market-data research, context and hypothesis testing. The proposed
first contract is an immutable snapshot: source, creation/as-of time, data window,
research version, evidence and uncertainty. Updating Analysis must not rewrite
the context of an earlier user decision. Repositories, databases and runtimes
remain separate. This connection is not implemented.

## Demand and subscription hypotheses

The initial segment is traders who save screenshots in Telegram and postpone
manual logging. A future pilot would compare logging time/corrections with the
participant's usual method and observe a return for another review. The proposed
subscription charges a self-directed trader for journaling and regular review.
Pricing and willingness to pay are unknown. No pilot is run in this stage.

## Two-minute walkthrough

Open `index.en.html`, then its recorded demo (`demo.en.html`). This is a viewer
of an existing synthetic run, not a new application or Claude call. Existing UI
screenshots are in Russian; English explanatory copy does not imply an English
product UI has been implemented.

### 0:00–0:20 — the problem

**Show:** the first screen.

**Say:** “Today, Trader Tool is a trade journal with review before saving.
Our first audience hypothesis is traders who save screenshots in Telegram but
put off manual logging. We want to test whether they can reach a confirmed
record with less manual work and return to it for review.”

### 0:20–0:45 — the current prototype

**Show:** the synthetic screenshot and **Fields** tab.

**Say:** “This is an early offline prototype. Every record is synthetic and
model responses are mocked, not live Claude output. We are showing the
application workflow. Here, the response misses direction and gets quantity wrong.”

### 0:45–1:10 — the user controls the record

**Show:** **Check → Edit → Confirm record → Record**.

**Say:** “The application will not default an unknown direction to long.
The user corrects the fields and confirms. These reviewed values reach the
saved record. One record comes from this screenshot; six further synthetic
records are added separately to demonstrate review, not extracted from the same image.”

### 1:10–1:35 — recent entries, not the whole practice

**Show:** the existing journal image and **Reflection** tab.

**Say:** “The assistant is intended to ask questions about recent confirmed
entries, not analyze the trader's entire practice. This reply is mocked too.
With real Claude, we want an error inventory and the cost of each workflow,
then a decision about a small user pilot.”

### 1:35–2:00 — future context

**Show:** the clearly labelled **Vision** concept.

**Say:** “The first proposed connection to the separate Analysis project is a
timestamped context snapshot beside my plan and result. That could make
expectations, actions and outcomes comparable. Forecasting is a research goal,
not a claim of accuracy or profit. First, we need to validate Claude and whether
people return to this journal.”

## Next work, not prerequisites for finishing this package

1. A separately approved live-Claude evaluation: field ambiguity, useful
   questions, safety, latency and cost.
2. Compare usual logging and return behaviour; investigate willingness to pay.
3. Scope assistant context to the selected account and decide which plan/rule
   fields should be shared. The current excerpt is limited.
4. Design plan/skip records and a snapshot reference without merging applications.
5. Separately verify Telegram/PostgreSQL and the user workflow before a pilot.

No new product functions or pilot are implemented by this editorial pass.