vibecodeit

Build Amazing Marvin

YESreplaces $8/mosaves $96/yrback to the verdict

0%0 of 19 items done

Saved on this device only. Tick prerequisites first, then work the phases in order · do not start one until the checks above it pass.

A task system whose central mechanic is the day plan with a time budget: tasks carry estimates, the day refuses to silently accept more than fits, and the record of what you planned against what happened is what makes your estimates get better.

estimated effort multi-daythe files for this build are in the project pack

RuntimeTypeScript with a local application and SQLiteModelTasks with estimates, a day plan, and a completion recordTimeEvery timestamp stored in UTC with the local zone recordedReviewScheduled prompts driven by data, not by a calendarExportJSON and Markdown, complete

Before step 1

Everything below is assumed from the first step. Tick each one when you actually have it, not when you plan to.

  1. installfree

    Why Runs the local application.

    Get it nodejs.org, or nvm install 22. open ↗

    Verify node --version prints v22 or higher

  2. decidefree, and mildly deflating

    Why The budget is the constraint everything else checks against, and setting it to eight hours guarantees the system tells you nothing useful.

    Get it Look at a real week and count the hours you actually spent on planned work rather than meetings, interruptions and admin.

    Verify A number is written down with the reasoning behind it

  3. have readyfree, but it takes two weeks

    Why Estimate accuracy, rollover distribution and budget suggestion need real data, and synthetic data will confirm whatever you assumed.

    Get it Use the tool for two weeks before trusting the review, or import from an existing system with times.

    Verify Two weeks of plans with actual times exist

  4. decidefree

    Why Day plans, rollover and recurrence all depend on when a day starts, and someone working past midnight breaks the naive answer.

    Get it Decide the hour a new day begins for you and whether travel changes it. Write it down before phase 2.

    Verify A written note states the day start hour and travel behaviour

Data model

Create these before the first phase that stores anything. Changing a table later is the expensive kind of change.

- tasks(id, title, project_id, estimate_minutes, due_at, created_at, completed_at, dropped_at)
- day_plans(date, budget_minutes, planned_at, local_zone) · the budget is the constraint the day is checked against
- plan_items(day_plan_date, task_id, ordinal, estimate_at_plan_minutes) · the estimate is captured at planning time
- sessions(id, task_id, started_at, ended_at, source) · source is timer or entered_later
- outcomes(day_plan_date, planned_minutes, actual_minutes, completed_count, rolled_over_count)
- The estimate is snapshotted into the plan item, because comparing today's outcome against a later revised estimate tells you nothing.

Environment variables

These go in a .env file the app reads at startup. The pack's .env.example is this table as a file · copy it, never commit the filled-in version.

VariableNeededExampleWhere the value comes from
DB_PATHrequired~/.local/share/marvin/tasks.dbTasks, plans and time. Your working history.
DAY_START_HOURrequired4When a new day begins, so work past midnight lands on the right day.
DEFAULT_BUDGET_MINUTESrequired240The honest number, not the hopeful one. Four hours of planned work is a real day.
TIMER_PROMPT_MINUTESrequired180When a running timer prompts, so an abandoned one does not record sixteen hours.
ROLLOVER_ALERT_COUNTrequired5How many rolls before a task is surfaced. It usually needs breaking up or dropping.

The build, in order

  1. Tasks with honest estimates

    Every task carries a time estimate and you can see them accumulate.

    1. A handful of buckets. False precision is what kills estimating.

      Files src/estimate.ts

    2. An optional estimate is an absent estimate within a week.

      Files src/tasks.ts

    3. The total is what the day plan will check against.

      Files src/totals.ts

    done when · tick each as it passes
    watch out
    • A free-text minutes field produces false precision and slows down capture until people stop estimating, which removes the mechanic the whole system is built on. Use a coarse scale of a few buckets, which is fast to choose and accurate enough for a day budget.
    next phase

  2. A day that refuses to hold more than it can

    Planning past your budget is possible but never silent.

    1. Days differ. A budget you set is a budget you believe.

      Files src/plan.ts

    2. Blocking pushes planning out of the tool. Recording produces the review.

      Files src/plan.ts

    3. Comparing against a revised estimate later measures nothing.

      Files src/plan.ts

    done when · tick each as it passes
    watch out
    • Blocking overcommitment outright means people plan outside the tool the first time a real day demands it, and blocking is also wrong because some days genuinely are like that. Allow it, require an acknowledgement, and record it, so the review can show the pattern.
    next phase

  3. What actually happened

    You can compare the plan against the day without perfect timer discipline.

    1. Timer and after the fact. Recording the source keeps the data honest.

      Files src/time.ts

    2. Prompt past a threshold. Sixteen-hour sessions poison the comparison.

      Files src/time.ts

    3. Planned, actual, completed, rolled over. Four numbers that mean something.

      Files src/outcome.ts

    done when · tick each as it passes
    watch out
    • A system that only records time from a timer produces mostly empty data, because nobody starts a timer every time, and then the plan against actual comparison is built on nothing. Make entering time afterwards as easy as starting the timer and mark which is which.
    next phase

  4. Rollover that does not hide the problem

    Unfinished tasks carry forward visibly, with their history.

    1. The number is the signal. Rolling silently discards it.

      Files src/rollover.ts

    2. Past a threshold, distinctly. It is usually a task that needs breaking up or dropping.

      Files src/rollover.ts

    3. What you chose not to do is data about your planning.

      Files src/tasks.ts

    done when · tick each as it passes
    watch out
    • Silent rollover produces a task that has moved forward forty times and looks identical to one created this morning, which is the exact information you need and the exact information the interface hides. Count the rolls and show the count.
    next phase

  5. A review that shows you your own numbers

    You find out how wrong your estimates are, by how much, and in which direction.

    1. By project and size. The pattern is usually specific rather than global.

      Files src/review.ts

    2. The uncomfortable number. It is the one that changes planning.

      Files src/review.ts

    3. What you actually complete, not what you hoped to.

      Files src/budget.tssrc/budget.test.ts

    done when · tick each as it passes
    watch out
    • A review showing only completions is flattering and useless. The numbers that change behaviour are the ratio of actual to estimated time, how often you exceeded budget, and how long things sit before being done or dropped. Compute those even though they are uncomfortable.
what this build does not replace
after v1, if you want it

Need the files? The project pack on the verdict page hands your agent the whole brief · more tasks.