buildpulse/docs/TEST_PLAN.md

# BuildPulse v0.1 Test Plan

## Test Goal

Verify that BuildPulse v0.1 can manage one project, protect scope, log progress, and export useful AI handoff context.

## Manual Test Group 1 — Project Summary

### Test 1.1: Edit project summary

Steps:
1. Open app.
2. Edit project name.
3. Edit one-line pitch.
4. Edit current goal.
5. Refresh page.

Expected:
- Edited values persist after refresh.

### Test 1.2: Empty project fields

Steps:
1. Clear optional project fields.
2. Save.
3. Refresh.

Expected:
- App does not crash.
- Empty states are readable.

## Manual Test Group 2 — Feature Plan

### Test 2.1: Add feature

Steps:
1. Open Feature Plan.
2. Add new feature.
3. Enter title and description.
4. Save.

Expected:
- Feature appears in default column.
- Feature persists after refresh.

### Test 2.2: Move feature

Steps:
1. Move a feature from Now to Next.
2. Move it to Later.
3. Move it to Done.

Expected:
- Feature appears in the correct column each time.
- State persists after refresh.

### Test 2.3: Edit acceptance criteria

Steps:
1. Open feature detail.
2. Add acceptance criteria.
3. Save and close.
4. Reopen feature.

Expected:
- Acceptance criteria are saved and visible.

### Test 2.4: Delete feature

Steps:
1. Create a test feature.
2. Delete it.

Expected:
- Feature is removed.
- App remains stable.
- Related pulse events are either preserved with missing feature label or handled gracefully.

## Manual Test Group 3 — Parking Lot

### Test 3.1: Add parked idea

Steps:
1. Open Parking Lot.
2. Add an idea.
3. Add reason parked and risk level.

Expected:
- Item appears in Parking Lot.
- Item persists after refresh.

### Test 3.2: Convert parked idea to feature

If implemented in v0.1:

Steps:
1. Select Parking Lot item.
2. Convert to feature.

Expected:
- New feature is created.
- Original item is either removed or marked converted.

If not implemented:
- This test is skipped.

## Manual Test Group 4 — Pulse Log

### Test 4.1: Add INTENT pulse

Steps:
1. Open Pulse Log.
2. Add pulse type INTENT.
3. Link to a feature.
4. Add message and confidence.

Expected:
- Pulse appears in log.
- Feature name is shown.
- Pulse persists after refresh.

### Test 4.2: Add BLOCKER pulse without feature

Steps:
1. Add pulse type BLOCKER.
2. Do not link feature.
3. Save.

Expected:
- Pulse appears in log.
- App does not require feature link.

### Test 4.3: Filter pulses

If filtering is implemented:

Steps:
1. Add multiple pulse types.
2. Filter by RESULT.
3. Filter by feature.

Expected:
- Correct pulses are shown.

## Manual Test Group 5 — Export

### Test 5.1: Export full JSON

Steps:
1. Add project summary, features, parking items, and pulses.
2. Export full JSON.
3. Inspect file/content.

Expected:
- JSON contains schema version.
- JSON contains project.
- JSON contains features.
- JSON contains parking_lot.
- JSON contains pulses.

### Test 5.2: Import JSON

Steps:
1. Export JSON.
2. Clear app or use different browser.
3. Import JSON.

Expected:
- Data is restored.
- App does not duplicate IDs unexpectedly.

### Test 5.3: Export Pulse JSONL

Steps:
1. Add several pulses.
2. Export JSONL.

Expected:
- Each line is valid JSON.
- Each line represents one pulse event.

### Test 5.4: Export Markdown

Steps:
1. Export Markdown package.
2. Open `CLAUDE_CONTEXT.md`.

Expected:
- Contains project summary.
- Contains Now/Next/Later/Done features.
- Contains Parking Lot.
- Contains recent pulses.
- Is useful as an AI coder handoff.

## Manual Test Group 6 — Mobile Usability

### Test 6.1: Phone layout

Steps:
1. Open app in mobile-width browser.
2. Navigate all views.
3. Add feature.
4. Add parked idea.
5. Add pulse.

Expected:
- UI is usable on phone.
- No critical controls are inaccessible.

## Manual Test Group 7 — Scope Guard

### Test 7.1: Parking distracting idea

Scenario:
User thinks of “real-time OpenClaw integration.”

Steps:
1. Add it to Parking Lot.
2. Mark risk as high/dangerous.
3. Do not add it as active feature.

Expected:
- Idea is captured.
- Active v0.1 scope remains clean.

## Release Decision

v0.1 can ship when:
- All required happy paths pass.
- Data persists.
- Export works.
- App can manage BuildPulse itself.
- No forbidden v0.1 scope items have been implemented.