Index: docs/P0-ProjectDefinition/About.md =================================================================== --- docs/P0-ProjectDefinition/About.md (revision fe28254e92473e37e178fb19214e517a028ddb24) +++ docs/P0-ProjectDefinition/About.md (revision df058387ebe7d07864d874fd1376f15512418581) @@ -6,4 +6,6 @@ ## Short description + +Eduberza - Educational Market simulation This project is a simulation of a crypto exchange, intended for beginners and @@ -67,5 +69,5 @@ This is only for education purposes. The problem is fixing the financial literacy of the people. -### Who uses the system? What types of users exist? +### What types of users exist? Roles/Users that are expected to use this product are: Index: docs/P1-ConceptualModel/ERModel.md =================================================================== --- docs/P1-ConceptualModel/ERModel.md (revision fe28254e92473e37e178fb19214e517a028ddb24) +++ docs/P1-ConceptualModel/ERModel.md (revision df058387ebe7d07864d874fd1376f15512418581) @@ -1,14 +1,8 @@ -# Entity-Relationship Model v.01 +# Entity-Relationship Model v.02 ## Diagram -![ERModel_v01](ERModel_v01.png) - -Attachments for this page: `ERModel_v01.xml` (TerraER source) and `ERModel_v01.png` -(exported image). Open the source with TerraER 3.11: - -```sh -java -jar TerraER3.11.jar # then File → Open → ERModel_v01.xml -``` +![ERModel_v02](ERModel_v02.png) + Notation: Chen. Rectangles are entity sets, diamonds are relationships, ellipses Index: docs/P1-ConceptualModel/ERModel_v02.xml =================================================================== --- docs/P1-ConceptualModel/ERModel_v02.xml (revision df058387ebe7d07864d874fd1376f15512418581) +++ docs/P1-ConceptualModel/ERModel_v02.xml (revision df058387ebe7d07864d874fd1376f15512418581) @@ -0,0 +1,1 @@ +CryptosMarketsMarketTradesMarketCandlesOrdersTransactionsUsersWatchlistsQuotedOnFillsAggregatesPlacedOnSettlesRecordsPlacesHoldsOwnsContains

3

3

3

3

3

3

3

created_at

name

symbol

truetrueid

created_at

is_active

quote_currency

truetrueid

truetrueid

executed_at

price

quantity

side

source

truetrueid

timeframe

open

high

low

close

volume

candle_time

truetrueid

side

type

status

quantity

price

placed_at

executed_at

truetrueid

type

amount

currency

created_at

description

truetrueid

username

email

full_name

password_hash

available_balance

invested_balance

created_at

updated_at

created_at

name

truetrueid

quantity

5avg_price

created_at

updated_at

added_at

