💡 Hive lifecycle automation with split, combine, and requeen lineage tracking

[github-actions[bot]]

Summary

Automate tracking of complex hive operations — splits, combines, requeening — with automatic history inheritance, queen lineage graphs, and merged recommendation context. When a beekeeper splits Hive A into A1 and A2, both daughter hives inherit relevant history, and the system tracks queen genetics across generations to inform future breeding recommendations.

Market Signal

No competing beekeeping app tracks hive lifecycle operations with history inheritance. HiveTracks, HiveSense, Apiary Book, and Beezum all treat hives as static entities that can be created and deleted but not linked to parent/daughter relationships. Sideliner beekeepers performing 10-20+ splits per spring currently track this on paper or spreadsheets, losing the data linkage that powers informed management decisions. Queen rearing and genetic selection is a growing interest area in the hobbyist-to-sideliner transition.

User Signal

The PRD defines the Elena persona (Sideliner, 50+ hives) as needing "operational clarity" for batch operations. Epic 7 (Hive CRUD) defines basic create/update/delete but no lifecycle operations. No existing Ideas Discussion addresses split/combine tracking or queen lineage. The architecture's domain model includes hive and inspection tables but no parent-child hive relationships. This is a gap in both the domain model and the UX.

Technical Opportunity

Requires a hive_lineage table with parent_hive_id, operation_type (split/combine/requeen), and timestamp — a directed acyclic graph that PostgreSQL handles well with recursive CTEs via sqlc-generated queries. The recommendation engine can use lineage data to compare outcomes across sister colonies and suggest breeder queens from high-performing genetic lines. Progressive disclosure in the UI keeps lifecycle operations hidden from newbies until they are relevant to their skill level.

Assessment

Dimension	Score	Rationale
Feasibility	high	Clean domain model extension; recursive CTE queries are well-understood in PostgreSQL
Impact	med	Primary value for sideliner segment (highest willingness to pay); limited newbie value
Urgency	med	No competitive pressure (no one does this), but sideliner persona is key to revenue

Adversarial Review

Strongest objection: This is bookkeeping, not a differentiator. Newbies don't split hives, and sideliners can track this on paper. The data model complexity of a hive split from one that was combined from two others creates a graph, not a tree.

Rebuttal: This targets the sideliner persona specifically — the segment with the highest willingness to pay for premium features. Manual tracking breaks down at scale: when you've done 15 splits in spring, paper can't tell you which daughter colonies came from your best genetic stock. The real value emerges over time with accumulated data: "Daughter colonies from your Hive 7 queen line have 40% higher survival — consider using for next split." No competitor offers this genetic intelligence layer.

Suggested Next Step

Design the hive_lineage database schema (migration), define the split/combine/requeen mutation operations in the GraphQL schema, and create a UX wireframe for the lineage view integrated into the hive detail screen.