Codex/whe 15 bootstrap workspace (#1)

* feat(WHE-15): bootstrap bun workspace with app and package scaffolds

* chore(WHE-17): switch workspace typecheck to tsgo

* chore(WHE-16): configure oxlint and oxfmt no-semicolon style

* chore: address CodeRabbit review feedback

* chore: apply coderabbit fixes and add review script

* docs: add ADR decision metadata

docs/decisions/ADR-001-tech-stack.md

@@ -1,12 +1,18 @@
 # ADR-001: V1 Tech Stack
 
 ## Status
+
 Accepted
 
+Decision Date: 2026-03-05
+Owners: Stanislav Kalishin
+
 ## Context
+
 The project needs to be modern, modular, and scalable while still delivering v1 quickly.
 
 ## Decision
+
 - Runtime/package manager/test runner: Bun
 - Language: TypeScript (strict mode)
 - Bot framework: grammY
@@ -20,6 +26,7 @@ The project needs to be modern, modular, and scalable while still delivering v1
 - Logging/metrics baseline: Cloud Logging/Monitoring
 
 ## Rationale
+
 - Bun provides a fast unified developer workflow.
 - grammY is TypeScript-friendly with strong middleware patterns.
 - Supabase keeps SQL-first data modeling while reducing ops overhead.
@@ -28,15 +35,19 @@ The project needs to be modern, modular, and scalable while still delivering v1
 - Oxlint enables fast linting suitable for small-commit workflow.
 
 ## Consequences
+
 Positive:
+
 - Strong portfolio architecture with pragmatic service count.
 - Clear path to production without heavy platform ops.
 
 Negative:
+
 - Some enterprise tooling (Prometheus/Grafana/K8s) is deferred.
 - Serverless constraints require disciplined idempotency and stateless design.
 
 ## Alternatives Considered
+
 - Fly.io runtime: good DX, but Cloud Run better matches serverless objective.
 - Convex backend: strong DX, but SQL/reporting fit is weaker for financial ledger.
 - Telegraf bot framework: mature ecosystem, but less desirable TS ergonomics.

docs/decisions/ADR-002-hexagonal-architecture.md

@@ -1,13 +1,20 @@
 # ADR-002: Hexagonal Architecture (Ports and Adapters)
 
 ## Status
+
 Accepted
 
+Decision Date: 2026-03-05
+Owners: Stanislav Kalishin
+
 ## Context
+
 The project combines domain-heavy finance logic, Telegram integration, mini-app APIs, and scheduled jobs. Without strict boundaries, framework and infrastructure concerns will leak into core logic.
 
 ## Decision
+
 Adopt hexagonal architecture with explicit layers:
+
 - Domain: pure business model and invariants.
 - Application: use-case orchestration.
 - Ports: interfaces for repositories/services.
@@ -15,12 +22,14 @@ Adopt hexagonal architecture with explicit layers:
 - Composition root: runtime wiring only.
 
 ## Boundary Rules
+
 - Domain cannot import adapters, SDKs, HTTP, or SQL clients.
 - Application cannot import concrete adapter implementations.
 - Adapters can depend on SDKs and infra concerns but must implement ports.
 - Entry points create dependency graph and pass ports to use-cases.
 
 ## Module Layout
+
 - `packages/domain`
 - `packages/application`
 - `packages/ports`
@@ -28,23 +37,30 @@ Adopt hexagonal architecture with explicit layers:
 - `apps/*` for composition and delivery endpoints
 
 ## Rationale
+
 - Keeps financial logic testable and framework-independent.
 - Enables incremental replacement of adapters (e.g., parser provider).
 - Supports clean growth from v1 to larger-scale architecture.
 
 ## Consequences
+
 Positive:
+
 - High maintainability and clear ownership of concerns.
-- Better interview-readability of architecture.
+- Easier to explain architecture decisions in interviews.
 
 Negative:
+
 - Requires initial discipline and more explicit interfaces.
 - Slight boilerplate overhead for small features.
 
 ## Risks and Mitigations
+
 Risk:
+
 - Overengineering through too many tiny abstractions.
 
 Mitigation:
+
 - Create ports only for external boundaries and meaningful seams.
 - Keep use-cases focused; avoid generic base classes.