# Phase 0 — Columns to Rename / Add

**Purpose:** explicit list of every DB column being renamed AND every NEW column being added, derived from your sync spec. Each entry shows the Monday column ID it maps from, the OLD DB name (if any), and the NEW DB name. **No destructive migration runs until you sign off.**

Forms inputs (HTML `name=` attributes) are NEVER renamed — only DB columns. The FormRequest layer aliases them in `prepareForValidation()` so the existing signup forms continue to submit successfully.

---

## 1. `groups` table — column rename

| Current | New | Notes |
|---------|-----|-------|
| `user_type` | `type` | Values stay: `investor` / `startup` / `both` ([create_groups_table.php:14](database/migrations/2026_05_04_100002_create_groups_table.php#L14)) |

Plus add: `monday_group_id` (string, nullable, indexed) so the sync can map Monday's group identifier strings to our row.

---

## 2. Startups — rename existing DB columns

| Current DB column | New DB column | Maps from Monday | Rationale |
|-------------------|---------------|------------------|-----------|
| `company_brief` | `startup_brief` | `company_brief` | Spec wording |
| `compelling_factors` | `investment_opportunity` | `long_text0` | Spec wording |
| `kpi_with_funding` | `kpi_targets` | `long_text6` | Spec wording |
| `revenue_model_text` | `business_model` | `text__1` | Spec wording |
| `valuation_sar` | `valuation_amount_sar` | `numbers1__1` | Spec: `numbers1__1 → valuation_amount` |
| `valuation_formula` | `valuation` | `formula` | Spec: `formula → valuation` (formula stored as string) |
| `prior_financing_option_id` | `previously_received_funding_option_id` | `prior_financing_` | Spec: `prior_financing_ → previously_received_funding` |
| `previous_funding_sar` | `previous_funding_amount_sar` | `numbers` | Spec: `numbers → previous_funding_amount` |
| `heard_about_option_id` | `referral_source_option_id` | `status_13` | Spec: `status_13 → referral_source` |

---

## 3. Startups — NEW columns to add

| New DB column | Type | Maps from Monday | Notes |
|---------------|------|------------------|-------|
| `geographic_focus_option_id` *(or pivot)* | FK / pivot | `dropdown` | **Open question:** keep as multi-value `startup_locations` pivot (renamed) or store single value? Currently it's multi via [StartupItemMapper.php:219](app/Services/Monday/StartupItemMapper.php#L219) → see Q1 below |
| `subitem_members.job_type_option_id` | FK → label_options | subitem `status` | New: subitems already store `job_title_option_id` ([StartupItemMapper.php:313](app/Services/Monday/StartupItemMapper.php#L313)) — spec renames to `job_type` |
| `subitem_members.position_option_id` *(or pivot)* | FK / pivot | subitem `dropdown` | Currently multi-pivot `members_positions` → spec implies single field. See Q2 below |
| `subitem_members.nationality_option_id` | FK → label_options | subitem `nationality` (no `__1`) | Currently a free-text column. Promote to label FK |
| `subitem_members.is_founder` | bool | subitem `checkbox__1` | Currently stored as `founder` (bool); rename for clarity |

---

## 4. Investors — rename existing DB columns

| Current DB column | New DB column | Maps from Monday | Rationale |
|-------------------|---------------|------------------|-----------|
| `about` | `investor_bio` | `long_text` | Spec: `long_text → investor_bio` |
| `linkedin_url` | `linkedin_profile` | `link5` | Spec: `link5 → linkedin_profile` |
| `expected_yearly_investment_sar` | `expected_investment_per_year_sar` | `numeric` | Spec: `numeric → expected_investment_per_year` |
| `expected_yearly_investments_option_id` | `expected_annual_investments_option_id` | `status_mkktfrkq` | Spec: `status_mkktfrkq → expected_annual_investments` |
| `how_heard_option_id` | `referral_source_option_id` | `color1` | Spec: `color1 → referral_source` |
| `investment_knowledge_option_id` | `investment_experience_level_option_id` | `status_12` | Spec: `status_12 → investment_experience_level` |
| `has_exit_option_id` | `exit_experience_option_id` | `color2` | Spec: `color2 → exit_experience` |
| `is_in_other_angel_group_option_id` | **OPEN — see Q3** | `color8` | Spec maps `color8 → investor_type` but the existing label is "is in other angel group" — semantically different |

---

## 5. Investors — NEW columns to add

| New DB column | Type | Maps from Monday | Notes |
|---------------|------|------------------|-------|
| `last_name` | string | (none — signup form only) | Already added by [2026_05_11_223606 migration](database/migrations/2026_05_11_223606_add_last_name_to_investors.php) — preserve |
| `previous_investments_details` | text, nullable | `text4` | NEW per spec |
| `template_name_option_id` | FK → label_options | `status_mkkqyha` | NEW per spec |
| `payment_method` | string nullable *(or JSON array — see Q4)* | `dropdown_mksekwvt` | NEW per spec; was multi-pivot `methods` — see drop doc |
| `number` | decimal(20,2) nullable | `numeric_mkseahse` | NEW per spec. **Open Q5: column name "number" is vague — suggest renaming** |
| `investment_value` | string nullable | `formula_mkvxze1e` | Monday formula columns are computed; stored verbatim as string |
| `wishlist_value` | string nullable | `formula_mkw0fb6j` | Same |
| `formula_result` | string nullable | `formula_mkw94as` | Same. **Open Q6: name is vague — suggest renaming** |
| `demo_date` | string nullable *(or date — see Q7)* | `text_mkr99p9a` | Spec lists it as text; if it's actually a date column on Monday, use date type |
| `country_id` | FK → countries, nullable | (derived from `nationality_option_id`) | Backfill from label_options.name_en → countries.code. Keep `nationality_option_id` for one release as shadow |
| `city_id` | FK → cities, nullable | (derived from `color0` city_option_id) | Backfill from label_options.name_en → cities.name_en |

---

## 6. Files table — add `status` column

| New column | Type | Default | Notes |
|------------|------|---------|-------|
| `status` | enum('ready','pending_download','failed') | `ready` | Required by Phase 4 re-download command to track which files need refetching |

---

## 7. Open questions (please answer before Phase 2 migrations run)

### Q1. Startup `dropdown` (Geographic Focus) — multi-value pivot or single column?

Currently it's a **multi-value pivot** at [`startup_locations`](database/migrations/2026_05_06_000004_create_startup_locations_table.php) with one row per selected location ([StartupItemMapper.php:219](app/Services/Monday/StartupItemMapper.php#L219)). Spec implies a single `geographic_focus` field.

- **A.** Keep as multi-pivot, rename table `startup_locations` → `startup_geographic_focuses` (recommended — preserves data and Monday's natural multi-select)
- **B.** Collapse to a single `geographic_focus_option_id` FK (data loss for startups with >1 location)
- **C.** Collapse to a JSON column `geographic_focus` (preserves multi-value without a pivot)

### Q2. Startup subitem `dropdown` (member positions) — pivot or single?

Currently a multi-pivot `members_positions`. Spec says `dropdown → position`. Same three options as Q1.

### Q3. Investor `color8` — semantic change?

The existing Monday column `color8` is mapped as **"is in other angel group" (yes/no)**. Your spec says **`color8 → investor_type`**, which is a different concept (category like Angel/VC/Family Office).

- **A.** The Monday column genuinely was repurposed; rename DB column to `investor_type_option_id` and treat existing option values (Yes/No) as legacy data to be re-seeded with new option names
- **B.** Keep semantic meaning ("is in other angel group"); rename to `is_in_other_angel_group_option_id` is already that name — just clean it up
- **C.** Something else — please specify

### Q4. Investor `payment_method` — single string or multi-value JSON?

Currently `dropdown_mksekwvt` is treated as multi-select with a pivot table `methods`. Spec writes it as a single field. Is it actually single-value on Monday's side now?

- **A.** Single value — store as `payment_method` string column
- **B.** Multi-value — store as `payment_method` JSON array column (no pivot table)

### Q5. Investor `number` column name

`numeric_mkseahse → number` from your spec is a very generic name. What does this number represent? Examples: `score`, `priority`, `rank`, `sequence_number`. I'll use whatever you specify; otherwise default to literal `number` (not recommended — it shadows reserved keywords in some contexts).

### Q6. Investor `formula_result` column name

`formula_mkw94as → formula_result` is also generic. What does this formula compute? I'll rename to match semantic.

### Q7. Investor `demo_date` type — text or date?

Spec lists it as `text_mkr99p9a` (text column on Monday). If the date is always in `YYYY-MM-DD` format, store as `date`. If it's freeform text, keep as `string`. Default: `string nullable` until I see sample data.

### Q8. Investor `text4 → previous_investments_details` interaction with form input `previous_investments_count`

The signup form has a numeric input `previous_investments_count`. We're dropping that DB column (see drop doc). Three options for the form input handling — see drop doc Q1.

### Q9. Old DB columns — drop immediately or keep as deprecated shadows?

After renames, do you want me to:
- **A.** Drop the old columns in the same migration (cleanest, but a hot deploy could break briefly if a request lands between migration and code deploy)
- **B.** Keep both columns for one release, with the model's accessor reading the new name and writing both — drop in a follow-up migration (safer for production)

### Q10. Subitem changes — backwards compat for member positions?

If we collapse `members_positions` to a single field (Q2-B/C), do you want the migration to:
- **A.** Take the first position for each member (lossy)
- **B.** Concatenate all positions into the new field with a delimiter
- **C.** Keep the pivot, just rename it

---

## What is NOT being renamed

These already match the spec verbatim, no rename needed:

**Startups:** `cap_and_floor`, `market_size_tam`, `market_size_sam`, `market_size_som`, `problem`, `solution`, `min_ticket_size_sar`, `offered_equity_pct`, `asking_fund_sar`, `runway_months`, `fund_use_operation_sar`, `fund_use_marketing_sar`, `fund_use_development_sar`, `fund_use_salaries_sar`, `total_raised_sar`, `rejection_reason`, all label FKs not listed above.

**Investors:** `first_name`, `last_name`, `name`, `email`, `phone_number`, `joining_date`, `investments_count`, `investment_cap_sar`, `nationality_option_id` (kept until cities/countries migration deprecates it), `city_option_id` (same), `category_option_id`, `action_option_id`, `has_angel_invested_option_id`, `investment_method_option_id`, `average_ticket_option_id`.