Fix stale codebase example in README.invariant.md

[ooloth]

✅ What

• Replaces the stale "Good: Post-Validation Assertion" example (which cited a deleted dimensions invariant at an old file path) with the actual invariant present at io/cloudinary/fetchCloudinaryImageMetadata.ts
• Updates the section heading to "Pre-Condition Guard" to accurately describe the replacement
• Fixes the old lib/cloudinary/ path in the "Bad" example to io/cloudinary/

🤔 Why

• A reader following the cited file path would find neither the path nor the invariant call, making the example misleading

👩‍🔬 How to validate

• Open utils/errors/README.invariant.md and read the "Good: Pre-Condition Guard" example — expect the file path to be io/cloudinary/fetchCloudinaryImageMetadata.ts
• Open io/cloudinary/fetchCloudinaryImageMetadata.ts and search for publicId.trim().length > 0 — expect to find that exact invariant call in generateResponsiveImageUrls

🔖 Related links

• Fix stale codebase example in README.invariant.md "Post-Validation Assertion" section #28
• https://claude.ai/code/session_01NX6Sqy1LRifn2ZbMjm4gcM

Closes #28

---

Generated by Claude Code

[claude]

Code Review

Overview

This PR fixes stale documentation in utils/errors/README.invariant.md by replacing a "Good" example that referenced a deleted invariant at an old file path (lib/cloudinary/) with an actual invariant that exists in the current codebase (io/cloudinary/fetchCloudinaryImageMetadata.ts).

---

Code Quality & Correctness

• Example accuracy confirmed: The new example correctly references invariant(publicId.trim().length > 0, ...) which exists at line 88 of io/cloudinary/fetchCloudinaryImageMetadata.ts. No drift between the doc and the code.
• Heading rename is accurate: "Pre-Condition Guard" correctly describes the pattern — the function asserts a contract on its own input (publicId) before proceeding, which is a pre-condition check, not a post-validation assertion.
• "Bad" example path fix: Updating lib/cloudinary/ → io/cloudinary/ (with the added clarification "before this pattern was removed") is a nice touch — it makes the example's intent clearer while removing the misleading path.

Minor Observation

The comment in the "Good" snippet —

// publicId has already been parsed from a validated Cloudinary URL

— describes caller-side context that isn't visible in the snippet itself. A reader can't easily verify this from the example alone. That said, this is accurate (the function signature receives a string, not a raw URL), and the context explains why an invariant is appropriate here rather than a Zod validator. It's a judgment call; leaving it as-is is fine.

---

Potential Issues

None. This is a single-file documentation change with no runtime impact.

Performance / Security

N/A — documentation only.

Test Coverage

No tests needed for a markdown documentation fix.

---

Summary

Clean, accurate, well-scoped fix. The PR description's validation steps match exactly what I verified in the code. LGTM. ✓

[Copilot]

Pull request overview

Updates the invariant() documentation examples so they reference current, findable code in the repository, resolving a stale example called out in issue #28.

Changes:

• Replaces the outdated “Good” example with an invariant() call that exists in io/cloudinary/fetchCloudinaryImageMetadata.ts.
• Renames the example heading to “Good: Pre-Condition Guard” to match the new example’s intent.
• Updates the “Bad” example’s file path from lib/cloudinary/ to io/cloudinary/.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.