Changeset df05838


Ignore:
Timestamp:
09/11/26 11:05:54 (3 weeks ago)
Author:
Stefan <trsunovstefan@…>
Branches:
main
Children:
9577c79
Parents:
fe28254
Message:

Zip files

Location:
docs
Files:
7 added
6 edited

Legend:

Unmodified
Added
Removed

  • docs/P0-ProjectDefinition/About.md

    rfe28254 rdf05838  
    66
    77## Short description
     8
     9Eduberza - Educational Market simulation
    810
    911This project is a simulation of a crypto exchange, intended for beginners and
    … …  
    6769This is only for education purposes. The problem is fixing the financial literacy of the people.
    6870
    69 ### Who uses the system? What types of users exist?
     71### What types of users exist?
    7072
    7173Roles/Users that are expected to use this product are:

  • docs/P1-ConceptualModel/ERModel.md

    rfe28254 rdf05838  
    1 # Entity-Relationship Model v.01
     1# Entity-Relationship Model v.02
    22
    33## Diagram
    44
    5 ![ERModel_v01](ERModel_v01.png)
    6 
    7 Attachments for this page: `ERModel_v01.xml` (TerraER source) and `ERModel_v01.png`
    8 (exported image). Open the source with TerraER 3.11:
    9 
    10 ```sh
    11 java -jar TerraER3.11.jar     # then File → Open → ERModel_v01.xml
    12 ```
     5![ERModel_v02](ERModel_v02.png)
     6
    137
    148Notation: Chen. Rectangles are entity sets, diamonds are relationships, ellipses

  • docs/P2-RelationalDesign/RelationalDesign.md

    rfe28254 rdf05838  
    9696![relational_schema](relational_schema.jpg)
    9797
    98 Generated in **DBeaver** from the **live** `project` schema, in crow's-foot
     98Generated in **Pgadmin** from the **live** `project` schema, in crow's-foot
    9999notation — not drawn by hand, so it is evidence that the deployed database
    100100actually matches the design described above. Each box is a table with its
    … …  
    103103
    104104### How to regenerate it
    105 
    106 **With DBeaver** (the tool the course recommends):
    107 
    108 1. Connect to the assigned FINKI PostgreSQL project database.
    109 2. Double-click the `project` schema → **ER Diagram** tab.
    110 3. Right-click in the diagram → **Notation** → **Crow's foot**.
    111 4. Arrange the tables to mirror the layout of
    112    [`ERModel_v01.png`](../P1-ConceptualModel/ERModel_v01.png).
    113 5. Right-click → **Export diagram** → save as `relational_schema.jpg`.
    114 
    115 On Linux, install it with:
    116 
    117 ```sh
    118 flatpak remote-add --if-not-exists --user flathub https://dl.flathub.org/repo/flathub.flatpakrepo
    119 flatpak install --user flathub io.dbeaver.DBeaverCommunity
    120 # or:  sudo snap install dbeaver-ce
    121 ```
    122105
    123106**With pgAdmin 4**, if DBeaver is unavailable — it reads the live schema the same
    … …  
    131114   `convert relational_schema.png relational_schema.jpg`
    132115
    133 Whichever tool is used, state it here so the choice is explicit rather than
    134 inferred. Do **not** substitute a tool that only reads the `.sql` file — such as
    135 dbdiagram.io — because the diagram would then show what the script says rather
    136 than what the deployed database contains, which is the thing this artefact is
    137 meant to demonstrate.

  • docs/P3-UseCaseModel/UseCaseModel.md

    rfe28254 rdf05838  
    1 # Use-case model
     1= Use-case model =
    22
    3 ## List of Actors / Roles
     3The detailed pages for this phase are kept in the project's GitHub repository,
     4[https://github.com/StefanTrsunov/bp StefanTrsunov/bp], under `docs/P3-UseCaseModel/`. Every
     5use-case link below opens the corresponding file there.
    46
    5 - **Visitor** — Anyone browsing the platform without an account. Can only view public market information.
    6   - [UC0001](UseCase0001.md) — Register new account
    7   - [UC0002](UseCase0002.md) — Log in
     7== Actors / Roles ==
    88
    9 - **Trader** — A logged-in user managing their virtual funds and positions.
    10   - [UC0003](UseCase0003.md) — Deposit virtual funds
    11   - [UC0004](UseCase0004.md) — Place market BUY order
    12   - [UC0005](UseCase0005.md) — Place market SELL order
    13   - [UC0006](UseCase0006.md) — View portfolio and transaction history
    14   - [UC0007](UseCase0007.md) — Manage watchlist
     9'''Visitor''' – Anyone using EduBerza without an account, who can look at public market
     10information, create an account, and log in.
    1511
    16 - **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.
     12'''Trader''' – A registered, logged-in user who deposits virtual funds, places market buy and
     13sell orders, follows the value of their portfolio, and keeps a watchlist of assets they want to
     14monitor.
    1715
    18 ## Use-case model diagram (optional)
     16'''Market Simulator''' – An external automated system (the bot in `bots/`) that writes simulated
     17trades and candles into the database so prices move without a connection to a real exchange.
    1918
    20 *(Optional per the rubric; include one later if time allows.)*
     19== Use-Cases ==
    2120
    22 ## Realization details on selection of the most important use cases
     21=== Visitor ===
    2322
    24 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.
     23 * [https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCase0001.md UC0001] –
     24   '''Register new account''' – Visitor creates an account with a unique username and e-mail; the
     25   password is stored as a SHA-256 hash.
     26 * [https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCase0002.md UC0002] –
     27   '''Log in''' – Visitor authenticates with username and password so the system treats every
     28   following action as a Trader.
    2529
    26 | Use case                               | Importance | Why documented                                                                            |
    27 |----------------------------------------|------------|-------------------------------------------------------------------------------------------|
    28 | [UC0001 — Register](UseCase0001.md)    | High       | Without it nothing else works; demonstrates `INSERT` with uniqueness check.               |
    29 | [UC0002 — Login](UseCase0002.md)       | High       | Authenticates every `Trader` action; demonstrates `SELECT` with parameter binding.        |
    30 | [UC0003 — Deposit](UseCase0003.md)     | High       | Shows a multi-row transaction: `UPDATE users` + `INSERT INTO transactions`.               |
    31 | [UC0004 — Buy](UseCase0004.md)         | Very high  | Core of the exchange: `INSERT orders`, `UPDATE users`, `UPSERT holdings`, ledger, trade.  |
    32 | [UC0005 — Sell](UseCase0005.md)        | Very high  | Dual of Buy; demonstrates row-level `FOR UPDATE` locking and cost-basis bookkeeping.      |
    33 | [UC0006 — Portfolio](UseCase0006.md)   | High       | Demonstrates joins over `holdings`, `markets`, `crypto`, and a view (`v_portfolio`).      |
    34 | [UC0007 — Watchlist](UseCase0007.md)   | Medium     | Demonstrates N-M relation handling and `ON CONFLICT` upsert semantics.                    |
     30=== Trader ===
     31
     32 * [https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCase0003.md UC0003] –
     33   '''Deposit virtual funds''' – Trader tops up their virtual cash balance; the user row and the
     34   ledger are written in one transaction.
     35 * [https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCase0004.md UC0004] –
     36   '''Place market BUY order''' – Trader buys a crypto asset at the current market price, which
     37   debits cash and upserts the holding at a running weighted-average price.
     38 * [https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCase0005.md UC0005] –
     39   '''Place market SELL order''' – Trader sells part or all of a holding at the current market
     40   price, which credits cash and preserves the cost basis.
     41 * [https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCase0006.md UC0006] –
     42   '''View portfolio and transaction history''' – Trader inspects current holdings, unrealised
     43   P/L, cash balances and the most recent ledger entries.
     44 * [https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCase0007.md UC0007] –
     45   '''Manage watchlist''' – Trader lists, adds and removes crypto assets on a personal watchlist,
     46   where adding an asset already on the list is a no-op.
     47
     48=== Market Simulator ===
     49
     50The Market Simulator initiates no use case of its own. It participates in
     51[https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCase0004.md UC0004] and
     52[https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCase0005.md UC0005]
     53indirectly, by keeping `project.market_trades` populated so that `project.v_latest_prices`
     54returns a current price for every active market.
     55
     56== Use-case model diagram ==
     57
     58{{{#!comment
     59The diagram is optional for P3. Commit the exported image to
     60docs/P3-UseCaseModel/use_case_diagram.png and then replace this comment with:
     61
     62[https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/use_case_diagram.png Use-case model diagram]
     63}}}
     64
     65== Detailed Use-Cases ==
     66
     67The following use-cases are documented in detail, with SQL tested against the P2 database:
     68
     69 * [https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCase0001.md UseCase0001] – Visitor registers a new account
     70 * [https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCase0002.md UseCase0002] – Visitor logs in
     71 * [https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCase0003.md UseCase0003] – Trader deposits virtual funds
     72 * [https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCase0004.md UseCase0004] – Trader places a market BUY order
     73 * [https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCase0005.md UseCase0005] – Trader places a market SELL order
     74 * [https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCase0006.md UseCase0006] – Trader views portfolio and transaction history
     75 * [https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCase0007.md UseCase0007] – Trader manages a watchlist
     76
     77== Realization details on selection of the most important use cases ==
     78
     79This is a solo project, so '''at least 3 use cases''' are required. '''7 use cases''' are
     80documented, for a safety margin. All seven are implemented in the P4 prototype; see
     81[https://github.com/StefanTrsunov/bp/tree/main/server server/] for the Go source and
     82[https://github.com/StefanTrsunov/bp/blob/main/docs/P4-Prototype/PrototypeImplementation.md PrototypeImplementation]
     83for the documented runs.
     84
     85||=Use case=||=Importance=||=Why it was selected=||
     86||[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.||
     87||[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.||
     88||[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`.||
     89||[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.||
     90||[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.||
     91||[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.||
     92||[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.||
     93
     94== AI usage ==
     95
     96AI was used in this phase and is logged in full, per the course rule for P1 onward.
     97
     98 * '''Phase log:'''
     99   [https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCaseModelAIUsage.md UseCaseModelAIUsage.md]
     100   – service used, what the AI produced, and what I decided myself.
     101 * '''Full conversation transcript:'''
     102   [https://github.com/StefanTrsunov/bp/blob/main/docs/P1-ConceptualModel/ERModelAIUsage.md ERModelAIUsage.md]
     103   – the same conversation produced the P1–P4 artefacts, so the complete prompt/response log is
     104   kept in one place. Direct links:
     105   [https://github.com/StefanTrsunov/bp/blob/main/docs/P1-ConceptualModel/ERModelAIUsage.md#session-1--2026-04-21 Session 1 – 2026-04-21],
     106   [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].
     107
     108'''Service:''' Claude Code (Anthropic), https://claude.com/claude-code – Claude subscription,
     109model Claude Opus 4.7 (1M context).
     110
     111'''In short:''' the AI proposed the actor taxonomy and drafted the seven use cases with their SQL
     112in session 1. In session 2 the use-case model itself was '''not''' changed – the only work was
     113re-executing every scenario, including the failure paths, against a live PostgreSQL 16 database.

  • docs/P4-Prototype/PrototypeImplementation.md

    rfe28254 rdf05838  
    1 # Prototype Implementation
     1= Prototype Implementation =
    22
    3 The prototype is a Go command-line application in `server/` that works against
    4 the `project` schema in PostgreSQL. It implements all seven use cases from
    5 [UseCaseModel](../P3-UseCaseModel/UseCaseModel.md) — the rubric requires at least three — with
    6 every database access shown as real, executed SQL. An auxiliary program in
    7 `bots/` simulates a live market so prices move while the prototype is running.
     3The prototype is a Go command-line application in
     4[https://github.com/StefanTrsunov/bp/tree/main/server server/] that works against the `project`
     5schema in PostgreSQL. It implements all seven use cases from
     6[https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCaseModel.md UseCaseModel]
     7– the rubric requires at least three – with every database access shown as real, executed SQL.
     8An auxiliary program in [https://github.com/StefanTrsunov/bp/tree/main/bots bots/] simulates a
     9live market so prices move while the prototype is running.
    810
    9 Build, configure, run and test instructions: [BuildInstructions](BuildInstructions.md).
     11Build, configure, run and test instructions:
     12[https://github.com/StefanTrsunov/bp/blob/main/docs/P4-Prototype/BuildInstructions.md BuildInstructions].
    1013
    11 ## Implemented use-cases
     14All pages listed below, together with the screenshots of each run, are kept in the project's
     15GitHub repository, [https://github.com/StefanTrsunov/bp StefanTrsunov/bp], under
     16`docs/P4-Prototype/`.
    1217
    13 | Page | Use-case | Source |
    14 |------|----------|--------|
    15 | [UseCase0001Implementation](UseCase0001Implementation.md) | Register a new account | `server/auth.go` |
    16 | [UseCase0002Implementation](UseCase0002Implementation.md) | Log in | `server/auth.go` |
    17 | [UseCase0003Implementation](UseCase0003Implementation.md) | Deposit virtual funds | `server/account.go` |
    18 | [UseCase0004Implementation](UseCase0004Implementation.md) | Place market BUY order | `server/trade.go` |
    19 | [UseCase0005Implementation](UseCase0005Implementation.md) | Place market SELL order | `server/trade.go` |
    20 | [UseCase0006Implementation](UseCase0006Implementation.md) | View portfolio and history | `server/portfolio.go` |
    21 | [UseCase0007Implementation](UseCase0007Implementation.md) | Manage watchlist | `server/watchlist.go` |
     18== Implemented use-cases ==
    2219
    23 Each page mirrors its P3 use-case page and adds the actual SQL emitted by the Go
    24 code plus a screenshot of the corresponding run against the live database.
     20||=Page=||=Use-case=||=Source=||
     21||[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]||
     22||[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]||
     23||[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]||
     24||[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]||
     25||[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]||
     26||[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]||
     27||[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]||
    2528
    26 ## What the prototype demonstrates about the database design
     29Each page mirrors its P3 use-case page and adds the actual SQL emitted by the Go code plus a
     30screenshot of the corresponding run against the live database. The screenshots are committed
     31alongside the pages, in
     32[https://github.com/StefanTrsunov/bp/tree/main/docs/P4-Prototype/screenshots docs/P4-Prototype/screenshots/].
    2733
    28 - **The current price is never stored as a column.** It is always the price of
    29   the most recent row in `market_trades`, read through the `v_latest_prices`
    30   view. Both the user's own fills and the bot's simulated trades feed the same
    31   table, so there is exactly one definition of "the price".
    32 - **Money movements are transactional.** Buying touches five tables — `orders`,
    33   `users`, `holdings`, `transactions`, `market_trades` — inside one transaction.
    34   A failed balance check rolls the whole thing back: after a rejected purchase
    35   there is no order row, no ledger entry and no holding. This is verified in the
    36   failure-path tests in [BuildInstructions](BuildInstructions.md).
    37 - **Constraints do real work.** `UNIQUE (user_id, crypto_id)` on `holdings` is
    38   what makes the `INSERT … ON CONFLICT DO UPDATE` upsert possible, so the
    39   weighted-average entry price is recomputed by the database in one statement
    40   instead of by a read-modify-write in application code.
    41 - **No identifiers are ever typed.** Markets are listed with their prices before
    42   any choice is made, and everything else is selected by symbol.
     34== What the prototype demonstrates about the database design ==
    4335
    44 ## Known limitations
     36 * '''The current price is never stored as a column.''' It is always the price of the most recent
     37   row in `market_trades`, read through the `v_latest_prices` view. Both the user's own fills and
     38   the bot's simulated trades feed the same table, so there is exactly one definition of "the
     39   price".
     40 * '''Money movements are transactional.''' Buying touches five tables – `orders`, `users`,
     41   `holdings`, `transactions`, `market_trades` – inside one transaction. A failed balance check
     42   rolls the whole thing back: after a rejected purchase there is no order row, no ledger entry
     43   and no holding. This is verified in the failure-path tests in
     44   [https://github.com/StefanTrsunov/bp/blob/main/docs/P4-Prototype/BuildInstructions.md BuildInstructions].
     45 * '''Constraints do real work.''' `UNIQUE (user_id, crypto_id)` on `holdings` is what makes the
     46   `INSERT … ON CONFLICT DO UPDATE` upsert possible, so the weighted-average entry price is
     47   recomputed by the database in one statement instead of by a read-modify-write in application
     48   code.
     49 * '''No identifiers are ever typed.''' Markets are listed with their prices before any choice is
     50   made, and everything else is selected by symbol.
    4551
    46 Deliberately out of scope for a first prototype, and the natural content of the
    47 later phases:
     52== Known limitations ==
    4853
    49 - Only `market` orders execute. `limit` is accepted by the schema
    50   (`orders.type`) but the matching logic is not implemented.
    51 - Passwords are SHA-256 without a salt. Adequate to demonstrate that the
    52   password itself is never stored; not adequate for real use. A proper
    53   password hash belongs in P9 (security).
    54 - Money is handled as `float64` in Go while the database columns are `numeric`.
    55   All arithmetic that must be exact — the weighted average — is done in SQL for
    56   that reason, but the Go side would need a decimal type for real use.
    57 - There is no connection pooling configuration and no explicit isolation level;
    58   both are P8 topics.
     54Deliberately out of scope for a first prototype, and the natural content of the later phases:
     55
     56 * Only `market` orders execute. `limit` is accepted by the schema (`orders.type`) but the
     57   matching logic is not implemented.
     58 * Passwords are SHA-256 without a salt. Adequate to demonstrate that the password itself is
     59   never stored; not adequate for real use. A proper password hash belongs in P9 (security).
     60 * Money is handled as `float64` in Go while the database columns are `numeric`. All arithmetic
     61   that must be exact – the weighted average – is done in SQL for that reason, but the Go side
     62   would need a decimal type for real use.
     63 * There is no connection pooling configuration and no explicit isolation level; both are P8
     64   topics.
     65== AI usage ==
     66
     67AI was used in this phase and is logged in full, per the course rule for P1 onward.
     68
     69 * '''Phase log:'''
     70   [https://github.com/StefanTrsunov/bp/blob/main/docs/P3-UseCaseModel/UseCaseModelAIUsage.md UseCaseModelAIUsage.md]
     71   – service used, what the AI produced, and what I decided myself.
     72 * '''Full conversation transcript:'''
     73   [https://github.com/StefanTrsunov/bp/blob/main/docs/P1-ConceptualModel/ERModelAIUsage.md ERModelAIUsage.md]
     74   – the same conversation produced the P1–P4 artefacts, so the complete prompt/response log is
     75   kept in one place. Direct links:
     76   [https://github.com/StefanTrsunov/bp/blob/main/docs/P1-ConceptualModel/ERModelAIUsage.md#session-1--2026-04-21 Session 1 – 2026-04-21],
     77   [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].
     78
     79'''Service:''' Claude Code (Anthropic), https://claude.com/claude-code – Claude subscription,
     80model Claude Opus 4.7 (1M context).
     81
     82'''In short:''' the AI proposed the actor taxonomy and drafted the seven use cases with their SQL
     83in session 1. In session 2 the use-case model itself was '''not''' changed – the only work was
     84re-executing every scenario, including the failure paths, against a live PostgreSQL 16 database.
     85
     86== AI usage ==
     87
     88AI was used in this phase and is logged in full, per the course rule for P1 onward.
     89
     90 * '''Phase log:'''
     91   [https://github.com/StefanTrsunov/bp/blob/main/docs/P4-Prototype/PrototypeImplementationAIUsage.md PrototypeImplementationAIUsage.md]
     92   – service used, the bugs found and fixed, the test evidence, and what I decided myself.
     93 * '''Full conversation transcript:'''
     94   [https://github.com/StefanTrsunov/bp/blob/main/docs/P1-ConceptualModel/ERModelAIUsage.md ERModelAIUsage.md]
     95   – the same conversation produced the P1–P4 artefacts, so the complete prompt/response log is
     96   kept in one place. Direct links:
     97   [https://github.com/StefanTrsunov/bp/blob/main/docs/P1-ConceptualModel/ERModelAIUsage.md#session-1--2026-04-21 Session 1 – 2026-04-21],
     98   [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].
     99
     100'''Service:''' Claude Code (Anthropic), https://claude.com/claude-code – Claude subscription,
     101model Claude Opus 4.7 (1M context).
     102
     103'''In short:''' session 1 rewrote the existing Chi/HTTP backend as the CLI prototype covering
     104UC0001–UC0007 and added the market bot. Session 2 was a review pass I asked for, which found and
     105fixed three bugs – a path-resolution bug that made the documented build instructions fail, an
     106infinite loop at end of input, and an error check in the wrong order that misreported database
     107failures as "Insufficient holding" – and replaced the read-modify-write holding update with a
     108single `INSERT … ON CONFLICT DO UPDATE`.

  • docs/README.md

    rfe28254 rdf05838  
    7777| File | Phase | What |
    7878|------|-------|------|
    79 | [`ERModel_v01.xml`](P1-ConceptualModel/ERModel_v01.xml) | P1 | TerraER source of the ER diagram |
    80 | [`ERModel_v01.png`](P1-ConceptualModel/ERModel_v01.png) | P1 | Exported diagram image |
     79| [`ERModel_v02.xml`](P1-ConceptualModel/ERModel_v02.xml) | P1 | TerraER source, current version |
     80| [`ERModel_v02.png`](P1-ConceptualModel/ERModel_v02.png) | P1 | Exported diagram image, current version |
     81| [`ERModel_v01.xml`](P1-ConceptualModel/ERModel_v01.xml) | P1 | TerraER source, first version (kept per P1 rules) |
     82| [`ERModel_v01.png`](P1-ConceptualModel/ERModel_v01.png) | P1 | Exported diagram image, first version |
    8183| [`../server/db/schema_creation.sql`](../server/db/schema_creation.sql) | P2 | DDL — drops and recreates the `project` schema |
    8284| [`../server/db/data_load.sql`](../server/db/data_load.sql) | P2 | DML — truncates and reloads sample data |
Note: See TracChangeset for help on using the changeset viewer.