philipp/orderbooks
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
orderbooks/docs/PRODUCTION_DEFINITION_OF_DONE.md
philipp 284e465588
Some checks failed
deploy / deploy (push) Has been cancelled
Details
Prepare Kubernetes orderbooks deployment
2026-04-18 11:23:28 +02:00

2 KiB
Raw Blame History

Production Definition Of Done

Status: ACTIVE

Defined at UTC: 2026-04-17T09:12:02Z

This project is done for the first production milestone only when it is reliably collecting Polymarket BTC order-book data on a small VPS with evidence on disk. Packaging, docs, local samples, and local soak tests are useful evidence, but not the finish line.

Done Means

  1. The collector runs on the VPS under systemd using /opt/orderbooks for code and /var/lib/orderbooks for data.
  2. Raw gzip JSONL order-book snapshots are written for active BTC up/down markets, with manifests beside them.
  3. The service survives a forced restart: after restart, a later collection cycle writes valid raw rows without corrupting prior files.
  4. Temporary network/API failure is handled as an operational failure, not data loss: failures are visible in logs/manifests, and the next successful cycle resumes writing new files.
  5. Google Drive upload runs from the VPS through rclone, verifies success, and leaves local files in place until upload is confirmed.
  6. A final production report and machine-readable manifest record exact commands, timestamps, files, checksums, restart result, upload result, and remaining risks.

Not Required For This Milestone

  • No second market.
  • No dashboard.
  • No database.
  • No strategy or backtest code.
  • No websocket rewrite unless polling proves insufficient.
  • No generic multi-market abstraction.

Maximum Remaining Builder Turns

The remaining work is capped at three builder turns:

  1. Accept deploy bundle and prepare the minimal VPS reliability gate.
  2. Execute or guide the VPS cutover and collect runtime evidence.
  3. Fix only blocking production issues found by the VPS gate, then write the final pass/fail report.

If actual VPS access is unavailable, the gate must be BLOCKED_NEEDS_VPS_ACCESS, not production ready.

Current Evidence

  • Deploy bundle gate: DEPLOY_BUNDLE_READY.
  • Local 24h soak final manifest exists but remains NEEDS_REVIEW.
  • Production readiness remains false until VPS runtime evidence exists.