# Sprint Change Proposal - Horizontal Multi-Table Detection

**Date:** 2025-11-27
**Author:** BMad Method - Correct Course Workflow
**Triggered by:** Code review of Story 3.1 (Table Boundary Detection)
**Scope:** Minor - Documentation + Future Enhancement Story

---

## Section 1: Issue Summary

**Problem Statement:**
The `TableDetector` implementation in Story 3.1 only supports detecting **vertically stacked** tables (separated by 2+ blank rows). **Side-by-side (horizontal)** tables are merged into a single table because the column detection logic spans from the first to last populated column across the entire row range.

**Discovery Context:**
During code review documented in `docs/multi_table_detection_review.md`, it was identified that FR10 ("System handles multiple tables per sheet") is only partially satisfied.

**Evidence from Review:**
```
The current logic does not support tables placed side-by-side
(e.g., Table A in cols A-C, Table B in cols F-H on the same rows).
- _get_first_populated_col finds the leftmost populated cell
- _get_last_populated_col finds the rightmost populated cell
- It treats the entire range (A:H) as a single table
```

**Recommendation from Review:**
> "Keep as is for MVP: Vertical stacking is the standard convention for machine-readable Excel files."

---

## Section 2: Impact Analysis

### Epic Impact

| Epic | Impact | Details |
|------|--------|---------|
| Epic 3 | LOW | Limitation documented, future story added |
| Epic 4-5 | NONE | Work with whatever tables are detected |

### Artifact Conflicts

| Artifact | Conflict? | Action Needed |
|----------|-----------|---------------|
| PRD | PARTIAL | FR10 partially covered (documented) |
| Architecture | NO | None |
| Epics Document | YES | Document limitation + add Story 3.1b |
| Sprint Status | YES | Add Story 3.1b to backlog |

---

## Section 3: Recommended Approach

**Selected:** Accept limitation for MVP + Add future enhancement story

**Rationale:**
- Vertical stacking is the standard convention for machine-readable Excel files
- Side-by-side tables are an edge case
- Adding horizontal detection now would delay MVP
- Documenting the limitation sets clear expectations
- Story 3.1b provides a clear path for future enhancement

**Effort:** Low (documentation only)
**Risk:** Low
**Timeline Impact:** None

---

## Section 4: Detailed Changes

### Change 1: Document Limitation in Story 3.1

Added to Technical Notes:
```
**Known Limitation:** Side-by-side tables (horizontal layout) are detected
as a single merged table. Only vertically stacked tables (separated by 2+
blank rows) are detected as separate tables. This is acceptable for MVP as
vertical stacking is the standard convention. See Story 3.1b for future
enhancement.
```

### Change 2: Add Story 3.1b (Post-MVP)

New story added for horizontal multi-table detection:
- Detects tables separated by empty columns
- Handles different header patterns per horizontal section
- Supports mixed vertical and horizontal layouts
- Priority: Post-MVP enhancement

### Change 3: Update Story Counts

- Epic 3: 10 → 11 stories
- Total: 32 → 33 stories

### Change 4: Update Sprint Status

Added: `3-1b-horizontal-multi-table-detection: backlog`

---

## Section 5: Implementation Handoff

**Change Scope:** Minor - Documentation only (no code changes)

| Deliverable | Status |
|-------------|--------|
| Story 3.1 limitation documented | ✅ Complete |
| Story 3.1b added to epics.md | ✅ Complete |
| Story counts updated | ✅ Complete |
| Sprint status updated | ✅ Complete |
| Review document preserved | ✅ Complete |

**No immediate implementation required.** Story 3.1b is backlogged for post-MVP consideration.

---

## Approval

- [x] Proposal reviewed by: TextIQ
- [x] Changes approved: Yes
- [x] Implementation: Documentation complete

---

_Generated by BMad Method - Correct Course Workflow_
_Date: 2025-11-27_