Harvy Developer Documentation
Harvy is a source-grounded intelligence system. This site documents the actual repository, its contracts, its standards, and the difference between local implementation and verified deployment.
Warning
A green local check is not proof of a deployed service, live connector, proxy egress, tenant isolation, or production data path. Every page must distinguish implemented, partial, planned, blocked, and unverified.
Start here
- Codebase map — where code lives and which module owns each boundary.
- API reference — routes implemented by the API Worker, with auth, scope, and source links.
- Engineering standards — the canonical coding, data, security, API, automation, and contribution rules.
- Implementation status — evidence-backed delivery ledger.
- Delivery plan — the single project plan; do not create competing planning documents.
- Repository and infrastructure index — current checkout and account evidence.
Architecture and data
- Dataset engineering — how to build large, provenance-preserving intelligence datasets.
- UI and analytics specification — product surfaces and acceptance criteria.
- Basin provisioning and Basin pipeline runbook.
- Deployment runbook.
- Connector policy and adoption gates.
- Connector evidence ledger.
Working rules
- Read DEVELOPMENT and PLAN before changing behavior.
- Read callers, tests, migrations, and Wrangler configuration before editing a boundary.
- Preserve tenant, workspace, product, and shared-record scope at every read and write.
- Keep provenance, source URLs, timestamps, collection method, coverage gaps, and evidence limitations.
- Treat local fixtures and templates as local proof only. Live acceptance must have live evidence.
- Record blocked and unverified work instead of silently bypassing a gate.
Source of truth
Canonical content is maintained in the repository’s docs/ directory. The Quartz build reads that directory directly, so this site is not a second hand-edited documentation tree.