| 1 | = Use-Case Model AI Usage =
|
|---|
| 2 |
|
|---|
| 3 | == Name of AI service/solution that was used ==
|
|---|
| 4 |
|
|---|
| 5 | '''Claude Code''' (Anthropic)
|
|---|
| 6 |
|
|---|
| 7 | * '''URL:''' `https://claude.com/claude-code`
|
|---|
| 8 | * '''Type of service/subscription:''' Claude subscription, model Claude Opus 4.7 (1M context).
|
|---|
| 9 |
|
|---|
| 10 | == Final result ==
|
|---|
| 11 |
|
|---|
| 12 | === Results in details / description ===
|
|---|
| 13 |
|
|---|
| 14 | The AI:
|
|---|
| 15 |
|
|---|
| 16 | * Proposed the actor taxonomy (Visitor, Trader, Market Simulator) from the project description and the existing Go code.
|
|---|
| 17 | * Derived a set of 7 use cases covering the full trading loop (register, login, deposit, buy, sell, view portfolio, watchlist).
|
|---|
| 18 | * Wrote each `UseCaseXXXX.md` file with:
|
|---|
| 19 | * initiating actor, other actors, goals
|
|---|
| 20 | * step-by-step dialog-form scenario
|
|---|
| 21 | * '''tested''' SQL statements for every database-touching step, using the `project` schema
|
|---|
| 22 | * alternate flows for the most common failure cases (insufficient funds, insufficient holding, duplicate user, invalid input)
|
|---|
| 23 |
|
|---|
| 24 | == Summary of AI involvement ==
|
|---|
| 25 |
|
|---|
| 26 | ||= =||= Session 1 — 2026-04-21 =||= Session 2 — 2026-08-06/07 =||
|
|---|
| 27 | || '''What I brought''' || The project description in `opis.md` and the existing Go backend || The use-case model as completed in session 1 ||
|
|---|
| 28 | || '''What the AI did''' || Proposed the actor taxonomy and drafted seven use cases with tested SQL || Nothing — the model was not changed ||
|
|---|
| 29 | || '''What I decided''' || To go solo, and therefore to document seven use cases rather than the three the rubric requires || To re-verify every scenario's SQL against a live database rather than trust the April run ||
|
|---|
| 30 |
|
|---|
| 31 | This phase was finished in session 1. In session 2 the only work was
|
|---|
| 32 | verification: each scenario was executed against a live PostgreSQL 16 database,
|
|---|
| 33 | including the failure paths, and the results recorded on the
|
|---|
| 34 | `UseCaseXXXXImplementation` pages.
|
|---|
| 35 |
|
|---|
| 36 | == Entire AI usage log ==
|
|---|
| 37 |
|
|---|
| 38 | See [wiki:ERModelAIUsage] for the full transcript — the same 2026-04-21 session produced the use-case documentation. The defining student prompt was:
|
|---|
| 39 |
|
|---|
| 40 | > I'm going solo do everything that you need to do, and tell me after what do I need to do
|
|---|
| 41 |
|
|---|
| 42 | which led the AI to pick "solo → 3 minimum per rubric → document 7 for a margin" as a default.
|
|---|
| 43 |
|
|---|
| 44 | > '''Student action required:''' append any future refinements of the use-case list or scenarios here.
|
|---|
| 45 |
|
|---|
| 46 |
|
|---|
| 47 | === Session 2 — 2026-08-06 / 2026-08-07 ===
|
|---|
| 48 |
|
|---|
| 49 | No changes were made to the use-case model in this session: the actor list, the
|
|---|
| 50 | seven use cases and the scenario SQL in `UseCase0001`–`UseCase0007` are as
|
|---|
| 51 | produced on 2026-04-21. The SQL in those scenarios was, however, re-verified by
|
|---|
| 52 | executing the corresponding prototype flows against a live PostgreSQL 16
|
|---|
| 53 | database, including the failure paths (insufficient funds, insufficient holding,
|
|---|
| 54 | duplicate registration, wrong password). The results are documented per use case
|
|---|
| 55 | on the `UseCaseXXXXImplementation` pages.
|
|---|
| 56 |
|
|---|
| 57 | === Session 3 — 2026-09-16 ===
|
|---|
| 58 |
|
|---|
| 59 | Driven by the design review logged in full in the Session 3 — 2026-09-16 section of
|
|---|
| 60 | [wiki:ERModelAIUsage]:
|
|---|
| 61 | placing a sell order checked `holdings.quantity` directly, with no way to
|
|---|
| 62 | record that part of a position was already promised to another, unsettled
|
|---|
| 63 | order.
|
|---|
| 64 |
|
|---|
| 65 | '''What changed:'''
|
|---|
| 66 |
|
|---|
| 67 | * [wiki:UseCase0005] — the scenario now reserves the crypto
|
|---|
| 68 | (`holdings.reserved_quantity`) before removing it from the position, checks
|
|---|
| 69 | `quantity - reserved_quantity` rather than raw `quantity`, and adds a
|
|---|
| 70 | worked example and a note on why the reserve and settle steps stay inside
|
|---|
| 71 | one transaction rather than two (only market orders are implemented, and
|
|---|
| 72 | splitting into two commits would risk an order stuck `open` with no cancel
|
|---|
| 73 | use case to recover it).
|
|---|
| 74 | * [wiki:UseCase0004] — no change to the balance logic, but the
|
|---|
| 75 | order insert now goes through `status='open'` before a final
|
|---|
| 76 | `UPDATE ... SET status='executed'`, matching the sell side, so `Orders`
|
|---|
| 77 | genuinely has the lifecycle [wiki:ERModel]
|
|---|
| 78 | describes for it rather than a status column that is only ever written
|
|---|
| 79 | once.
|
|---|
| 80 | * [wiki:UseCase0006] — the `v_portfolio` reference and its query
|
|---|
| 81 | gained `reserved_quantity`/`available_quantity`, since the portfolio screen
|
|---|
| 82 | is where a Trader would actually see the new field.
|
|---|
| 83 | * The use-case importance table and UC0005's one-line description in
|
|---|
| 84 | [wiki:UseCaseModel] were reworded to mention the reservation.
|
|---|
| 85 |
|
|---|
| 86 | Every changed scenario's SQL was re-run against the live database, including a
|
|---|
| 87 | two-concurrent-sells test that reproduces the exact bug being fixed: see
|
|---|
| 88 | [wiki:UseCase0005Implementation].
|
|---|
| 89 |
|
|---|
| 90 | '''What I decided:''' to keep this a revision of the existing UC0004/UC0005
|
|---|
| 91 | pages rather than a new use case (e.g. "cancel order") — `cancelled` remains
|
|---|
| 92 | an unused status, same as before, since nothing in the prototype produces it
|
|---|
| 93 | and inventing a cancel flow was not what the review asked for.
|
|---|
