> ## Documentation Index
> Fetch the complete documentation index at: https://docs.zeus.ttr.gg/llms.txt
> Use this file to discover all available pages before exploring further.

# Plans MVP BVT

> Business verification test for Zeus's current Plans MVP capabilities

## 1. document purpose

This document is the **business verification test (BVT)** for the current **Plans MVP** release in Zeus.

Its purpose is to give product, operations, QA, design, and stakeholders one practical checklist that answers two questions:

1. What Plans features are available to use right now?
2. How do we verify that each feature works well enough for internal use, demos, and pilot validation?

This is a business-facing verification document. It focuses on user-visible capabilities and expected outcomes, not technical implementation.

## 2. current feature set available now

The current Plans MVP supports the following user-facing capabilities.

### Available now

| Capability                       | What the user can do now                                                                              |
| -------------------------------- | ----------------------------------------------------------------------------------------------------- |
| Monthly plan creation            | Create a monthly plan from expected income, fixed expenses, one primary goal, and lifestyle mode      |
| Recommendation-driven allocation | Receive an allocation across fixed expenses, essential spending, goal contribution, and safe-to-spend |
| Plan activation                  | Activate a draft plan for the current month                                                           |
| In-month dashboard               | View remaining safe-to-spend, daily guide, goal progress, warning state, and streak                   |
| Manual progress logging          | Log discretionary spend and goal contribution directly from Plans                                     |
| Daily transaction reminder       | Enable one fixed-time daily reminder delivered to the in-app notifications inbox                      |
| Warning and rebalance            | Receive a warning when pace drifts and accept one recommended corrective action                       |
| Month-end reflection             | Review planned versus actual results after a month closes                                             |
| Historical plans                 | Open prior months and inspect completed plan summaries                                                |

### Explicitly not part of this BVT

The following items are still outside the MVP verification scope:

* Variable-income planning
* Multiple simultaneous plan goals
* Browser push notifications or email reminders
* AI-generated month-end summaries
* Advanced adaptive learning across repeated months

## 3. business readiness bar

The release is considered **business-ready for internal use and pilot validation** when all of the following are true:

* A user can create and activate a monthly plan without external explanation.
* A user can understand their current monthly health within a few seconds of opening Plans.
* A user can turn on a daily reminder and receive it in the in-app inbox at the selected time.
* A user can accept a warning recommendation and see the plan update immediately.
* A user can reopen a completed month and understand what happened plus what to do next.

## 4. test prerequisites

Before running this BVT, the tester should have:

* A valid user account with access to the web app
* At least one financial goal created
* Ability to create or edit transactions manually
* Access to the notifications inbox
* Ability to create a current-month plan and wait for or simulate a new month if month-end scenarios are being verified live

Recommended test setup:

* Use one current-month test plan with a linked goal
* Use predictable amounts so planned versus actual changes are easy to validate
* Keep one second user account available if a clean-state test is needed
* Admin operators can use the manual Plans trigger in Settings > AI Insights to run plan jobs immediately for one user instead of waiting for cron timing during internal verification

### Deterministic test data for BR-5, BR-6, and BR-7

Use the following sample data if the tester wants a repeatable path with minimal judgment:

| Field                                    | Suggested value                             |
| ---------------------------------------- | ------------------------------------------- |
| Expected monthly income                  | 3000                                        |
| Fixed expenses                           | 1200                                        |
| Primary goal monthly contribution target | 600                                         |
| Lifestyle mode                           | Balanced                                    |
| Reminder time                            | 5 to 10 minutes ahead of current local time |

Suggested log events for warning tests:

| Test intent                   | Suggested action                                                                                                  |
| ----------------------------- | ----------------------------------------------------------------------------------------------------------------- |
| Trigger spend warning quickly | Log one large discretionary transaction that clearly consumes most of the current safe-to-spend allowance         |
| Trigger goal warning          | Keep discretionary spend low but do not log goal contributions until the plan falls materially behind target pace |
| Create month-end variance     | End the month with discretionary actual above plan or goal actual below target                                    |

If the team wants a faster test path in a non-production environment:

