The three NextSteps*.md files were per-session handoff notes that had gone stale; the plan they described is superseded. CLAUDE.md gains a MODEL TIERS section recording who is allowed to run as what: Opus coordinates, Sonnet implements, Haiku verifies, and no subagent runs on Opus.
6.6 KiB
These are TODOs and ideas from me, do not touch these unless explicitly told.
- The whole UX and user flow feels very off. Here we need to rethink. More of this below.
- We need to make it more clear if a plan has been selected / is active, so that you clearly can either remove the entire plan, or do additions to the existing plan. Or maybe rethink the entire plan part all together. More of this below.
- Let's remove the "tips" tab, those should probably be instead on the side of the calendar view and in a section in the overview to make it more clear. But hidden if there's nothing to say.
- Not sure what the "Mark working/day off" button and entire logic is about in the Calendar view. Probably remove?
- In the calendar view, red days are not shown. I would expect e.g. today's week and month to be fully covered but it is not. Sundays should always be marked red and in addition to that, also the other red days.
- A setting that says if "half days" are actually used by the employer (e.g. myself does not have those, but many do, so should be a toggle)
- According to Gemini, Försäkringskassan will remove the days on "lägsta nivå" first, meaning a tip (and how the planner should work) is to use the "sjukpenningnivå" days first always.
- We should remove, in the settings, the planning goal. Everything will always be "most money" because the tips we have are all related to maximising the use of both parental leave days + vacation days. So this can be simplified across planning + settings.
- The days after the child turns 4 are also cut strictly for each parent to save max 48 days. So this means that it is probably good to transfer days between the parants (if possible) beforehand so that both have more than 48 days. Example of a bad situation: One parent have 60 days and the other have 10 days. This will result in the first parent losing 12 days and the second parent keeping the 10, resulting in a total of 58 days when a total of 70 could have been achieved. So this should be a super important tip if the balance between the parents are "off" and the child's 4th birthday is coming up. Maybe the first 2 yeras (child being 0 and 1 years old) are ok, but after that the app should start to show this! To do it even better is if both parents have fetched/entered data for the child, then the app can show exactly the situation. Otherwise it will just have to do a "btw".
- On the overview in the bottom it says "48 / 96 weeks" for example for the remaining until age 4. This is wrong: It is not 96 weeks it is days. Plus we should make this more clear that it is actually 48+48 days (per parent) that can be saved. So if we can modify the progress bar to show how much each parent have left, that would be good.
- It seems like in the "plan" tab that UUIDs are being displayed instead of the user's (parents) actual names. A translation from user id to name should happen here. For example, it says "3d6c6b2e-e91d-450c-99d6-bc199a91dd57 has a large surplus" which is confusing.
User flow
This flow assumes that it is the first time the user uses this app. So no prior data exists.
- A user logs in
- The app shows that no child(ren) are registered and asks the user to fill that in. This can be done by manually adding the child, or by simply fetching data from Försäkringskassan, which then will give the app information about the amount of children and their names, to be auto-filled.
- Once the data is there (manually or automatic), the overview page can be displayed. The most important thing to show here is if (and if so, how many) any days are at risk of being lost when the child turns 4 years old. At the very start this is most probably the case, that a lot of days are at risk of getting lost.
- The user should be able to configure if the planning should happen for one or both parents directly, and this is then saved in the settings. (Another parent can later login and also connect to the same child/plan
- The user then heads over to the calendar tab, because now he/she wants to start planning.
The planning can happen in two ways:
5.1. The user might click-and-select dates in the calendar view directly and say what kind of day this is (parental leave vs vacation etc)
5.2. By selecting one of the "quick buttons" that should show somewhere on the page where it makes for good UX/UI (maybe on the side of the calendar view?) which correspond to the "preset buttons" on the now Plan tab, so "Summer (6 weeks)", "Winter (4 weeks)", "Autumn break (1 week)" etc.
If the user clicks one of the presets, the calendar view should imediately jump to the next upcoming time that preset can happen (i.e. if summer is pressed and we are in May, jump to July, if we are in September, jump to next year's July) and mark those weeks that the planner think is the best fit. The planner will also have selected the kind of time-off depending on what fits best.
Somehow (and here I need help of UX expert agent), the periods should be displayed as one section even though they might include multiple types of time-off (PL + vacation), and the type of time-off should also be visible on a per-day basis.
It should also be possible to click a time-off period and see that specific period (just like when you click on a multi-day event in your calendar on the phone) and there be able to change start/end date, the other things that can be changed and also importantly: The ability to "Repeat" (again, exactly like it is possible to do in a calendar app on your phone). Here the options should be "Don't repeat", "Every _ month" and "Every _ year" where 1 should be default but can be changed. That way a summer vacation can be repeated every year.
Basically, this whole thing is like a normal calendar with events that can stretch for multiple days, with the difference that each individual day within a range can have "time-off types" and that the app as a whole needs to keep track of the amount of days of specific types in order to know how many days are left for the future.
When an event is saved, that should trigger the planner (and whatever else needs to run) to run and re-evaluate things like tips etc. It can of course be that a user manually selected to have parental leave on a friday and then a monday, and then this is the time a new "tip" should be created saying something like "Hey, it is better if you take vacation here" or something like that.
When a user have selected that e.g. a summer vacation should "repeat every 1 year", it might be better to shift the start & end date to better fit red days in another year. These kind of things should happen when the event is saved, when the planner runs and can calculate this.