2025 06 21 recall session #2

Ben Fisher records a development session for his personal "recall" project, describing recent changes (support for multiple email addresses), the state of the codebase, and his priorities: implementing a happy-path first, adding logging for message/API actions, and creating tests without polluting the live CRM. He discusses Node.js unfamiliarity (where logs go, how to write tests), ideas for mocking API calls, handling contacts lacking emails (throwaway emails as an edge case), and using Taskmaster/Claude to generate tasks and commits. The tone is exploratory and practice-focused—building a private tool and learning.
Chapters
Like change of scenery. I'm not home. Made a couple tweaks, nothing noteworthy, so I just did them. But basically I just add support for multiple email addresses and did was I just created this for overview of what have we built and what the different sections are, what's even left. We've not yet built an import. What I'm focused on initially is the happy path. And just functionally does all this work? This is. This is what we have been focused on because this is all that matters and we're using AI to help us think through the solution for it. What I'm telling it now is as we're running tests, I want it to isolate it to someone that I know I've been texting the last day. This works. Frankly, it doesn't matter. Please add a task and let's do it now to create a log of any changes that are being made of email or phone or SMS messages being read, who it is. And then if we're making any API calls to add IO, what changes we're making to add IO and or for sending a spoofed email on behalf of a particular user, let's make sure that we have a log so we can go through and see what's changing and what's happening behind the scenes and maybe where it's failing. And that's the thing too is I've never used Node before, so I don't know where the error logs go. Huh. Guess we'll see. Overkill. They typically be listening to instrumental music, but it's kind of hard to do. Oh yeah. And typically what I'll do is I'll functionally focus on getting this to work and then refactor because again we're. On one hand I want this to be dry and well structured. On the other hand, I'm right now focused on functionally how to do something so that on the. On the product side it actually does it accomplish the goal before investing enormous amount in the architecture. Because this is not going to be a product I sell. It's a product that I'll be using for myself and it's a way to learn test building with AI. And I would describe this as somewhere between. This is more than Vibe coding, but it's not certainly much more than Vibe coding, but this is not intensive. We'll call it document based building where I'm building out tests and incorporating tests. From the beginning, this is more me tinkering and exploring and building a product and trying to see if I can functionally accomplish stuff. Not the most It's a way to do it, but not generally what I'd recommend when building like a real product. Wonderful. And so what I guess I could do in this situation is actually create tests that mock API calls rather than as we're going through this and testing all these edge cases and making sure that it's actually doing this, it would do it through tests with mocked API calls rather than the actual it muddies up the well, I've reached my focus limit but the answer is that not sure that's the right place to put it. Should that be in the quad markdown file or in the projects markdown? Read me kind of blows my mind that it keeps doing this it moving Answer the Cloud markdown file to to not add project related documentation to the Claude markdown. Add that to the readme or into the project markdown if it's related to the scope or implementation of the project. The Claude markdown is limited only to things related to best practices to around software engineering and building the product and using Claude code. How else to say about the most elephant wave? Yes. No, we already have them defined in the Cloud Markdown file. I'm saying add that as a requirement so it stops happening. Oh you pause that for a second go. So that's all the things it did. Then let's check logs. There we go. Should be able to do tail where it shows any changes there one create one skips There you go. Person talk stories phone call. So there's no there'd be a note because we're still in the notes. So right now we don't have if we don't have an email address for someone that's going to educate us make note of an edge case we're going to have to resolve where if we have a phone number for someone but not an email address at all, there's no way for us to track an interaction with them unless we did like a note. But that will defeat the purpose. Like because we don't have an email address for them, we don't have a way to to pipe to adio a conversation with the person. So we'll want to figure out a solution for that later. My assumption is we might dynamically generate a throwaway email for that person and or it's a edge case that won't happen very often. There you go. We'll see how it handles this and but yeah you can see like you can see this in the edge case and logs now this should be added to the project TRD as an edge case and should Create a task that's at the end like deprioritize but task that we'll need to decide how to handle this and then it runs Taskmaster to add that. You can see it's even like familiarizing itself with Taskmasters syntax. Pretty cool. Made our changes. I am thinking that this might be a bit of a extensive project to be live streaming or recording. Maybe I should stick with N8N workflows. Is there a simple way for us to build a test suite here so that we don't start muddying out up the adio CRM. Like what would be your recommendation? Investigate a best practice here for a simple way of building out tests so that we're not. So we can verify these functions work but are not muddying up the CRM and sending tons of emails to Addio. I mean really, this should be a task. Oh, we need to commit the changes. No, we did. We did change do. There you go. So again like update to do's all this is using Taskmaster Relayer. I mean we can stick with real. The real messages and contacts reader for now, but everything else sounds fine with basic tests for our existing functionalities. We'll see Instinct here. This is probably going to get unnecessarily complicated pretty quickly. And it's compounded by the fact that I've never created node tests before. At least we can track here what the changes are. Just, you know, I mean I go back and forth on is this useful to see someone going through this but I know that I find it useful so you don't have to sit here through all this but and. Or you can watch it at 5x speed and maybe what I'll do is I'll extract some clips from here that are actually useful. But and or will be a way to summarize all this at the end. It any person found. Not found. I will say so far I've been impressed by how functionally a lot of this has worked on the first pass. Knock on wood. And I attribute a good part of that to using Taskmaster honestly. But I would probably be done by now if I was able to use both both my screens instead of having to centralize everything on this one. One monitor and then having to talk through my process and my thoughts. Good. Ah yeah. If the interaction already exists, it sa just change. See, this is where I start getting nervous. Think harder. I'm a little concerned. That is what we already. Yes. Restart simpler and focus on the basics. See if it cleans up all the extra files in this minute now okay. It we should be incrementally testing these tests as we're going when possible rather than jumping to building a bunch of stuff. It failing because I'm testing implementation details I don't actually know. Wow. I mean I need to really look through this test. I'm on the verge of asking you to think harder. How do I verify myself the tests are running and which tests are actually being run. It I find this is actually a helpful opportunity to learn. It's just as I'm going through and building some stuff asking questions to better understand why and how to dig deeper into this. All right. Yeah. That's basically what I'm this what I would do is I would start putting I would start putting real user information. Maybe intentionally the fuck this one's hate and then it's very I struggle with this These types of shortcuts and cursor because it's very different here. It yeah I could actually run cursor right here within Claude it add it to my eslint JS yourself or actually check or add the just globals do what you recommend Even if that means just adding the warnings to stop immediately in the test files. What do you recommend? Cool. I'll take a look at configuration meanwhile. Huh. So we have a battle of two different LMS with their recommendations. I think either one would have been fine. Adjust globals. See if the warnings are gone. Indeed they are gone. All right. We'll get rid of that computer is slow with screen recording software which is annoying as well. All right. All right. Commit our changes. A lot of stuff to do incremental and incrementally incrementally grouped in ways that make sense. Again. These are things that I wish it just and I'm sure there's ways to do it to have the project just know that this is how you should do anything around committing Then you always get anxious when you have auto compact context gain low because then it will compress it. And then I always find it generally doesn't do a great job of compressing. I don't see it added to the git ignore because they're still showing us unstage changes in git it's not going to show up in the logs. But SA and having never done this with Node getting some messages it things why is it saying a message from an unknown person in the logs? They are in my contacts. Where are we saying that they're unknown? Here's an example. Just look through the code. I guess too These are all known people because these are all known people within my contacts. My concern now is calm working it this is just creating a. Just creating an empty object but it makes no sense because we have a phone number. This object makes no sense that we're printing out because we obviously have a phone number. We're not actually looking at the contact at this stage. We're just taking the message. So what we're printing on the page makes absolutely no sense because obviously we have a phone number because we're reading the phone number. What we don't have is we don't yet know who the contacts are. It it how does it decide which email address to associate with the person on the contact list Like D has multiple email addresses to search for. She went to the multi email address search and wouldn't this be using the multi email search or is it just that it loops through them? Does it loop through them if it can't find them for the first one? Yeah yeah it SA made our changes it rename the primary file here instead of e to E whatever should it be like index js rename it maybe to recall sync then that's fine. And I like that NPM start would actually run sa this method is horribly named changes in push. How can I test. How can I verify that my tests are actually testing? Well actually I know that they're actually testing the methods of my objects say that but I actually know the answer to this. I'll just say it regardless. I just want to verify that these tests are not just happening and testing themselves. I want to make sure they're actually testing our application because I haven't seen any of them fail yet which concerns me. Yeah. Like how do I verify the testing will code the place? No they are and the reason I know is it's instantiating the object 1 or 16 point it it so let's end this for now.






