HerdOS Production Maturity Plan

Purpose
- This document converts the current maturity gaps into controlled development gates.
- Keep it as an owner/internal readiness file. It should guide engineering, pilots, funder discussions, and launch preparation without exposing private operating logic on customer screens.

Current maturity position
- HerdOS is an advanced prototype/pilot-ready platform with main, field, administrator support, API, offline, RFID, security, packaging, and VS Code workflows.
- The repository being new, private, and low in public activity is not a product weakness by itself. It simply means market proof, pilot evidence, and release discipline still need to be built.
- The JSON store is acceptable only for local demos and quick validation. Production multi-ranch use should run through the API with HERDOS_STORAGE_ADAPTER=postgres, managed PostgreSQL/Supabase/AWS RDS, and tested tenant isolation.

What to keep
- Keep the dual Dairy and Beef station model.
- Keep the field-first offline workflow.
- Keep global RFID reader flexibility.
- Keep tenant isolation, owner/manager login, administrator support, and back-and-forth support messages.
- Keep finance only on the main platform.
- Keep sensitive implementation details out of buyer-facing overview screens.

What to avoid for now
- Do not crowd farm screens with investor, architecture, pricing, or security implementation text.
- Do not promise formal national reporting, formal ICAR certification, or direct vendor reader certification until each integration is tested and documented.
- Do not replace the working local/PWA platform with a native-only app until the API and offline sync are proven.
- Do not open the repository publicly until trademark, security, licensing, and launch messaging are settled.

Gate 1: Demo and local pilot readiness
- Confirm main, field, and administrator dashboard open from VS Code preview.
- Run JavaScript syntax checks.
- Run security checksum verification.
- Run API smoke test for registration, login, duplicate email protection, bulk animals, and tenant isolation.
- Run the offline load simulation with at least 1,000 records.
- Rebuild the downloadable package and verify the package hash.

Gate 2: Field pilot readiness
- Test at least three named field devices under the same farm account.
- Confirm Field app A can sync without clearing or interfering with Field app B.
- Confirm each device label, department, site, and responsible user appears on synced records.
- Test no-internet cattle entry, RFID/manual tag collection, treatment, vaccination, pen move, breeding, maternity/calf care, supplies, and manual corrections.
- Confirm synced records land in the correct main workspaces.
- Confirm unknown RFID tags are captured and marked for registry review instead of being lost.

Gate 3: Production API/database readiness
- Run the PostgreSQL/Supabase storage adapter against a managed production database using DATABASE_URL and HERDOS_ALLOW_JSON_STORE=false.
- Enable authentication, tenant enforcement, HTTPS, rate limiting, backups, restore drills, and observability.
- Apply db/postgres-rls.sql and prove app_records plus normalized farm tables reject cross-organization reads and writes.
- Run multi-user concurrency tests with owner, manager, support administrator, and multiple field devices.
- Benchmark herd list, animal profile, sync ingestion, support messages, RFID scan list, and report endpoints.
- Test weak-network sync behavior using controlled latency, dropped connections, duplicate sync attempts, and conflict cases.
- Run at least two API replicas behind the target load balancer with HERDOS_RATE_LIMIT_STORE=postgres. A request sequence split across replicas must receive 429 after the shared policy limit, and either replica must be restartable without losing tenant isolation or health coverage.
- Capture release evidence: deployed image digest, migration revision, RLS probe output, multi-replica rate-limit result, backup snapshot identifier, restore elapsed time, and operator.

Gate 4: Market launch readiness
- Create private demo farms for dairy, beef, and mixed operations.
- Create a one-page buyer guide, quick-start guide, pricing sheet, and support policy.
- Define SaaS, self-hosted, and enterprise/private-cloud licensing.
- Document one pilot case study before public marketing claims.
- Prepare trademark filing, domain, production email, and support terms.

Minimum production acceptance checks
- Tenant isolation: a farm can never read another farm's animals, work records, support messages, devices, or finances.
- Offline safety: no record entered offline is lost when the app is closed and reopened.
- RFID safety: duplicate reads are visible without duplicating the animal entry.
- Sync routing: health, breeding, maternity/calf care, movement, inventory, sales, finance, reports, and dry cow records land in their correct areas.
- Security: secrets stay in .env or managed provider settings, never in app source files.
- Recovery: a database backup can be restored into a test environment in minutes, not days.

Measurable production gates
- PostgreSQL/RLS: use a non-superuser application role with no BYPASSRLS. In a production-like staging database, Tenant A must be unable to read, insert, update, or delete Tenant B rows in both herdos.app_records and a normalized table. A zero-row/denied result is required for every cross-tenant probe.
- Multi-replica: run two replicas with PostgreSQL-backed rate limiting. Split max + 1 equivalent client/tenant requests across the replicas; the final request must return HTTP 429 with Retry-After, not succeed because it reached another process.
- Field pilot: operate at least three named devices across at least two pilot farms for 14 consecutive days. Exercise offline entry, reconnect, duplicate delivery, RFID capture, health, movement, and a sync conflict. Require zero unacknowledged record loss and signed sample-record review by each pilot owner.
- Backup/restore: monthly and after each schema change, restore the latest managed PostgreSQL backup to an isolated staging database, compare animal/work-record/device/app-record counts to the backup manifest, and rerun the RLS probes. Require RTO under 5 minutes for pilot data and RPO of 24 hours or less.

Recommended next engineering order
1. Production database and RLS-backed tenant isolation.
2. Offline sync stress testing and conflict reporting.
3. RFID adapter certification/testing matrix.
4. Mobile app production build from the existing field workflow.
5. Commercial documents and pilot case studies.

Market launch blockers
- HerdOS should be described as prototype/pilot-ready, not enterprise-ready, until field pilots and production database operations are proven.
- Required proof before broad launch: 3-5 pilot farms, one real RFID reader workflow tested end to end, weak-network sync evidence, PostgreSQL or Supabase RLS running outside the JSON store, backup/restore drill evidence, monitoring, support runbooks, pricing validation, and at least one case study.
- The private repository is acceptable for IP protection now, but it is not a substitute for investor, partner, security, or customer validation.
- Named competitor research should stay in private sales/research materials. HerdOS customer screens should stay focused on HerdOS workflows, offline reliability, RFID readiness, compliance records, and support.
