You should really know what you're doing all day. If you can't even summarize what you were doing all day, that sounds like a bad thing. The evidence is your story about what you actually did.
Here's a perfectly great update that didn't result in a quick win:
"I spent all day debugging that null pointer issue like we discussed. I thought maybe it was because the API was sending nulls across, but I looked at the logs and couldn't find any instance of that happening. I thought maybe it was a type coercion issue too, but I wrote a few tests to rule that out and it turned out not to be the case. Then I remembered reading about a memory corruption issue that sometimes happens in our runtime version, so I spent the rest of the day reading about the situations where that occurs and figuring out if it applies to us, but didn't get enough time to finish that up completely."
You should still be able to recount what you did, past tense.
"This morning I sketched out three different possibilities for the new client check-in service. First draft of the spec is in progress, I expect to send it over to Jen and Andy tomorrow for their feedback."
"I made a dozen or so mockups for the new landing page. I have a couple more ideas I want to try out tomorrow, then I'll figure out what the best four or five are and show them to the team."
"Since we don't have any feature work pending right now, I've been experimenting on a branch with using $TOOL to do $THING better. It looks good because $X, although $Y might be a problem."
"We talked a while ago about doing $THING with the user's documents so they can $WHATEVER more easily, and I wasn't sure it was even possible. I've been looking into that today. It looks like there might be a way, so I'm continuing to investigate."
"We've wanted to replace $FRAMEWORK for a while now. I've identified the parts of it that we actually use, and I'm putting together a plan for what we can swap in and/or get rid of. It looks like, since we made $CHANGE last month, we can actually do most of it ourselves without much trouble."
Starting from the standpoint that your peers or reports are lying to you is never going to work. Treating people like kids means you'll get kid level responses.
If someone is lying, it will eventually come out. That fake report one day will turn into a week and eventually they will get fired. But, don't kill your entire team on the off chance that someone is trying to game the system.
Assuming that you really think that the members of your team are lying to you like this, it's easy enough to validate.
The first one says they're writing a spec. Well, three days later, where's that spec? Next one is producing some designs, so same. Sure someone saying "$TOOL/$NEW_FUNCTION/$REPLACE_FRAMEWORK just didn't work out", could be cover for "I was playing Pac-man all day", but if you ask for details, BS should become clear pretty quickly.
And again, that's starting from the position that you think your teammates are probably slackers who would rather lie than work. Which is not really a great position to hold, IMO.
Look, if I'm leading a group like this, I'm going to have an idea of what your output is like in an average sense, both compared to your historical output and the group as a whole. If you blow off a day it's not really going to matter. (although I'd rather you tell me you needed to blow off a day than try and hide it, sure).
However, if you blow of enough days we're going to have a conversation about how your performance is dropping, and why, and discuss your ideas about how to turn that around. If it doesn't, we'll have another conversation, and so on. Eventually if none of this works we'll have a different conversation (about why you are leaving).
This doesn't actually have anything to do with reviewing daily/weekly reports. Those are for different things.
"Big design up front" rarely works, even in abstract terms. I've learned that your point 2) is crucial - you have to force yourself to build "artifacts of progress" for actual progress to happen! Maybe there are some geniuses who can build whole programs completely in their heads, but my mind starts to run in circles if I try that. Whether drawings, prototypes, or just stream-of-thought notes, just continuously getting things out of my head speeds working a lot for me - and all of these can be turned into a summary of what I did today.
There are days when I'm trying to write (as in prose or a presentation) all day and the muses are not connecting, I do a lot of unrelated not-really "research," etc. And that's mostly OK. For a day. But obviously not for a week or weeks in a corporate setting. (And, if I really had a hard deadline, I'd crank out something serviceable. But I usually aim to do better than that.)
With one of my customers, I had a week when I consistently reported "designing the new model for $thing-that-drives-our-product", sometimes additionally with "and I spend some time talking with $product-guy and $coworker about the design". As a side effect of the design process, I produced a bunch of concept documents and drawings, which once the overall goal was clear, I transformed into barebones interactive prototypes testing experimentally some design points. So the next week, my daily reports were "aaand, I also did this prototype to test out $design-concern" (to which the universal reaction was "oooh, shiny! <3"). Two weeks, zero code for the actual product, just couple pages of text and a lot of garbage JavaScript in prototypes.
This is how work sometimes look. A good manager will accept your vague description, trusting that something of value commensurate with time spent will come out from the other end. As long as you actually deliver, a sane manager will not mind.
(That said, if asked for details, I always could explain what my main concerns and areas of exploration were at any point in the design process. The story about what you were doing is proportional to how much work you actually put in. If you can't elaborate beyond "I was thinking about $X", maybe you weren't really thinking about it? Conversely, I find forcing myself to write down and structure my thoughts to be an excellent way to unblock myself when my mind is running circles, or feels like watching Netflix instead.)
Well, I guess set up the bait by using the phrase "good manager".
Maybe I'm lucky, but for all the failings of various people I've worked under, I've met none who wouldn't understand it when some work requires more cognitive effort than code.
If anything, the problem may be that the "bad manager" doesn't trust you. But that's a completely different issue than them not understanding the concept of abstract work.
The creative people I know generate all sorts of artifacts that may or may not be used (designs, notes, research, etc..). They rarely sit at their desk all day just thinking.
Here's a perfectly great update that didn't result in a quick win:
"I spent all day debugging that null pointer issue like we discussed. I thought maybe it was because the API was sending nulls across, but I looked at the logs and couldn't find any instance of that happening. I thought maybe it was a type coercion issue too, but I wrote a few tests to rule that out and it turned out not to be the case. Then I remembered reading about a memory corruption issue that sometimes happens in our runtime version, so I spent the rest of the day reading about the situations where that occurs and figuring out if it applies to us, but didn't get enough time to finish that up completely."