chore(deps): upgrade cssnano 7.1.9 → 8.0.1

linkedin-posts/icp-validation/backlog-vibe-coding-disposable.md

@@ -6,44 +6,37 @@ voice: personal-first-person
 pillar: validation-vs-production
 hypothesis: H3, H4
 icp_test: Do founders who vibe-coded an MVP recognize the disposable-vs-production line and share their rebuild stories? Do builders/CTOs add their own war stories?
-cta: Open question - "If you've been through one of these rebuilds, what's the part you thought you'd keep that you ended up throwing out anyway?"
+cta: Open question - "If you've been through one of these rebuilds, what did you keep, what did you throw away?"
 utm_campaign: icp_validation_validation_vs_production
 utm_content: vibe_coding_disposable_by_design
 status: draft
 notes: |
   Off-pillar post activated from backlog. Not in the planned Week 1
   (Progress Visibility) or Week 2 (Ownership & Access) slots.
 
-  REFRAMED 2026-05-09 (second pass): user flagged that leading with
-  security incidents was the wrong frame. The position is that vibe
-  coding produces unmaintainable code - generate-and-kill, not
-  generate-and-defend. Security failures are downstream symptoms.
-  Opener now leads with the maintenance mechanic (every fix breaks
-  something else; AI regenerates instead of refactors; fourteen
-  implementations of the same auth check) and skips the leak headlines.
+  SIMPLIFIED 2026-05-10 (third pass): user requested a simpler, more
+  direct opener. Now states the pattern flat ("for the last 3 months
+  I've gotten requests to turn vibe-coded MVPs into production code,
+  every time the answer is rewrite from scratch") instead of the prior
+  layered "founders messaged me / here's what's underneath" structure.
 
-  Hook archetype: observation-led (not stat-led, not dialogue-led).
-  Mon=dialogue, Tue=history, Wed=question, so this is a fresh shape.
+  Position unchanged: vibe coding produces unmaintainable code,
+  generate-and-kill is the workflow, security failures are downstream
+  symptoms not the lead. Mechanism still in body (AI regenerates, fix
+  patches one of N duplicates).
 
-  Story-shape: encounter (founders messaging Paul about vibe-coded
-  MVPs they can't change) -> mechanism (fourteen auth implementations,
-  AI regenerates) -> Karpathy framing -> Paul's personal rule (validate,
-  kill, rebuild fresh) -> peer question close.
-
-  Position: vibe coding is hypothesis-validation tooling; the code is
-  disposable BY DESIGN because it can't be maintained; the founder
-  mistake is treating disposable code as production code. The
-  generate-and-kill frame is now the post's spine.
+  Hook archetype: observation-led with direct first-person time stamp.
+  Mon=dialogue, Tue=history, Wed=question - this is a fresh shape.
 
   Voice: ~85% Walling + 15% Fishkin. Confession ("I vibe-code on
   weekends too") softens the line and earns the right to draw it. No
   credential stamps, no em dashes, no rule of three, no anaphora pairs.
 ---
 
-Three founders messaged me about the same thing this month. Vibe-coded MVP in front of paying customers, and a bug that keeps coming back no matter how many times the team patches it. They patch Monday, customer hits it Wednesday, they patch again Thursday, support ticket lands Friday. Three weeks in, the same file is open for the fourth time.
+For the last 3 months I've gotten several requests to turn vibe-coded MVPs into real production code. Every time, the answer comes back the same: rewrite from scratch.
 
-AI doesn't refactor when you ask for a fix. It writes fresh code. So after a few months of patches, the same broken logic lives in six different places in your codebase. The next "fix" patches one of them. The other five still produce the bug. From your seat, "we fixed it" keeps turning into "wait, it's back" three days later.
+AI doesn't refactor when you ask for a fix. It generates fresh code. After a few months of patches the same broken logic lives in five or six different places in your codebase. The next fix patches one of them; the others still produce the bug. From your seat, "we fixed it" keeps turning into "wait, it's back" three days later.
 
-I vibe-code on weekends. Once the hypothesis lands, I throw the code out and rebuild from scratch. Not because I'm pure about it. Because otherwise you keep paying for the same fix every couple of weeks for the rest of the product's life.
+I vibe-code on weekends too. Once the hypothesis lands, I throw the code out. Not because I'm pure about it. Because the alternative is paying for the same fix every couple of weeks for the rest of the product's life.
 
-If you've been through one of these rebuilds, what's the part you assumed you'd keep that you ended up tossing anyway?
+If you've been through one of these rebuilds, what did you keep, what did you throw away?

package.json

@@ -20,8 +20,8 @@
   "devDependencies": {
     "@fullhuman/postcss-purgecss": "^8.0.0",
     "autoprefixer": "^10.5.0",
-    "cssnano": "^7.1.9",
-    "lighthouse": "^13.2.0",
+    "cssnano": "^8.0.1",
+    "lighthouse": "^13.3.0",
     "markdownlint-cli": "^0.48.0",
     "postcss": "^8.5.14",
     "postcss-cli": "^11.0.1",
@@ -33,7 +33,7 @@
     "surge": "^0.27.3"
   },
   "dependencies": {
-    "caniuse-lite": "^1.0.30001791"
+    "caniuse-lite": "^1.0.30001792"
   },
   "engines": {
     "bun": ">=1.3"