Wire token-budget packing into the overview/rerank fallback path

This commit is contained in:
2026-08-10 12:02:31 +07:00
parent 60b4397032
commit 46469468bb
18 changed files with 768 additions and 38 deletions
+91
View File
@@ -1,5 +1,96 @@
# Progress Log
## 2026-08-10 (cont. 17) — First production deployment: EC2 + Docker + CI/CD, live at realvuxbaro.me
Owner and Codex agreed a work split mid-session
(`coordination/WORK_SPLIT_2026-08-10.md`): Codex owns `rag/**` (multi-query,
hybrid retrieval, fusion, guardrails); Claude owns deployment (Dockerfiles,
runtime env, Compose, hosting, CI/CD). Stopped the in-flight RAG bug-fixing
work (Aspirin/Warfarin/Vancomycin abstains, tasks 8/9) at the owner's
direction and pivoted entirely to standing up a real production deployment,
separate from the team's k3s/ArgoCD — a personal AWS account + a bought
domain (`realvuxbaro.me`, Namecheap).
**Infra provisioned** (`ai-lab-user`'s AWS account, confirmed personal by
the owner, not the team-shared one memory previously described): EC2
`t3.large` in us-east-1 (`i-039fc8f6102467a54`, Elastic IP `52.0.158.61`),
a dedicated security group (22/80/443), and an IAM instance role
(`duocthu-prod-ec2-role`) with the same Bedrock policies `ai-lab-user`
has — no long-lived AWS access keys anywhere on the server or in any env
file; boto3 picks up credentials from instance metadata.
**Containerized for the first time** — neither app had a Dockerfile before
today:
- `apps/ai-service/Dockerfile`: the flat module layout (`rag/`, `adapters/`,
`routers/` all top-level) isn't pip-installable as a package — setuptools
rejects "multiple top-level packages" — so deps are pip-installed
directly instead of via `pip install .`, plus `boto3` (used for Bedrock,
never declared in `pyproject.toml`).
- `apps/web/Dockerfile`: pnpm-workspace multi-stage build. Needed a new
root `.dockerignore` — a host `node_modules` from an earlier accidental
`npm run dev` (should have been `pnpm`) was copying over the container's
correctly pnpm-installed `node_modules` and breaking the Next.js build.
- `infra/docker/docker-compose.prod.yml` + `Caddyfile`: single-box
topology — postgres, qdrant, ai-service, web, Caddy for automatic Let's
Encrypt SSL. Redis/Prometheus/Grafana left out (redis is unused anywhere
in the live path; observability can come back later).
**Two real crash-loop bugs found and fixed, both packaging-assumption
bugs, neither RAG logic**:
1. `config.py`'s `entities_path` default did
`Path(__file__).resolve().parents[2]` to find the repo root and load
`ingestion/data/verified/drug_entities.json` — assumed a full monorepo
checkout depth. The deploy image flattens `apps/ai-service/` into `/app`,
so this raised `IndexError` at class-definition time, before any env
override could apply — crashed the container on every single start.
Fixed with a depth-guarded fallback in a small `_default_entities_path()`
helper, plus the file itself baked into the image and pointed at via
`ENTITIES_PATH` in `.env.prod`. 202/202 tests still pass.
2. `web`'s `CMD ["pnpm", "start", "--", "-p", "3000", "-H", "0.0.0.0"]`
didn't forward the flags through pnpm to `next start` in this pnpm
version — `next` received `-p` as a literal project-directory argument
and crashed every time. Fixed by invoking `next`'s own binary directly,
sidestepping pnpm's arg-forwarding.
**Qdrant data migrated via snapshot, not re-embedded** — free and exact,
no new Bedrock spend: snapshotted both `duocthu_v1` (15,100 points) and
`duocthu_v1__manifest` locally, scp'd the ~118MB total to the server, and
restored via Qdrant's multipart `/snapshots/upload` endpoint (first attempt
used `PUT` with a raw body per a wrong guess at the API shape — 404;
`POST` with `-F` multipart is correct). Verified live on the server after
restore: `points_count: 15100`, `status: green` — and confirmed it
survived Compose recreating the container afterward (named volume, not the
container, holds the data).
**DNS**: `realvuxbaro.me`'s existing Namecheap ALIAS/CNAME records (pointed
at Namecheap's own parking page) replaced with `A` records for `@` and
`www``52.0.158.61`. Caddy's automatic ACME issuance failed twice before
DNS propagated (expected — logged, not a bug), then succeeded within
seconds of a manual restart once `nslookup` confirmed propagation.
**End-to-end live-verified in the actual browser over real HTTPS**
(not curl): `https://realvuxbaro.me` — asked about Amoxicillin
contraindications, got correctly routed to `AMOXICILIN` and a genuine
absolute-vs-relative clarifying question with working quick-reply chips.
Full round trip through Caddy → web → ai-service → Qdrant/Postgres →
Bedrock, all over the public domain.
**CI/CD**: `.github/workflows/deploy.yml` — push to `master` SSHes into
the box (key + host in GitHub Actions secrets, `EC2_SSH_KEY`/`EC2_HOST`),
`git reset --hard origin/master`, rebuilds+restarts only `ai-service`/`web`
(postgres/qdrant/caddy untouched), runs migrations, health-checks both
services. First real run (triggered by its own commit) succeeded in 21s;
site confirmed still up and correct after.
**Explicitly deferred, not done this session**: no real k3s/ArgoCD (owner
asked about it mid-session, decided current Docker-image approach is easy
to migrate to later since the hard part — containerizing — is already
done); the 3 persistent RAG abstains and 2 minor precision bugs from
cont. 13's audit are untouched, back with Codex per the work split;
`api-gateway`/`auth-service`/`chat-service` still unbuilt scaffolds — this
deployment is `web` talking directly to `ai-service`, same as local dev,
now just reachable over the internet with no additional auth layer.
## 2026-08-10 (cont. 16) — Recovered from the machine-trouble cutoff: Bug 2 live-reverified, quarantine path conclusively exercised, retry rate remeasured
Picked up exactly where cont. 15 left off. Docker Desktop was down (machine