This morning before I went out, I threw together the plumbing and a very basic view for Edit Project.

My insistence on non-standard navigation patterns is coming to bite me in the ass. On the WIP view, Edit has to be invoked from the title menu (whats shown here) which shows an action sheet first. You can't present sheets on top of sheets in iOS, so I'll have to come up with something else.

Funnily enough, I ran into this problem at work too a year or two ago. Our solution then was to dismiss one sheet, then present the second one... which is honestly not great. I could push a new view onto the navigation stack instead but I'm not sure.

I haven't done a bunch today despite staying inside since I kind of want to unwind. However, in the spirit of daily progress, I cleaned up the sheet animation and had Claude refactor some of the code in this view so its not a mess.

Notably, before the Goal field (essentially a textarea) was hardcoded because textareas suck! But now we're using a GeometryReader to calculate how much space is left in the ScrollView and using that with a set min-height. This way, the field shrinks and expands as the keyboard is shown and hidden.

Design-wise, the header view has cancel and save buttons, but the bottom of the view is looking kinda lonely, so I'm going to think about that some more.

I kept going a little bit longer last night and wired up the view model, so saving your edits does work! When you save updates, the view underneath updates seamlessly, notably without a refresh.

In order to do that, I had to re-wire some of the views to use @Binding instead of @State in order to make the fields update properly. That turned out messier than I'm okay with, so I want to go back and find a cleaner way of doing it.

However, there also seems to be an API issue specifically when updating the project name, which you see in the beginning of the video. I think this has to do with slug-creation or something but I'm not sure, so this will be what I investigate next.

Just a quick update: I fixed and deployed the fix for the API error. It turns out it had to do with routing.

Creating and updating both use POST requests (due to something on web). On the API side, the routes were out of order, so every update request was being treated as a create request. I should probably just figure out how to get Svelte to properly send PUT/PATCH requests, but for now, the issue is fixed.

‎​‎​I've been busy doing things before I leave Japan, so progress has slowed. I did do some API and frontend work around limiting when a project's theme can be changed, so let's talk about that for a bit.

Themes are important in Maitsu because they will eventually determine how proficient you are in specific skills. I don't want people to be able to abuse things I have planned in the future, so themes can only be changed:

* If the project is currently in progress, and * If the project has less than 4 checkins (can't be completed yet)

Essentially, once a project is completed, cancelled or closed, the theme is locked and can no longer be changed. This will bite me in the ass when new themes get added, but that's a problem for future me.

Also, when a project is _completable_, its theme can't be changed either. This is so that people can't make themselves seem proficient in categories that they aren't.

This honestly might just be overkill because anyone can make a project in a theme they don't match and make dummy checkins for four days anyway, but hopefully that kind of malicious use doesn't happen for a while.

I didn't test yet, but I did implement editing checkins so we can call this project complete. There was an API issue I had to patch, but other than that, implementing edit for checkins was smooth sailing.

One nice thing that isn't in the video is the segmented control at the top of the sheet works for toggling between the checkin's content and milestone.

There is a lot of issues with checkin rendering though, specifically around newlines. There's honestly a lot of issues everywhere. My work never ends.