chore/frontend/vue-app/e2e/plans/bugs-1.0.6-set01.plan.md

E2E Test Plan — Bug Fixes 1.0.6 Set 1

Covers the bug fixes from .github/specs/bugs-1.0.6-01/bugs-1.0.6-set01.md. Each section proposes new E2E specs or additions to existing specs.

---

1. Assign View Shows Child Name

File: e2e/mode_parent/task-assignment/assign-title-shows-child-name.spec.ts Project: chromium-task-assignment

Seed: Create an isolated child with a known name via API. Create at least one chore, reward, kindness, and penalty task.

1.1. "Assign Chores" heading contains child name

• Navigate to /parent/{childId}/assign-chores?name={childName}
• Verify the heading text includes the child's name

1.2. "Assign Rewards" heading contains child name

• Navigate to /parent/{childId}/assign-rewards?name={childName}
• Verify heading

1.3. "Assign Kindnesses" heading contains child name

• Navigate to /parent/{childId}/assign-kindness?name={childName}
• Verify heading

1.4. "Assign Penalties" heading contains child name

• Navigate to /parent/{childId}/assign-penalties?name={childName}
• Verify heading

---

2. General Chore Approval — No COMPLETED Stamp

File: e2e/mode_parent/task-activation/general-chore-no-completed.spec.ts Project: chromium-task-activation

Seed: Create an isolated child, one general (unscheduled) chore, and one scheduled chore. Assign both to the child.

2.1. Approving a general chore awards points

• Click general chore → confirm in dialog → approve
• Verify child's points increase by chore value

2.2. General chore does NOT show COMPLETED stamp after approval

• After approval, verify the chore card does not contain "COMPLETED" text

2.3. General chore can be triggered again immediately after approval

• Click the same general chore again
• Verify the confirmation dialog re-appears (chore is re-triggerable)

2.4. Scheduled chore DOES show COMPLETED after approval (contrast)

• Trigger and approve the scheduled chore
• Verify "COMPLETED" stamp is visible on that card

---

3. Extend Time Removes TOO LATE Banner

Existing file: e2e/mode_parent/chore-scheduler/extend-time.spec.ts

The existing spec already has tests for "Extend Time removes TOO LATE badge" and "gray styling removed." The bug fix ensures refresh() is called immediately, so the existing tests should pass without page reload. If not already asserted:

3.1. TOO LATE disappears without page reload (addition to existing spec)

• After clicking "Extend Time," assert TOO LATE text is hidden within 3 seconds
• Do NOT call page.reload() between extension and assertion

---

4. Notification Card Overflow

File: e2e/mode_parent/notifications/notification-card-overflow.spec.ts Project: chromium-task-activation or new chromium-notifications

Seed: Create child + a chore with a very long name (50+ characters). Assign and trigger it so a notification is created.

4.1. Notification icon stays within card boundaries

• Navigate to notifications view
• Get the bounding box of the notification card and its icon
• Assert the icon's bounding box is fully contained within the card's bounding box

4.2. Long notification text does not visually overflow

• Assert the card element has appropriate overflow CSS (overflow: hidden or similar)
• Optionally use toHaveScreenshot() for visual regression

Note: This test benefits from visual regression testing (expect(page).toHaveScreenshot()) more than functional assertions, since overflow is inherently visual.

---

5. Override SSE Updates Child View

File: e2e/mode_parent/task-modification/override-sse-child-update.spec.ts Project: chromium-task-modification

Seed: Create child + one chore, one kindness, one penalty. Assign all to the child.

5.1. Changing chore override points updates child view in real time

• Open child view in the browser (goToChildView)
• Via API, set a point override on the chore: PUT /api/child/{id}/task/{taskId}/override
• Without page reload, verify the chore card displays the new point value

5.2. Changing kindness override points updates child view

• Same pattern for kindness task — set override via API, assert child view updates

5.3. Changing penalty override points updates child view

• Same pattern for penalty task

5.4. Deleting an override reverts child view to original points

• Remove the override via API
• Verify child view reverts to original point value without reload

---

6. Scroll to Edited Task After Save

File: e2e/mode_parent/task-modification/scroll-to-edited-task.spec.ts Project: chromium-task-modification

Seed: Create child + 10–15 chores and 5+ rewards (enough to require both vertical and horizontal scrolling). Assign all to the child.

6.1. Edited chore card scrolls into viewport after override save

• Navigate to parent child view
• Open override modal on a chore that requires scrolling to reach
• Save a new point value
• Assert the edited card toBeInViewport() after the list refreshes

6.2. Edited reward card scrolls into viewport after override save

• Open override modal on a distant reward
• Save, assert card toBeInViewport()

---

7. Task Sorting — Parent Mode

File: e2e/mode_parent/task-sorting/parent-sort-order.spec.ts Project: New chromium-task-sorting or chromium-chore-scheduler

