Fair, you're right. Thanks for the point. I used ai for a chunk of the build and writing. However, the actual work behind it wasn't AI-generated. I spent a few weeks interviewing people in r/devops and some compliance subs about how they actually test backup restores, and the report schema especially came out directly out of those conversations.
You are also right about the REAME. I'll tighten it up right now, and enhance it. Thank you for the feedback.
What bothers me personally the most is trying to hide it. Why did you remove Claude's (or whatever you used, but looks like opus to me from the style) co-author info?
I'm willing to use (semi-)vibecoded projects under certain circumstances, but I like to know up front what I'm getting. The github contributors list makes that easy to see as long as people don't try to hide it.
> There are other tools in this space. Worth naming plainly instead of pretending they don't exist.
Why do LLMs like this kind of writing? Why did you need to “plainly” name the competition as opposed to “flamboyantly” naming them?
This is a cool idea but the README is absurdly not-to-the-point.
Fair, you're right. Thanks for the point. I used ai for a chunk of the build and writing. However, the actual work behind it wasn't AI-generated. I spent a few weeks interviewing people in r/devops and some compliance subs about how they actually test backup restores, and the report schema especially came out directly out of those conversations. You are also right about the REAME. I'll tighten it up right now, and enhance it. Thank you for the feedback.
What bothers me personally the most is trying to hide it. Why did you remove Claude's (or whatever you used, but looks like opus to me from the style) co-author info?
I'm willing to use (semi-)vibecoded projects under certain circumstances, but I like to know up front what I'm getting. The github contributors list makes that easy to see as long as people don't try to hide it.
This is a great idea. Anything that makes this easier is a win for ops teams.