Merge remote-tracking branch 'old-github/main' into integrate-old-refactors-of-github

docs/DESIGN_RECOMMENDATION_SUMMARY.md

@@ -7,6 +7,7 @@ Your current design has a **fundamental flaw** that prevents it from working cor
 ### The Problem
 
 The phase tables (`soaking`, `airdrying`, `cracking`, `shelling`) have this constraint:
+
 ```sql
 CONSTRAINT unique_soaking_per_experiment UNIQUE (experiment_id)
 ```
@@ -16,7 +17,8 @@ This means you can **only have ONE soaking record per experiment**, even if you
 ### Why This Happens
 
 When you create an experiment with 3 repetitions:
-1. ✅ 3 rows are created in `experiment_repetitions` 
+
+1. ✅ 3 rows are created in `experiment_repetitions`
 2. ❌ But you can only create 1 row in `soaking` (due to UNIQUE constraint)
 3. ❌ The other 2 repetitions cannot have soaking data!
 
@@ -25,6 +27,7 @@ When you create an experiment with 3 repetitions:
 ### Current Approach: Separate Tables (❌ Not Recommended)
 
 **Problems:**
+
 - ❌ UNIQUE constraint breaks repetitions
 - ❌ Schema duplication (same structure 4 times)
 - ❌ Hard to query "all phases for a repetition"
@@ -34,6 +37,7 @@ When you create an experiment with 3 repetitions:
 ### Recommended Approach: Unified Table (✅ Best Practice)
 
 **Benefits:**
+
 - ✅ Properly supports repetitions (one phase per repetition)
 - ✅ Automatic phase creation via database trigger
 - ✅ Simple sequential time calculations
@@ -45,7 +49,7 @@ When you create an experiment with 3 repetitions:
 
 I've created a migration file that implements a **unified `experiment_phase_executions` table**:
 
-### Key Features:
+### Key Features
 
 1. **Single Table for All Phases**
    - Uses `phase_type` enum to distinguish phases
@@ -68,7 +72,8 @@ I've created a migration file that implements a **unified `experiment_phase_exec
 ## Files Created
 
 1. **`docs/database_design_analysis.md`** - Detailed analysis with comparison matrix
-2. **`management-dashboard-web-app/supabase/migrations/00012_unified_phase_executions.sql`** - Complete migration implementation
+3. **`supabase/migrations/00012_unified_phase_executions.sql`** - Complete migration implementation
+
 
 ## Migration Path
 
@@ -81,6 +86,7 @@ I've created a migration file that implements a **unified `experiment_phase_exec
 ## Alternative: Fix Current Design
 
 If you prefer to keep separate tables, you MUST:
+
 1. Remove `UNIQUE (experiment_id)` constraints from all phase tables
 2. Keep only `UNIQUE (repetition_id)` constraints
 3. Add trigger to auto-create phase entries when repetitions are created
@@ -91,4 +97,3 @@ However, this still has the drawbacks of schema duplication and complexity.
 ## Recommendation
 
 **Use the unified table approach** - it's cleaner, more maintainable, and properly supports your repetition model.
-