Seed: Create child + 5 chores in different states:

1. A pending chore (child triggered, not yet approved)
2. A general (unscheduled) chore
3. An expired scheduled chore (today, deadline in the past → TOO LATE)
4. A completed scheduled chore (triggered + approved)
5. A chore scheduled on a non-today day (unscheduled for today)

Also create 2+ rewards: one with a pending request, one without.

7.1. Parent chore sort: pending → general → expired → completed → unscheduled

• Navigate to parent child view
• Read all chore card names in DOM order
• Assert the order matches: pending chore first, then general, then expired, then completed, then unscheduled-today

7.2. Parent reward sort: pending requests appear first

• Read all reward card names in DOM order
• Assert the pending-request reward appears before other rewards

---

8. Task Sorting — Child Mode

File: e2e/mode_parent/task-sorting/child-sort-order.spec.ts Project: Same as §7

Seed: Same child + tasks as §7, plus rewards with varying costs.

8.1. Child chore sort: scheduled today (earliest deadline first) → general → pending

• Switch to child view (goToChildView)
• Read all visible chore card names in DOM order
• Assert: scheduled-today chores first (sorted by deadline), then general, then pending
• Non-today chores should be hidden in child mode

8.2. Child reward sort: pending first, then ascending by points needed

• Read all reward card names in DOM order
• Assert: pending reward first, remaining sorted by ascending cost/points-needed

---

9. Notification Click Navigates and Scrolls to Task

File: e2e/mode_parent/notifications/notification-click-scroll.spec.ts Project: chromium-task-activation or new chromium-notifications

Seed: Create child + many chores (10+). Trigger one chore to create a pending notification. The triggered chore should be far enough in the list to require scrolling.

9.1. Clicking a chore notification navigates to parent child view

• Navigate to notifications page
• Click the pending chore notification
• Verify URL matches /parent/{childId} with scrollTo and entityType query params

9.2. Target chore card is scrolled into viewport after navigation

• After navigation from notification click, assert the target chore card toBeInViewport()

9.3. Works for reward notifications too

• Request a reward → navigate to notifications → click → verify reward card is in viewport

---

10. Pending Status Resets on Task/Reward Modification

File: e2e/mode_parent/task-modification/pending-reset-on-edit.spec.ts Project: chromium-task-modification

Seed: Create child + one chore + one reward. Assign both. Create a chore schedule.

10.1. Editing chore points clears pending status

• Trigger the chore (creates pending confirmation)
• Verify chore card shows pending state
• Edit the parent task's points via API: POST /api/task/{taskId}/edit with new points
• Refresh or wait for SSE — verify the chore card no longer shows pending state

10.2. Changing chore schedule clears pending status

• Trigger the chore again
• Set a new schedule via API: PUT /api/child/{childId}/task/{taskId}/schedule
• Verify pending is cleared

10.3. Editing reward cost clears pending reward request

• Request the reward (creates pending request)
• Edit the reward's cost via API
• Verify the reward card no longer shows pending state

10.4. Completed chores remain completed after point edit

• Complete and approve a scheduled chore so it shows COMPLETED
• Edit the parent task's points
• Verify the chore still shows COMPLETED stamp

10.5. Editing task name only (no point change) does NOT clear pending

• Trigger the chore
• Edit the task name only (points unchanged) via API
• Verify the chore still shows pending state

---

Summary

#	Area	Spec File	Tests	Priority
1	Assign view child name	task-assignment/assign-title-shows-child-name.spec.ts	4	Medium
2	General chore no COMPLETED	task-activation/general-chore-no-completed.spec.ts	4	High
3	Extend time TOO LATE	Existing chore-scheduler/extend-time.spec.ts	0–1	Low
4	Notification overflow	notifications/notification-card-overflow.spec.ts	2	Low
5	Override SSE child update	task-modification/override-sse-child-update.spec.ts	4	High
6	Scroll to edited task	task-modification/scroll-to-edited-task.spec.ts	2	Medium
7	Parent sort order	task-sorting/parent-sort-order.spec.ts	2	High
8	Child sort order	task-sorting/child-sort-order.spec.ts	2	High
9	Notification click scroll	notifications/notification-click-scroll.spec.ts	3	Medium
10	Pending reset on edit	task-modification/pending-reset-on-edit.spec.ts	5	High

Recommended implementation order: #2, #10, #7, #8, #5, #9, #6, #1, #3, #4

Notes:

• Bug #1 (uppercase verification code) is omitted from this E2E plan because reaching the PIN setup step requires email delivery; this is better covered by a component-level test on ParentPinSetup.vue.
• Bug #4 (extend time) is largely already covered by the existing extend-time.spec.ts — only a minor addition may be needed.
• Bug #5 (notification overflow) is best validated through visual regression (toHaveScreenshot()) rather than functional assertions.