From the Backlog to the Build Log
NuGet Vulnerability Audit: September 4 - September 10, 2026
What I Worked On
This was a light product week. Most of my tracked hours went to getting the word out about DevNitro: a lead magnet, the pages that deliver it, and the tracking that shows where a reader came from. The platform code came in two bursts. Wednesday a deploy failed because the NuGet vulnerability audit caught a package I never referenced. Intelligent Engineering puts gates in the pipeline that neither the agent nor I can talk our way past. This week one of them stopped a vulnerable deploy.
The third thread was this HowdyChad blog, which I built with DevNitro. It picked up per-post signup forms and a lead magnet delivery page, and the attribution work from the CRM week now carries across all three sites.
What the AI Did Well
The listener bug from last week: I picked a listener on my Linux box and the first chat went to my Windows machine. The agent built a CliConnectionRegistry that remembers listeners that just dropped, keeps an alias chain for connection ids, and resolves a stale id to the live connection. A conversation's affinity to a listener now survives a reconnect, and a listener you picked by hand never falls back to another one. Listener resolution for the web app collapsed into one ResolveCliForConversation method, and the status badge now reports whether a listener exists and whether it is busy. It also added admin-only diagnostic commands and a disconnect simulator so I can reproduce the drop. Tests cover the registry, the badge, and the routing.
Wednesday's deploy failed at CLI publish. The error was NU1902: Microsoft.Build.Tasks.Git 8.0.0 has a known vulnerability, and the build treats audit warnings as errors. Nothing in the repo references that package. I asked the agent where it came from. It restored with the audit off, walked the dependency graph, and found Terminal.Gui 2.0.0 publishing Microsoft.SourceLink.GitHub as a public dependency, which drags in the vulnerable build task. The fix was a pinned patched SourceLink in central package management with a build-only direct reference in the CLI project. Restore passed with the audit on and the build came back clean, all in under fifteen minutes.
On the blog side, the agent added a KitFormId column so each post can pick its own signup form, with a site-wide default as fallback, a form catalog, a dynamic Blazor component with a JS embed, a CSP update, and integration tests. Then it built the lead magnet delivery: a thank you page, a typed catalog, file endpoints that validate what they serve, auto-download, and tests for the catalog and the security checks. Last, it added journey ref, UTM, and landing page fields to the partner lead payload in DevNitro and to the GlobalCove website's lead API, run through the same allow-list the public form uses.
I ran one side test. I had not tried DevNitro with an MCP server in months, so I pointed it at Blender with Fable 5.1 and asked for a snowman that juggles. Two other tools got the same prompt. One crashed Blender. DevNitro's snowman juggled with the stick arms in sync with the balls.
What Needed Correction
While explaining the NuGet audit error, the agent noticed the deploy tool swallowed every Azure CLI failure and reported it as "no deployment found." After the CMOS chaos earlier in the week, my Azure login had expired, and the tool told me my infrastructure was missing. The agent replaced both catch blocks with one helper that prints the real error and tells you to log in.
The Canva MCP did not work out. I wanted the lead magnet PDF built there. The session could not see the server until a restart, and once it could, the model's output was weak. I made the PDF another way as I continued to test DevNitro.
What Shipped
DevNitro deployed with the listener fixes, the SourceLink pin, the deploy tool error fix, and a new model in the provider list. The HowdyChad blog deployed with per-post forms and lead magnet delivery, and the 7 Mistakes lead magnet is now the default form on every post. The GlobalCove website's lead API accepts attribution.
The Numbers
| Category | Hours |
|---|---|
| Business | 15h 13m |
| Content | 10h 31m |
| Testing | 1h 59m |
| Deploy / Infra | 0h 31m |
| Product / Features | 0h 15m |
| Total | 28h 29m |
This was a light week because of Labor Day. Seeing extended family was great. It took me a while to get back into the work rhythm afterward, and I spent more time than I have in a long time in a bucket I call IGM. Instant Gratification Monkey time. If I get distracted and play games, just watch YouTube videos for entertainment, stream movies, or scroll X, this gets logged. Most weeks, it is zero. This week it was over 6 hours (not included above). Some of the time was messing around with AI video and experimenting with new tools for content creation. It likely isn't a total waste of time, but I should have been working harder on getting the word out about DevNitro.
Where This Fits in Intelligent Engineering
The audit gate did not care who pushed the deploy. It failed the build on a transitive package, and the only way through was a fix. That is the operating model doing its job: the pipeline holds the line, the agent does the diagnosis, and the builder decides the fix. A team can trust a deploy that a gate like this has passed, whether a person or an agent wrote the code behind it.
A NuGet vulnerability audit cost me fifteen minutes and saved me from shipping a known hole in the CLI. Back at it next week.
0 Comments
No comments yet. Be the first to share your thoughts!
Leave a comment