* Run the daily plans cron job manually instead of waiting for the reminder time
* Or use the admin Plans manual trigger for the selected user to run the same lifecycle immediately
* Use an older active plan month to verify automatic month-end completion and reflection

## 5. end-to-end BVT scenarios

### BVT-1 create and activate a plan

**Purpose**

Verify that the user can create a recommendation-based monthly plan and activate it.

**Steps**

1. Open Plans with no active plan for the current month.
2. Start plan creation.
3. Enter expected monthly income.
4. Enter fixed expenses.
5. Select one primary goal.
6. Select a lifestyle mode.
7. Submit the plan.
8. Open the draft plan if needed and activate it.

**Expected result**

* A plan is created for the current month.
* The plan includes fixed expenses, essential spending, goal contribution, and safe-to-spend.
* The plan can be activated successfully.
* The active plan appears on the Plans dashboard.

### BVT-2 review active dashboard state

**Purpose**

Verify that the active dashboard shows the user’s in-month control layer clearly.

**Steps**

1. Open an active monthly plan.
2. Review the top-level dashboard.

**Expected result**

* Remaining safe-to-spend is visible.
* A daily safe-to-spend guide is visible.
* Goal contribution progress is visible.
* Current plan state is visible as on track, watch, or at risk.
* Streak count is visible.
* The dashboard is understandable without opening raw transactions first.

### BVT-3 log manual plan progress

**Purpose**

Verify that manual spending and saving updates keep the plan current.

**Steps**

1. Open the active plan.
2. Use the manual logging action.
3. Add discretionary spending.
4. Optionally add direct goal contribution.
5. Save the update.

**Expected result**

* The updated discretionary spend appears in the dashboard.
* Remaining safe-to-spend changes immediately.
* Daily guidance updates.
* Goal progress updates when savings are logged.

### BVT-4 configure and receive the daily reminder

**Purpose**

Verify BR-5: the user can enable a single daily reminder and receive it through the inbox.

**Recommended setup**

* Start from an active current-month plan
* Choose a reminder time a few minutes ahead of the current local time
* Keep Notifications and Transactions accessible in separate tabs if useful

**Steps**

1. Open the active plan.
2. Turn the reminder on.
3. Select a reminder time.
4. Save the reminder.
5. Wait until the reminder time is reached, run the daily plans job in a test environment, or use the admin Plans manual trigger for that user.
6. Open Notifications.
7. Open the reminder CTA.

**Expected result**

* Reminder settings save successfully.
* One reminder is created for that local day.
* The reminder appears in the notifications inbox.
* The CTA opens transaction input directly.
* Reopening Notifications the same day does not create duplicate reminders for the same plan/day.

**Pass notes**

* If the reminder is triggered by the job rather than real time, the business outcome is still considered valid as long as the user-visible reminder appears correctly
* The reminder is in-app only for MVP and does not require browser push or email delivery

### BVT-5 trigger a warning and dismiss it

**Purpose**

Verify that drift is surfaced clearly and can be dismissed without breaking the plan.

**Steps**

1. Start from an active plan.
2. Log enough discretionary spend or too little goal progress to push the plan off pace.
3. Reopen Plans if needed.
4. Dismiss the warning.

**Expected result**

* A warning appears with clear plain-language explanation.
* The warning indicates why the plan is at risk or under watch.
* The user can dismiss the warning.
* The plan remains active after dismissal.

### BVT-6 accept the recommended rebalance

**Purpose**

Verify BR-6: the user can accept one corrective action and see the plan rebalanced.

**Recommended setup**

* Start from an active plan with a visible safe-to-spend value
* If a fast path is needed, log a large discretionary transaction early in the month so the pace breach is obvious

**Steps**

1. Trigger a warning on an active plan.
2. Choose `Accept recommendation`.

**Expected result**

* The plan updates immediately.
* For spending drift, remaining discretionary room becomes tighter.
* For goal drift, goal contribution target increases and discretionary room adjusts down.
* Daily guidance refreshes after the rebalance.
* The action feels like one clear correction, not a manual editing flow.