Index: docs/P2-RelationalDesign/RelationalDesign.md =================================================================== --- docs/P2-RelationalDesign/RelationalDesign.md (revision fe28254e92473e37e178fb19214e517a028ddb24) +++ docs/P2-RelationalDesign/RelationalDesign.md (revision df058387ebe7d07864d874fd1376f15512418581) @@ -96,5 +96,5 @@ ![relational_schema](relational_schema.jpg) -Generated in **DBeaver** from the **live** `project` schema, in crow's-foot +Generated in **Pgadmin** from the **live** `project` schema, in crow's-foot notation — not drawn by hand, so it is evidence that the deployed database actually matches the design described above. Each box is a table with its @@ -103,21 +103,4 @@ ### How to regenerate it - -**With DBeaver** (the tool the course recommends): - -1. Connect to the assigned FINKI PostgreSQL project database. -2. Double-click the `project` schema → **ER Diagram** tab. -3. Right-click in the diagram → **Notation** → **Crow's foot**. -4. Arrange the tables to mirror the layout of - [`ERModel_v01.png`](../P1-ConceptualModel/ERModel_v01.png). -5. Right-click → **Export diagram** → save as `relational_schema.jpg`. - -On Linux, install it with: - -```sh -flatpak remote-add --if-not-exists --user flathub https://dl.flathub.org/repo/flathub.flatpakrepo -flatpak install --user flathub io.dbeaver.DBeaverCommunity -# or: sudo snap install dbeaver-ce -``` **With pgAdmin 4**, if DBeaver is unavailable — it reads the live schema the same @@ -131,7 +114,2 @@ `convert relational_schema.png relational_schema.jpg` -Whichever tool is used, state it here so the choice is explicit rather than -inferred. Do **not** substitute a tool that only reads the `.sql` file — such as -dbdiagram.io — because the diagram would then show what the script says rather -than what the deployed database contains, which is the thing this artefact is -meant to demonstrate. Index: docs/P3-UseCaseModel/UseCaseModel.md =================================================================== --- docs/P3-UseCaseModel/UseCaseModel.md (revision fe28254e92473e37e178fb19214e517a028ddb24) +++ docs/P3-UseCaseModel/UseCaseModel.md (revision df058387ebe7d07864d874fd1376f15512418581) @@ -1,34 +1,113 @@ -# Use-case model += Use-case model = -## List of Actors / Roles +The detailed pages for this phase are kept in the project's GitHub repository, +[https://github.com/StefanTrsunov/bp StefanTrsunov/bp], under `docs/P3-UseCaseModel/`. Every +use-case link below opens the corresponding file there. -- **Visitor** — Anyone browsing the platform without an account. Can only view public market information. - - [UC0001](UseCase0001.md) — Register new account - - [UC0002](UseCase0002.md) — Log in +== Actors / Roles == -- **Trader** — A logged-in user managing their virtual funds and positions. - - [UC0003](UseCase0003.md) — Deposit virtual funds - - [UC0004](UseCase0004.md) — Place market BUY order - - [UC0005](UseCase0005.md) — Place market SELL order - - [UC0006](UseCase0006.md) — View portfolio and transaction history - - [UC0007](UseCase0007.md) — Manage watchlist +'''Visitor''' – Anyone using EduBerza without an account, who can look at public market +information, create an account, and log in. -- **Market Simulator** — An external automated system (the bot in `bots/`) that inserts simulated trades and candles into the database so prices move in the simulation. +'''Trader''' – A registered, logged-in user who deposits virtual funds, places market buy and +sell orders, follows the value of their portfolio, and keeps a watchlist of assets they want to +monitor. -## Use-case model diagram (optional) +'''Market Simulator''' – An external automated system (the bot in `bots/`) that writes simulated +trades and candles into the database so prices move without a connection to a real exchange. -*(Optional per the rubric; include one later if time allows.)* +== Use-Cases == -## Realization details on selection of the most important use cases +=== Visitor === -Solo project → **at least 3 use cases required** (rubric: "at least 3 per team-member"). **7 use cases documented** for a safety margin. All are implemented in the P4 prototype; see `server/` for the Go source and [PrototypeImplementation](../P4-Prototype/PrototypeImplementation.md) for documented runs. + * [https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCase0001.md UC0001] – + '''Register new account''' – Visitor creates an account with a unique username and e-mail; the + password is stored as a SHA-256 hash. + * [https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCase0002.md UC0002] – + '''Log in''' – Visitor authenticates with username and password so the system treats every + following action as a Trader. -| Use case | Importance | Why documented | -|----------------------------------------|------------|-------------------------------------------------------------------------------------------| -| [UC0001 — Register](UseCase0001.md) | High | Without it nothing else works; demonstrates `INSERT` with uniqueness check. | -| [UC0002 — Login](UseCase0002.md) | High | Authenticates every `Trader` action; demonstrates `SELECT` with parameter binding. | -| [UC0003 — Deposit](UseCase0003.md) | High | Shows a multi-row transaction: `UPDATE users` + `INSERT INTO transactions`. | -| [UC0004 — Buy](UseCase0004.md) | Very high | Core of the exchange: `INSERT orders`, `UPDATE users`, `UPSERT holdings`, ledger, trade. | -| [UC0005 — Sell](UseCase0005.md) | Very high | Dual of Buy; demonstrates row-level `FOR UPDATE` locking and cost-basis bookkeeping. | -| [UC0006 — Portfolio](UseCase0006.md) | High | Demonstrates joins over `holdings`, `markets`, `crypto`, and a view (`v_portfolio`). | -| [UC0007 — Watchlist](UseCase0007.md) | Medium | Demonstrates N-M relation handling and `ON CONFLICT` upsert semantics. | +=== Trader === + + * [https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCase0003.md UC0003] – + '''Deposit virtual funds''' – Trader tops up their virtual cash balance; the user row and the + ledger are written in one transaction. + * [https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCase0004.md UC0004] – + '''Place market BUY order''' – Trader buys a crypto asset at the current market price, which + debits cash and upserts the holding at a running weighted-average price. + * [https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCase0005.md UC0005] – + '''Place market SELL order''' – Trader sells part or all of a holding at the current market + price, which credits cash and preserves the cost basis. + * [https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCase0006.md UC0006] – + '''View portfolio and transaction history''' – Trader inspects current holdings, unrealised + P/L, cash balances and the most recent ledger entries. + * [https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCase0007.md UC0007] – + '''Manage watchlist''' – Trader lists, adds and removes crypto assets on a personal watchlist, + where adding an asset already on the list is a no-op. + +=== Market Simulator === + +The Market Simulator initiates no use case of its own. It participates in +[https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCase0004.md UC0004] and +[https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCase0005.md UC0005] +indirectly, by keeping `project.market_trades` populated so that `project.v_latest_prices` +returns a current price for every active market. + +== Use-case model diagram == + +{{{#!comment +The diagram is optional for P3. Commit the exported image to +docs/P3-UseCaseModel/use_case_diagram.png and then replace this comment with: + +[https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/use_case_diagram.png Use-case model diagram] +}}} + +== Detailed Use-Cases == + +The following use-cases are documented in detail, with SQL tested against the P2 database: + + * [https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCase0001.md UseCase0001] – Visitor registers a new account + * [https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCase0002.md UseCase0002] – Visitor logs in + * [https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCase0003.md UseCase0003] – Trader deposits virtual funds + * [https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCase0004.md UseCase0004] – Trader places a market BUY order + * [https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCase0005.md UseCase0005] – Trader places a market SELL order + * [https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCase0006.md UseCase0006] – Trader views portfolio and transaction history + * [https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCase0007.md UseCase0007] – Trader manages a watchlist + +== Realization details on selection of the most important use cases == + +This is a solo project, so '''at least 3 use cases''' are required. '''7 use cases''' are +documented, for a safety margin. All seven are implemented in the P4 prototype; see +[https://github.com/StefanTrsunov/bp/tree/main/server server/] for the Go source and +[https://github.com/StefanTrsunov/bp/blob/main/docs/P4-Prototype/PrototypeImplementation.md PrototypeImplementation] +for the documented runs. + +||=Use case=||=Importance=||=Why it was selected=|| +||[https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCase0001.md UC0001 – Register]||High||Nothing else works without it; demonstrates `INSERT` with a uniqueness check.|| +||[https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCase0002.md UC0002 – Log in]||High||Authenticates every Trader action; demonstrates `SELECT` with parameter binding.|| +||[https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCase0003.md UC0003 – Deposit]||High||Shows a multi-row transaction: `UPDATE users` plus `INSERT INTO transactions`.|| +||[https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCase0004.md UC0004 – Buy]||Very high||Core of the exchange: `INSERT orders`, `UPDATE users`, upsert `holdings`, ledger entry, market trade.|| +||[https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCase0005.md UC0005 – Sell]||Very high||Dual of Buy; demonstrates row-level `FOR UPDATE` locking and cost-basis bookkeeping.|| +||[https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCase0006.md UC0006 – Portfolio]||High||Demonstrates joins over `holdings`, `markets` and `crypto`, and the `v_portfolio` view.|| +||[https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCase0007.md UC0007 – Watchlist]||Medium||Demonstrates N–M relation handling and `ON CONFLICT` upsert semantics.|| + +== AI usage == + +AI was used in this phase and is logged in full, per the course rule for P1 onward. + + * '''Phase log:''' + [https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCaseModelAIUsage.md UseCaseModelAIUsage.md] + – service used, what the AI produced, and what I decided myself. + * '''Full conversation transcript:''' + [https://github.com/StefanTrsunov/bp/blob/main/docs/P1-ConceptualModel/ERModelAIUsage.md ERModelAIUsage.md] + – the same conversation produced the P1–P4 artefacts, so the complete prompt/response log is + kept in one place. Direct links: + [https://github.com/StefanTrsunov/bp/blob/main/docs/P1-ConceptualModel/ERModelAIUsage.md#session-1--2026-04-21 Session 1 – 2026-04-21], + [https://github.com/StefanTrsunov/bp/blob/main/docs/P1-ConceptualModel/ERModelAIUsage.md#session-2--2026-08-06--2026-08-07 Session 2 – 2026-08-06/07]. + +'''Service:''' Claude Code (Anthropic), https://claude.com/claude-code – Claude subscription, +model Claude Opus 4.7 (1M context). + +'''In short:''' the AI proposed the actor taxonomy and drafted the seven use cases with their SQL +in session 1. In session 2 the use-case model itself was '''not''' changed – the only work was +re-executing every scenario, including the failure paths, against a live PostgreSQL 16 database. Index: docs/P4-Prototype/PrototypeImplementation.md =================================================================== --- docs/P4-Prototype/PrototypeImplementation.md (revision fe28254e92473e37e178fb19214e517a028ddb24) +++ docs/P4-Prototype/PrototypeImplementation.md (revision df058387ebe7d07864d874fd1376f15512418581) @@ -1,58 +1,108 @@ -# Prototype Implementation += Prototype Implementation = -The prototype is a Go command-line application in `server/` that works against -the `project` schema in PostgreSQL. It implements all seven use cases from -[UseCaseModel](../P3-UseCaseModel/UseCaseModel.md) — the rubric requires at least three — with -every database access shown as real, executed SQL. An auxiliary program in -`bots/` simulates a live market so prices move while the prototype is running. +The prototype is a Go command-line application in +[https://github.com/StefanTrsunov/bp/tree/main/server server/] that works against the `project` +schema in PostgreSQL. It implements all seven use cases from +[https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCaseModel.md UseCaseModel] +– the rubric requires at least three – with every database access shown as real, executed SQL. +An auxiliary program in [https://github.com/StefanTrsunov/bp/tree/main/bots bots/] simulates a +live market so prices move while the prototype is running. -Build, configure, run and test instructions: [BuildInstructions](BuildInstructions.md). +Build, configure, run and test instructions: +[https://github.com/StefanTrsunov/bp/blob/main/docs/P4-Prototype/BuildInstructions.md BuildInstructions]. -## Implemented use-cases +All pages listed below, together with the screenshots of each run, are kept in the project's +GitHub repository, [https://github.com/StefanTrsunov/bp StefanTrsunov/bp], under +`docs/P4-Prototype/`. -| Page | Use-case | Source | -|------|----------|--------| -| [UseCase0001Implementation](UseCase0001Implementation.md) | Register a new account | `server/auth.go` | -| [UseCase0002Implementation](UseCase0002Implementation.md) | Log in | `server/auth.go` | -| [UseCase0003Implementation](UseCase0003Implementation.md) | Deposit virtual funds | `server/account.go` | -| [UseCase0004Implementation](UseCase0004Implementation.md) | Place market BUY order | `server/trade.go` | -| [UseCase0005Implementation](UseCase0005Implementation.md) | Place market SELL order | `server/trade.go` | -| [UseCase0006Implementation](UseCase0006Implementation.md) | View portfolio and history | `server/portfolio.go` | -| [UseCase0007Implementation](UseCase0007Implementation.md) | Manage watchlist | `server/watchlist.go` | +== Implemented use-cases == -Each page mirrors its P3 use-case page and adds the actual SQL emitted by the Go -code plus a screenshot of the corresponding run against the live database. +||=Page=||=Use-case=||=Source=|| +||[https://github.com/StefanTrsunov/bp/blob/main/docs/P4-Prototype/UseCase0001Implementation.md UseCase0001Implementation]||Register a new account||[https://github.com/StefanTrsunov/bp/blob/main/server/auth.go server/auth.go]|| +||[https://github.com/StefanTrsunov/bp/blob/main/docs/P4-Prototype/UseCase0002Implementation.md UseCase0002Implementation]||Log in||[https://github.com/StefanTrsunov/bp/blob/main/server/auth.go server/auth.go]|| +||[https://github.com/StefanTrsunov/bp/blob/main/docs/P4-Prototype/UseCase0003Implementation.md UseCase0003Implementation]||Deposit virtual funds||[https://github.com/StefanTrsunov/bp/blob/main/server/account.go server/account.go]|| +||[https://github.com/StefanTrsunov/bp/blob/main/docs/P4-Prototype/UseCase0004Implementation.md UseCase0004Implementation]||Place market BUY order||[https://github.com/StefanTrsunov/bp/blob/main/server/trade.go server/trade.go]|| +||[https://github.com/StefanTrsunov/bp/blob/main/docs/P4-Prototype/UseCase0005Implementation.md UseCase0005Implementation]||Place market SELL order||[https://github.com/StefanTrsunov/bp/blob/main/server/trade.go server/trade.go]|| +||[https://github.com/StefanTrsunov/bp/blob/main/docs/P4-Prototype/UseCase0006Implementation.md UseCase0006Implementation]||View portfolio and history||[https://github.com/StefanTrsunov/bp/blob/main/server/portfolio.go server/portfolio.go]|| +||[https://github.com/StefanTrsunov/bp/blob/main/docs/P4-Prototype/UseCase0007Implementation.md UseCase0007Implementation]||Manage watchlist||[https://github.com/StefanTrsunov/bp/blob/main/server/watchlist.go server/watchlist.go]|| -## What the prototype demonstrates about the database design +Each page mirrors its P3 use-case page and adds the actual SQL emitted by the Go code plus a +screenshot of the corresponding run against the live database. The screenshots are committed +alongside the pages, in +[https://github.com/StefanTrsunov/bp/tree/main/docs/P4-Prototype/screenshots docs/P4-Prototype/screenshots/]. -- **The current price is never stored as a column.** It is always the price of - the most recent row in `market_trades`, read through the `v_latest_prices` - view. Both the user's own fills and the bot's simulated trades feed the same - table, so there is exactly one definition of "the price". -- **Money movements are transactional.** Buying touches five tables — `orders`, - `users`, `holdings`, `transactions`, `market_trades` — inside one transaction. - A failed balance check rolls the whole thing back: after a rejected purchase - there is no order row, no ledger entry and no holding. This is verified in the - failure-path tests in [BuildInstructions](BuildInstructions.md). -- **Constraints do real work.** `UNIQUE (user_id, crypto_id)` on `holdings` is - what makes the `INSERT … ON CONFLICT DO UPDATE` upsert possible, so the - weighted-average entry price is recomputed by the database in one statement - instead of by a read-modify-write in application code. -- **No identifiers are ever typed.** Markets are listed with their prices before - any choice is made, and everything else is selected by symbol. +== What the prototype demonstrates about the database design == -## Known limitations + * '''The current price is never stored as a column.''' It is always the price of the most recent + row in `market_trades`, read through the `v_latest_prices` view. Both the user's own fills and + the bot's simulated trades feed the same table, so there is exactly one definition of "the + price". + * '''Money movements are transactional.''' Buying touches five tables – `orders`, `users`, + `holdings`, `transactions`, `market_trades` – inside one transaction. A failed balance check + rolls the whole thing back: after a rejected purchase there is no order row, no ledger entry + and no holding. This is verified in the failure-path tests in + [https://github.com/StefanTrsunov/bp/blob/main/docs/P4-Prototype/BuildInstructions.md BuildInstructions]. + * '''Constraints do real work.''' `UNIQUE (user_id, crypto_id)` on `holdings` is what makes the + `INSERT … ON CONFLICT DO UPDATE` upsert possible, so the weighted-average entry price is + recomputed by the database in one statement instead of by a read-modify-write in application + code. + * '''No identifiers are ever typed.''' Markets are listed with their prices before any choice is + made, and everything else is selected by symbol. -Deliberately out of scope for a first prototype, and the natural content of the -later phases: +== Known limitations == -- Only `market` orders execute. `limit` is accepted by the schema - (`orders.type`) but the matching logic is not implemented. -- Passwords are SHA-256 without a salt. Adequate to demonstrate that the - password itself is never stored; not adequate for real use. A proper - password hash belongs in P9 (security). -- Money is handled as `float64` in Go while the database columns are `numeric`. - All arithmetic that must be exact — the weighted average — is done in SQL for - that reason, but the Go side would need a decimal type for real use. -- There is no connection pooling configuration and no explicit isolation level; - both are P8 topics. +Deliberately out of scope for a first prototype, and the natural content of the later phases: + + * Only `market` orders execute. `limit` is accepted by the schema (`orders.type`) but the + matching logic is not implemented. + * Passwords are SHA-256 without a salt. Adequate to demonstrate that the password itself is + never stored; not adequate for real use. A proper password hash belongs in P9 (security). + * Money is handled as `float64` in Go while the database columns are `numeric`. All arithmetic + that must be exact – the weighted average – is done in SQL for that reason, but the Go side + would need a decimal type for real use. + * There is no connection pooling configuration and no explicit isolation level; both are P8 + topics. +== AI usage == + +AI was used in this phase and is logged in full, per the course rule for P1 onward. + + * '''Phase log:''' + [https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCaseModelAIUsage.md UseCaseModelAIUsage.md] + – service used, what the AI produced, and what I decided myself. + * '''Full conversation transcript:''' + [https://github.com/StefanTrsunov/bp/blob/main/docs/P1-ConceptualModel/ERModelAIUsage.md ERModelAIUsage.md] + – the same conversation produced the P1–P4 artefacts, so the complete prompt/response log is + kept in one place. Direct links: + [https://github.com/StefanTrsunov/bp/blob/main/docs/P1-ConceptualModel/ERModelAIUsage.md#session-1--2026-04-21 Session 1 – 2026-04-21], + [https://github.com/StefanTrsunov/bp/blob/main/docs/P1-ConceptualModel/ERModelAIUsage.md#session-2--2026-08-06--2026-08-07 Session 2 – 2026-08-06/07]. + +'''Service:''' Claude Code (Anthropic), https://claude.com/claude-code – Claude subscription, +model Claude Opus 4.7 (1M context). + +'''In short:''' the AI proposed the actor taxonomy and drafted the seven use cases with their SQL +in session 1. In session 2 the use-case model itself was '''not''' changed – the only work was +re-executing every scenario, including the failure paths, against a live PostgreSQL 16 database. + +== AI usage == + +AI was used in this phase and is logged in full, per the course rule for P1 onward. + + * '''Phase log:''' + [https://github.com/StefanTrsunov/bp/blob/main/docs/P4-Prototype/PrototypeImplementationAIUsage.md PrototypeImplementationAIUsage.md] + – service used, the bugs found and fixed, the test evidence, and what I decided myself. + * '''Full conversation transcript:''' + [https://github.com/StefanTrsunov/bp/blob/main/docs/P1-ConceptualModel/ERModelAIUsage.md ERModelAIUsage.md] + – the same conversation produced the P1–P4 artefacts, so the complete prompt/response log is + kept in one place. Direct links: + [https://github.com/StefanTrsunov/bp/blob/main/docs/P1-ConceptualModel/ERModelAIUsage.md#session-1--2026-04-21 Session 1 – 2026-04-21], + [https://github.com/StefanTrsunov/bp/blob/main/docs/P1-ConceptualModel/ERModelAIUsage.md#session-2--2026-08-06--2026-08-07 Session 2 – 2026-08-06/07]. + +'''Service:''' Claude Code (Anthropic), https://claude.com/claude-code – Claude subscription, +model Claude Opus 4.7 (1M context). + +'''In short:''' session 1 rewrote the existing Chi/HTTP backend as the CLI prototype covering +UC0001–UC0007 and added the market bot. Session 2 was a review pass I asked for, which found and +fixed three bugs – a path-resolution bug that made the documented build instructions fail, an +infinite loop at end of input, and an error check in the wrong order that misreported database +failures as "Insufficient holding" – and replaced the read-modify-write holding update with a +single `INSERT … ON CONFLICT DO UPDATE`. Index: docs/README.md =================================================================== --- docs/README.md (revision fe28254e92473e37e178fb19214e517a028ddb24) +++ docs/README.md (revision df058387ebe7d07864d874fd1376f15512418581) @@ -77,6 +77,8 @@ | File | Phase | What | |------|-------|------| -| [`ERModel_v01.xml`](P1-ConceptualModel/ERModel_v01.xml) | P1 | TerraER source of the ER diagram | -| [`ERModel_v01.png`](P1-ConceptualModel/ERModel_v01.png) | P1 | Exported diagram image | +| [`ERModel_v02.xml`](P1-ConceptualModel/ERModel_v02.xml) | P1 | TerraER source, current version | +| [`ERModel_v02.png`](P1-ConceptualModel/ERModel_v02.png) | P1 | Exported diagram image, current version | +| [`ERModel_v01.xml`](P1-ConceptualModel/ERModel_v01.xml) | P1 | TerraER source, first version (kept per P1 rules) | +| [`ERModel_v01.png`](P1-ConceptualModel/ERModel_v01.png) | P1 | Exported diagram image, first version | | [`../server/db/schema_creation.sql`](../server/db/schema_creation.sql) | P2 | DDL — drops and recreates the `project` schema | | [`../server/db/data_load.sql`](../server/db/data_load.sql) | P2 | DML — truncates and reloads sample data |