## Context
The Fidelity provider (commit 804e6a8) drives headless Chromium via
Playwright to refresh the PlanViewer session cookie jar and scrape the
Struts2 transaction history page. The image needs both the Chromium
runtime and the Debian system libs Chromium dynamic-links against.
## This change
- Adds Playwright's documented Debian 12 dependency set
(fonts-liberation, libnss3, libxkbcommon0, xvfb, etc.).
- Creates /app/.playwright-browsers owned by the broker user so the
non-root process can write the Chromium install, and runs `playwright
install chromium` as that user so the browser lands in the right
cache path (PLAYWRIGHT_BROWSERS_PATH=/app/.playwright-browsers).
- Image size will grow by ~300MB (Chromium headless shell is ~110MB
compressed, plus libs). Acceptable — broker-sync runs once a day so
pull cost is a one-shot.
## What is NOT in this change
- Terraform CronJob / monitoring — separate commit in the infra repo.
## Verification
$ docker build -t broker-sync:test . → (will run in CI)
$ docker run --rm broker-sync:test fidelity-seed --help → shows the
CLI help (can't actually run fidelity-seed headlessly).
$ poetry run pytest -q (local) → 128 passed, 1 skipped.
Reproduce locally:
1. docker build -t broker-sync:fidelity-test .
2. docker run --rm -v $PWD/tests/fixtures/fidelity:/data broker-sync:fidelity-test \
python -c "from playwright.sync_api import sync_playwright; \
with sync_playwright() as p: b = p.chromium.launch(); b.close(); print('ok')"
3. Expected: "ok" — Chromium launches successfully.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Context
-------
Two live-integration bugs surfaced during the Phase 0.5 auth-spike
run against the restored production Wealthfolio.
1. Wealthfolio 3.2's LoginRequest schema is `{ password: String }` —
it rejects any request with an unknown `username` field as HTTP
400 (empty body, hard to debug). Upstream source:
https://github.com/afadil/wealthfolio/blob/main/apps/server/src/auth.rs#L86-L88
2. Dockerfile referenced `/opt/poetry/bin/poetry` but pip install
puts poetry on the normal PATH; POETRY_HOME only affects the
self-installer, not `pip install`. Exit 127 in GHA build.
This change
-----------
- WealthfolioSink.login() sends `{password}` only; kept `username`
constructor arg as a stub for the day Wealthfolio adds multi-user.
- Dockerfile drops POETRY_HOME and uses `poetry` on PATH.
- Test: `_login_ok` now asserts body == {"password": "hunter2"}
("hunter2" is the XKCD placeholder — not a real credential).
Test plan
---------
## Automated
- poetry run pytest -q → 70 passed
- poetry run mypy broker_sync tests → Success: no issues found in 29 source files
- poetry run ruff check . → All checks passed!
## Manual Verification (executed live)
```
kubectl -n wealthfolio port-forward svc/wealthfolio 18080:80 &
WF_BASE_URL=http://localhost:18080 WF_USERNAME=admin \
WF_PASSWORD=<from-vault> \
poetry run broker-sync auth-spike
→ "Logged in. 1 account(s) visible."
```
Context
-------
Closes Phase 0 scaffolding. Image must build and run so infra can
schedule an initial no-op CronJob (the plan's Phase 0 exit criterion)
while Phase 0.5 / 0.75 / 1 land.
This change
-----------
- broker_sync/cli.py: typer app with two commands.
* `version` — prints __version__; used as the no-op CronJob
liveness check.
* `auth-spike` — Phase 0.5 end-to-end live probe: log in to
Wealthfolio, list accounts, exit 0 on success. Credentials read
from env (WF_BASE_URL/USERNAME/PASSWORD) so CronJob + ESO can
inject them without CLI flags.
- Dockerfile: multi-stage, Python 3.12-slim, non-root user 10001
with /data as the shared PVC mount. Poetry virtualenv baked into
/app/.venv, entrypoint is `broker-sync`, default command `version`.
- CLI test via typer.testing.CliRunner.
Test plan
---------
## Automated
- poetry run pytest -q → 32 passed
- poetry run mypy broker_sync tests → Success: no issues found in 19 source files
- poetry run ruff check . → All checks passed!
- poetry run broker-sync version → broker-sync 0.1.0
## Manual Verification
Docker build + run deferred — image will be built via GHA after the
repo is pushed to GitHub in a follow-up session; the pyproject install
has already been verified locally.