**Business interpretation**

* The tester does not need the exact underlying formula to validate the feature
* The core pass condition is that Zeus identifies drift, recommends one clear action, and visibly updates the plan in a direction that matches the warning

### BVT-7 month-end auto-close and summary

**Purpose**

Verify BR-7: the prior month closes automatically and produces a useful reflection.

**Recommended setup**

* Use an active plan from a prior month if available
* If not, use a controlled environment where the daily plans job can be run after the calendar month changes

**Steps**

1. Use an active plan from a prior month or move into a new month in a controlled test environment.
2. Open Plans, run the daily plans job, or use the admin Plans manual trigger for that user.
3. Open the completed plan from history.

**Expected result**

* The prior month is no longer active.
* The prior month appears as completed.
* The plan detail view shows planned versus actual discretionary spend.
* The plan detail view shows planned versus actual goal contribution.
* The plan detail view shows one deterministic next-cycle suggestion.

**Pass notes**

* The summary should be understandable without reading raw transactions first
* The next-cycle suggestion should feel concrete and directionally correct even though it is rule-based rather than AI-generated

### BVT-8 month-end notification

**Purpose**

Verify that the user receives a post-cycle prompt to review the completed month.

**Steps**

1. Complete BVT-7.
2. Open Notifications.
3. Open the month-end review CTA.

**Expected result**

* One month-end notification appears for the completed plan.
* The CTA opens the plan summary.
* The notification does not duplicate once already sent for that completed plan.

### BVT-9 review historical plans

**Purpose**

Verify that completed plans remain useful after the current cycle changes.

**Steps**

1. Open Plans with both a current plan and at least one completed historical plan.
2. Review the historical list.
3. Open one completed month.

**Expected result**

* Historical plans are visible and identifiable by month.
* Completed plans show useful summary context.
* The user can inspect prior results without affecting the current month.

## 6. feature-by-feature acceptance checklist

| Feature                 | Pass condition                                                      |
| ----------------------- | ------------------------------------------------------------------- |
| Plan creation           | Recommendation is generated from user inputs and saved successfully |
| Plan activation         | A draft becomes the active plan for the month                       |
| Safe-to-spend dashboard | Remaining monthly and daily guidance update after progress changes  |
| Goal progress           | Goal contribution target and actual progress are visible            |
| Manual plan logging     | Spending and savings logs affect plan state immediately             |
| Reminder settings       | User can enable, disable, and set one reminder time                 |
| Reminder delivery       | One in-app reminder appears at the scheduled local time             |
| Warning card            | User sees one warning with explanation and clear choices            |
| Rebalance accept        | User can accept the recommendation and see updated values           |
| Warning dismiss         | User can dismiss the warning without breaking the active plan       |
| Month-end closure       | Prior active month transitions to completed automatically           |
| Month-end summary       | Completed plan shows planned versus actual plus one suggestion      |
| Historical browsing     | Users can reopen completed plans later                              |

## 7. edge cases to verify before pilot use

* User has no active plan for the current month but does have historical plans
* User creates a plan without linking a goal
* User enables a reminder and later disables it
* User logs spend only, save only, or both
* User dismisses a warning and later causes a new drift event
* User rebalances after a warning and the warning state clears
* User has a completed month but no month-end notification yet
* User opens the transaction CTA from a reminder more than once

## 8. recommended smoke path for demos

If a stakeholder demo needs the shortest convincing path, run this sequence:

1. Create and activate a plan
2. Show current safe-to-spend and daily guide
3. Turn on the daily reminder
4. Log spending to trigger a warning
5. Accept the rebalance recommendation
6. Open a completed historical month and show the summary

This path demonstrates the full operating model:

* setup
* live guidance
* reminder
* intervention
* reflection

## 9. definition of pass

The current Plans MVP passes business verification when:

* All end-to-end scenarios in section 5 succeed
* No duplicate reminder or month-end notifications appear in normal use
* Rebalance actions visibly change the active plan in a credible way
* Completed months remain understandable without additional explanation
* Stakeholders can use the feature set in a demo without needing hidden admin-only steps