HerdOS Offline and Scale Validation

Purpose
- HerdOS must work where farms actually work: barns, chutes, parlors, pastures, and weak-signal areas.
- This file defines the validation plan for offline use, RFID collection, high-volume sync, and production-scale confidence.

Included validation tool
- Tool: outputs/tools/herdos-load-sim.js
- VS Code task: HerdOS: Offline Load Simulation
- Default run: generates 1,000 offline work records across 250 simulated animals without contacting the API.
- The report is written to the system temporary folder and shows record count, batch count, station routing, tenant scoping, and readiness flags.

Run from VS Code
1. Open Command Palette.
2. Choose Tasks: Run Task.
3. Run HerdOS: Offline Load Simulation.
4. Review the terminal report path.

Run from terminal
- Dry run:
  node outputs/tools/herdos-load-sim.js --records 1000 --animals 250 --batch-size 250 --dry-run

- API post test against a running local API:
  node outputs/tools/herdos-load-sim.js --records 1000 --animals 250 --batch-size 250 --endpoint http://127.0.0.1:4199/api/v1/sync/field-events --post

- Weak-network simulation:
  node outputs/tools/herdos-load-sim.js --records 1000 --animals 250 --batch-size 100 --weak-network-ms 750 --endpoint http://127.0.0.1:4199/api/v1/sync/field-events --post

Pilot test levels
- Level A: 1,000 records, 250 animals, 1 field device.
- Level B: 10,000 records, 2,500 animals, 3 field devices.
- Level C: 100,000 records, 25,000 animals, 10 field devices.
- Level D: 500,000+ records, 100,000 animals, production database only.

Acceptance targets
- Local offline entry should remain responsive during daily work.
- Field app outbox records should remain saved after browser close/reopen.
- Sync batches should be idempotent where possible, so retrying a batch does not create confusing duplicates.
- Duplicate RFID reads should highlight the existing row instead of adding another animal row.
- Health/vaccination records should route to Health and the correct health lane.
- Breeding records should route to Breeding and the animal profile.
- Movement records should update the animal's visible pen/location.
- Supplies records should route to Inventory.
- Dairy and Beef station context should remain separate except in shared Herd Registry.

Concurrency tests to document
- Two field devices edit the same animal offline, then reconnect.
- Owner edits an animal profile while a field device has pending work for the same tag.
- Support administrator opens a client workspace while the client is actively syncing.
- One device sends duplicate scan lists while another sends treatments for the same cattle.
- Weak network drops midway through a sync batch.

JSON store limitation
- The included JSON store is useful for demos, local validation, and pilot scaffolding.
- It is single-process and should not be treated as the final production database for large commercial use.
- Production scale should use PostgreSQL/Supabase/AWS RDS or equivalent managed storage, indexes, backups, and row-level security.

Production benchmark checklist
- Herd list under 2 seconds for common filters.
- Animal profile under 2 seconds with health, breeding, movement, and vaccination history.
- Sync ingestion accepts field batches without freezing the main app.
- RFID scan list can collect large chute sessions without UI lockups.
- Reports can summarize large date ranges without blocking daily entry.
- Backup restore drill has a measured recovery time.

Evidence to keep
- Store each load simulation report.
- Keep screenshots or notes from offline field-device tests.
- Keep API smoke-test output.
- Keep package checksum history.
- Keep pilot farm feedback separate from customer-facing screens.
