I like when the day starts off easy. I pasted in my pre-written prompt to Claude, picking up right where I left off yesterday and immediately seeing my desired result—grid-bound metaballs.
Now that the metaballs never fully exit the grid, the logic I built yesterday to close the hands when the balls travel out of bounds never executes. Just kidding; yes it does. I need to remember that in one case, I’m tracking the position of the sphere, and in this new logic, I’m specifically tracking the position of the metaball. It would be prudent to add visuals to distinguish the spheres as well for debugging.
The remaining issue is with how far away the spheres will travel if left with velocity and without drag in the hands-closed state (I designed things this way to enable users to throw the energy balls off the screen). There are many possible ways for me to address this, but which is best for gameplay?
I’ll let that question ruminate. In the meantime, I want to tackle some low-hanging fruit related to deployments on this blog. I noticed yesterday that my post didn’t properly get moved to the /entries when running my auto-optimize script with pnpm, and therefore, a bunch of problems ensued as the rest of the optimization carried out. Images in the post never got renamed, but they still got added to /media and backed up to Google Drive. Once I manually moved my post to /entries and ran auto-optimize again, the media files all got renamed properly but the original files persisted along with their correctly-renamed versions.
Therefore, I need to ensure all .md files in the root of the /content folder that match the date naming convention for the blog posts get auto-moved into /entries when I run auto-optimize. This should happen at the very beginning of the optimization because it seems like a lot of other things go wrong when this doesn’t happen. Additionally, I need to safeguard against syncing incorrectly-named files to rClone and removing said files from /media if they aren’t being used in any posts. I know that I automatically move media files from /content into /media during optimization, but if those files never get properly renamed, they should get moved back into the root /content folder before I sync with rClone. I prefer that over deleting them entirely, just in case.
With only minimal revisions for context, I pasted the above two paragraphs into Claude and hit enter. ‘Nuff said. I love the satisfaction I get from crossing out todos.
Speaking of, I just knocked out another—automagically adding newlines before and after media in this blog. Small enhancement, but juicy.
All this task-list perusing has made me realize that some tasks are so old that I can’t really remember what exactly they even are based on their one-line descriptions. Therefore, I’m gonna update my task creation system so that when I designate the creation of a future task using my “todos” hashtag, the task created in Tasks will link back to the post the task was created from. I’ll utilize the invisible header technique and create an invisible id at the nearest newline to the relevant text (like <a id="task_1"></a>) so that I can click on the task reference and find exactly what I’m looking for, even in long entry posts. This lends to the fact that my tasks should probably all have IDs assigned to them. Therefore, instead of a task in the list looking like this:
- [ ] Add clickable references to tasks
It’d look something like this:
- [ ] [[2026-01-14#task_1|1]] Add clickable references to tasks
Let’s see if Claude can make that happen in one shot.
Update: Easy money snipes. ‘Nuff said.
Update 2: Frankly, I’d be doing you readers a disservice if I pretended that the task ID system I just built with Claude didn’t need any tweaking to get right. First of all, I realized that putting the task ID before the task label looks much worse visually than putting the ID afterwards. I could have intuited that, but it was easier to just test and see. After fixing, my tasks look like this:
- [ ] Add clickable references to tasks [[2026-01-14#task_1|1]]
Next, after conversing with Claude about how the system worked, I realized that multiple tasks would end up having the same ID. Backlinks still worked anyways, so my overall goal was met, but since I intend to use the task ID number as a counter to note how many tasks I’ve gone through over time, I opted to improve the design.
I also realized that backlinks never actually got deleted when tasks were removed. Claude missed that, but I didn’t when testing. Ergo, I want to underscore the importance of testing out systems instead of just assuming they work right away. Test, test, test some more.
Tags: metaballs physics debugging deployment file-management vibe-coding gdrive claude