= 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.

Build, configure, run and test instructions: [BuildInstructions](BuildInstructions.md).

== Implemented use-cases

|| 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` ||

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.

== What the prototype demonstrates about the database design

- **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.

== Known limitations

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.