waitsec 0.5.0 → 0.5.3

package/skills/waitsec-pagemaker/references/about-me.md

@@ -113,6 +113,44 @@ Use this guide when creating a personal developer portfolio, founder bio, or eng
 
 ---
 
+## SEO, GEO & Structured Data (About & Portfolio)
+
+- Title: full name plus role, for example "Ilyas Mukhlisin, Backend Engineer", about 50 to 60 characters.
+- Meta description: who you are, what you build, and how to reach you, about 140 to 160 characters.
+- One `<h1>` with your name.
+- Server-render the bio, project list, and contact email.
+- Add `sameAs` links to GitHub, LinkedIn, and X so engines can confirm the identity.
+- Describe each project with a concrete outcome, not a vague claim, so answer engines have something to quote.
+
+### JSON-LD for an About or Portfolio Page
+
+```html
+<script type="application/ld+json">
+{
+  "@context": "https://schema.org",
+  "@type": "ProfilePage",
+  "url": "https://example.com/about",
+  "mainEntity": {
+    "@type": "Person",
+    "name": "Your Name",
+    "jobTitle": "Backend Engineer",
+    "url": "https://example.com",
+    "image": "https://example.com/images/avatar.jpg",
+    "worksFor": { "@type": "Organization", "name": "Fastro" },
+    "knowsAbout": ["Laravel", "PostgreSQL", "API design"],
+    "sameAs": [
+      "https://github.com/username",
+      "https://www.linkedin.com/in/username"
+    ]
+  }
+}
+</script>
+```
+
+When the about page is part of a company site, add an `Organization` node and connect it with `worksFor` or `memberOf`.
+
+---
+
 ## Pre-Flight Checklist for About Me & Portfolio Pages
 
 - [ ] Are all fake animated skill percentage bars removed in favor of clean categorical tags?
@@ -120,3 +158,4 @@ Use this guide when creating a personal developer portfolio, founder bio, or eng
 - [ ] Does every featured project have a working live link or public repository link?
 - [ ] Is there a direct, clickable `mailto:` link clearly visible on the page?
 - [ ] Do project cards collapse into a clean single vertical stack on mobile screens?
+- [ ] Is there a valid ProfilePage with Person data, including sameAs links to real profiles?

package/skills/waitsec-pagemaker/references/article-single.md

@@ -95,6 +95,68 @@ Use this guide when creating a single article view, blog post template, or markd
 
 ---
 
+## SEO, GEO & Structured Data (Article Page)
+
+- Title: the article headline, optionally with the site name, about 50 to 60 characters.
+- Meta description: an honest summary of the article, about 140 to 160 characters.
+- One `<h1>` that matches the headline.
+- State the article's main answer in the first paragraph, before background detail.
+- Use question-shaped `<h2>` and `<h3>` headings, each followed by a direct answer.
+- Show `datePublished` and `dateModified` visibly near the top, and keep both in the schema.
+- Give the cover image descriptive alt text and an absolute URL.
+- Keep the article body server-rendered.
+
+### JSON-LD for an Article Page
+
+The `Article` type is safe, while `BlogPosting` is more specific for blog posts. Use the one that matches the page. Add `BreadcrumbList` so search engines can show the path.
+
+```html
+<script type="application/ld+json">
+{
+  "@context": "https://schema.org",
+  "@graph": [
+    {
+      "@type": "BlogPosting",
+      "headline": "Why Errors Appear as Codes and How to Read Them",
+      "description": "A short, honest summary of what the article explains.",
+      "image": "https://example.com/storage/blog-thumbnails/cover.webp",
+      "datePublished": "2026-09-04T09:56:00+07:00",
+      "dateModified": "2026-09-04T09:56:00+07:00",
+      "author": {
+        "@type": "Person",
+        "name": "Ilyas Mukhlisin",
+        "url": "https://example.com/about"
+      },
+      "publisher": {
+        "@type": "Organization",
+        "name": "Fikselink",
+        "logo": {
+          "@type": "ImageObject",
+          "url": "https://example.com/images/logo.png"
+        }
+      },
+      "mainEntityOfPage": {
+        "@type": "WebPage",
+        "@id": "https://example.com/blog/post/why-errors-appear-as-codes"
+      },
+      "articleSection": "Technology",
+      "keywords": "error code, HTTP status code, how to read errors"
+    },
+    {
+      "@type": "BreadcrumbList",
+      "itemListElement": [
+        { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://example.com" },
+        { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://example.com/blog" },
+        { "@type": "ListItem", "position": 3, "name": "Why Errors Appear as Codes", "item": "https://example.com/blog/post/why-errors-appear-as-codes" }
+      ]
+    }
+  ]
+}
+</script>
+```
+
+---
+
 ## Pre-Flight Checklist for Single Article Pages
 
 - [ ] Is the article reading width capped at `max-w-3xl` or `65-75ch` to prevent eye strain?
@@ -102,3 +164,5 @@ Use this guide when creating a single article view, blog post template, or markd
 - [ ] Is body paragraph line-height set to relaxed (`leading-relaxed` / 1.75)?
 - [ ] Are subheadings given generous top margin (`mt-10` to `mt-12`) to separate topics clearly?
 - [ ] Is there a clear back-navigation link at the top of the article?
+- [ ] Does the first paragraph answer the main question directly?
+- [ ] Is there a valid BlogPosting or Article block with author, publisher, and ISO 8601 dates?

package/skills/waitsec-pagemaker/references/auth-pages.md

@@ -0,0 +1,138 @@
+# Auth Pages Blueprint (waitsec-pagemaker)
+
+Use this guide when creating login, register, forgot password, reset password, remember me, or account lockout and rate-limit screens. These pages are private by nature, so the goal is clarity, safety, and a short path back into the product.
+
+---
+
+## Complete Page Anatomy & Responsive Flow
+
+### 1. Login Page
+* **Desktop (1024px+):** Centered card (`max-w-md`) or a 2-column split with the form on the left and a solid brand panel on the right. No busy background.
+* **Mobile (<768px):** Single column. Brand mark on top, then the form. Inputs and the primary button are full width.
+* Fields: email or username, password with a show or hide toggle, a "Remember me" checkbox, the primary "Sign in" button, and a secondary "Forgot password?" link.
+* One primary action only. Social login buttons appear only when a real provider is wired up, and they sit below a labeled divider.
+
+### 2. Register Page
+* Minimal fields: name, email, password, and confirm password (or a single password field with a visible rules checklist).
+* Show password rules as a short checklist and validate as the user types.
+* Terms or privacy checkbox only when it is legally required.
+* Primary "Create account", with a clear link back to login.
+
+### 3. Forgot and Reset Password
+* Forgot: one email field and one primary "Send reset link" button. Always show the same neutral success message, whether or not the email exists.
+* Reset: new password plus confirm. The token is handled server-side, and the page notes that the link expires.
+
+### 4. Remember Me
+* Label states the exact duration, for example "Remember me for 30 days".
+* Unchecked by default on shared or public devices.
+* Never store tokens in `localStorage` or `sessionStorage`. Use secure, httpOnly, sameSite cookies set by the server.
+
+### 5. Account Locked and Rate Limit Blocked
+* Explain what happened in plain words, how long the lock lasts, and the next step.
+* Provide one recovery action: retry when the countdown ends, reset the password, or contact support.
+* Show a live countdown and keep the submit button disabled until it ends.
+* Render this as its own clear state, not a generic error page.
+
+---
+
+## Interaction and Security Rules (Non-Negotiable)
+
+- Never reveal whether an account exists. Use the same message for an unknown email and a wrong password.
+- Enforce the rate limit on the server. The UI only reflects the remaining wait time.
+- Use correct autocomplete attributes: `autocomplete="email"`, `autocomplete="current-password"` for login, and `autocomplete="new-password"` for register and reset.
+- Keep password fields accessible with visible labels and a show or hide toggle.
+- Errors appear as a summary at the top of the form and, where useful, inline under the field.
+- Use `aria-live="polite"` for the lockout countdown and for async error messages.
+- Give every control at least a 44px by 44px target on mobile.
+- Set input font size to at least 16px on mobile so iOS does not zoom on focus.
+- Center the card with `min-h` and normal document flow, never a fixed `h-screen` that traps the form when the keyboard opens.
+
+---
+
+## Detailed Pitfalls & The 5-Point Rule
+
+### 1. User Enumeration
+
+* **The Bad Habit:** The login form says "Email not found" for an unknown address and "Wrong password" for a known one.
+* **The Problem:** The different responses let an attacker test which emails have accounts.
+* **Why It Fails:** It turns the login page into an account discovery tool and invites credential stuffing against real users.
+* **Clean Fix:** Return one generic message such as "Email or password is incorrect" for both cases, and keep the response time consistent.
+* **The Waitsec Way:** Treat account existence as private data. Say less to stay safe.
+
+### 2. Lockout With No Explanation or Recovery
+
+* **The Bad Habit:** After too many attempts the form silently stops working or returns a blank error.
+* **The Problem:** The user assumes the site is broken and keeps retrying, which extends the lock.
+* **Why It Fails:** Frustration grows, support load rises, and legitimate users are locked out with no path back.
+* **Clean Fix:** Show a clear locked state with the reason, a live countdown, and one recovery action.
+* **The Waitsec Way:** A block must explain itself and offer a way out.
+
+### 3. Insecure Remember Me
+
+* **The Bad Habit:** Storing a long-lived token in `localStorage` so the checkbox "just works".
+* **The Problem:** Any script on the page can read the token, and a stolen token keeps the session alive.
+* **Why It Fails:** It turns a small XSS into a permanent account takeover.
+* **Clean Fix:** Use secure, httpOnly, sameSite cookies set by the server, with a sensible expiry, and rotate the token on use.
+* **The Waitsec Way:** Convenience must never weaken the session.
+
+### 4. Password Fields That Fail on Mobile
+
+* **The Bad Habit:** A password input with no show or hide toggle, tiny text, and no correct autocomplete hint.
+* **The Problem:** Users mistype, cannot verify, and the browser fills the wrong field or the wrong kind of value.
+* **Why It Fails:** Failed logins pile up, and some users abandon the form entirely.
+* **Clean Fix:** Add a show or hide toggle, use at least 16px text, and set the correct `autocomplete` attribute for each field.
+* **The Waitsec Way:** Remove friction from the most repeated action in the product.
+
+### 5. Fixed h-screen Form Trap
+
+* **The Bad Habit:** Centering the card inside `h-screen flex items-center`.
+* **The Problem:** When the mobile keyboard opens, the viewport shrinks and the input scrolls out of view.
+* **Why It Fails:** Users cannot see what they type or reach the submit button.
+* **Clean Fix:** Use `min-h-screen` with normal flow and enough bottom padding so the form scrolls above the keyboard.
+* **The Waitsec Way:** Let the page scroll. Never lock the height of a form on mobile.
+
+### 6. No Loading or Disabled State
+
+* **The Bad Habit:** The submit button stays active while the request runs.
+* **The Problem:** Users click several times and send duplicate login or register requests.
+* **Why It Fails:** It triggers avoidable rate limits and adds confusing error states.
+* **Clean Fix:** Disable the button on submit, show a spinner or "Signing in..." label, and re-enable it on failure.
+* **The Waitsec Way:** Every submit needs feedback and a single-flight guard.
+
+---
+
+## SEO, GEO & Structured Data (Auth Pages)
+
+- Auth pages should not rank. Set `<meta name="robots" content="noindex, nofollow">`.
+- Keep a simple title ("Sign in" or "Create account") plus the brand, and skip promotional copy.
+- Exclude auth pages from the sitemap and avoid linking to them as content.
+- Because this is a private page, use a minimal `WebPage` node. Do not add rich result types that a login page cannot support.
+
+```html
+<script type="application/ld+json">
+{
+  "@context": "https://schema.org",
+  "@type": "WebPage",
+  "name": "Sign in",
+  "url": "https://example.com/login",
+  "isPartOf": {
+    "@type": "WebSite",
+    "url": "https://example.com"
+  }
+}
+</script>
+```
+
+---
+
+## Pre-Flight Checklist for Auth Pages
+
+- [ ] Is `<meta name="robots" content="noindex, nofollow">` present, and the page excluded from the sitemap?
+- [ ] Does the page avoid revealing whether an account exists, with the same message and timing for all failures?
+- [ ] Do password fields have a show or hide toggle and the correct `autocomplete` attribute?
+- [ ] Does "Remember me" state its duration and default to off on shared devices?
+- [ ] Are session tokens kept out of `localStorage` and placed in secure httpOnly cookies?
+- [ ] Does the locked or rate-limited state explain the reason, show a countdown, and offer one recovery action?
+- [ ] Is the submit button disabled during the request to prevent double submits?
+- [ ] Does the form use `min-h-screen` with normal scrolling instead of a fixed `h-screen`?
+- [ ] Is a minimal `WebPage` JSON-LD block present and valid?

package/skills/waitsec-pagemaker/references/blog-index.md

@@ -112,6 +112,50 @@ Every article preview card must contain:
 
 ---
 
+## SEO, GEO & Structured Data (Blog Index)
+
+- Title: blog name plus its topic focus, about 50 to 60 characters.
+- Meta description: what the blog covers and who it helps, about 140 to 160 characters.
+- One `<h1>` for the index title, and `<h2>` for each article title.
+- Server-render article titles, excerpts, and dates so crawlers read them without JavaScript.
+- Link each card with the article title as anchor text, not "read more".
+- Point a canonical tag at the canonical page of the listing, and keep paginated pages self-canonical.
+- Keep the publish date and reading time visible, because freshness matters to both search and answer engines.
+
+### JSON-LD for a Blog Index
+
+```html
+<script type="application/ld+json">
+{
+  "@context": "https://schema.org",
+  "@type": "CollectionPage",
+  "name": "Engineering Journal",
+  "url": "https://example.com/blog",
+  "description": "Articles about software architecture, security, and frontend engineering.",
+  "isPartOf": { "@type": "WebSite", "url": "https://example.com" },
+  "mainEntity": {
+    "@type": "ItemList",
+    "itemListElement": [
+      {
+        "@type": "ListItem",
+        "position": 1,
+        "url": "https://example.com/blog/scaling-sqlite"
+      },
+      {
+        "@type": "ListItem",
+        "position": 2,
+        "url": "https://example.com/blog/reading-stack-traces"
+      }
+    ]
+  }
+}
+</script>
+```
+
+Use `Blog` instead of `CollectionPage` when the listing is a true blog. Include one `ListItem` per visible article, in the same order shown on the page.
+
+---
+
 ## Pre-Flight Checklist for Blog Index Pages
 
 - [ ] Do article cards stack into a clean single column on mobile without horizontal scrolling?
@@ -119,3 +163,5 @@ Every article preview card must contain:
 - [ ] Are article excerpts clamped to 2 or 3 lines so cards maintain a predictable height?
 - [ ] Can visitors comfortably reach the footer without being trapped by automatic infinite scroll?
 - [ ] Are publication dates and reading estimates clearly legible with strong contrast?
+- [ ] Does the page expose a valid CollectionPage or Blog ItemList schema?
+- [ ] Do article cards use the article title as anchor text instead of "read more"?

package/skills/waitsec-pagemaker/references/contact-page.md

@@ -84,9 +84,9 @@ Never demand phone numbers, fax numbers, company size, or physical mailing addre
 * **Why It Fails:** Software must always confirm state changes. Silent forms destroy confidence and generate duplicate tickets.
 * **Clean Fix:** Disable the submit button immediately on click, show a loading state, and render an unmistakable success card:
   ```html
-  <!-- Button Loading State -->
+  <!-- Button Loading State: the spinner icon comes from the icon library, never inline SVG -->
   <button disabled class="w-full py-3 bg-neutral-700 text-white font-medium rounded-lg cursor-not-allowed flex items-center justify-center gap-2">
-    <svg class="animate-spin h-4 w-4 text-white" viewBox="0 0 24 24">...</svg>
+    <i data-lucide="loader-2" class="w-4 h-4 animate-spin"></i>
     <span>Sending...</span>
   </button>
 
@@ -113,6 +113,43 @@ Never demand phone numbers, fax numbers, company size, or physical mailing addre
 
 ---
 
+## SEO, GEO & Structured Data (Contact Page)
+
+- Title: "Contact" plus the brand name, about 50 to 60 characters.
+- Meta description: how to reach the team and the expected response time, about 140 to 160 characters.
+- One `<h1>` such as "Get in touch".
+- Print the email and address as visible text, not only inside the form, so they can be extracted.
+- Server-render the contact details, the email link, and the response-time note.
+- Keep the page focused on contact, and avoid unrelated marketing sections.
+
+### JSON-LD for a Contact Page
+
+```html
+<script type="application/ld+json">
+{
+  "@context": "https://schema.org",
+  "@type": "ContactPage",
+  "name": "Contact Us",
+  "url": "https://example.com/contact",
+  "mainEntity": {
+    "@type": "Organization",
+    "name": "Example Inc",
+    "url": "https://example.com",
+    "contactPoint": {
+      "@type": "ContactPoint",
+      "contactType": "customer support",
+      "email": "hello@example.com",
+      "availableLanguage": ["English", "Indonesian"]
+    }
+  }
+}
+</script>
+```
+
+Add the organization `logo` and a `PostalAddress` when a physical address is shown. Only include channels that are actually displayed on the page.
+
+---
+
 ## Pre-Flight Checklist for Contact Pages
 
 - [ ] Is the form limited to 3 or 4 essential fields (Name, Email, Message)?
@@ -121,3 +158,5 @@ Never demand phone numbers, fax numbers, company size, or physical mailing addre
 - [ ] Does the page display an unmistakable success banner after submission?
 - [ ] Is there a direct, visible email address (`mailto:`) provided as an alternative contact method?
 - [ ] Does the form have enough bottom padding to clear mobile virtual keyboards?
+- [ ] Is there a valid ContactPage with Organization and ContactPoint schema?
+- [ ] Are the email and address visible as text, not only inside the form?

package/skills/waitsec-pagemaker/references/landing-page.md

@@ -143,6 +143,72 @@ Use this guide when creating a marketing page, product launch screen, or SaaS ho
 
 ---
 
+## SEO, GEO & Structured Data (Landing Page)
+
+State what the product is and who it is for within the first two sentences of the hero. Answer engines quote those lines, so make them complete and direct.
+
+- Title: product name plus one clear benefit, about 50 to 60 characters.
+- Meta description: what the product does and who it is for, about 140 to 160 characters.
+- One `<h1>` that carries the core value proposition in plain words.
+- Server-render the hero headline, subheadline, and primary CTA.
+- Add an FAQ block with question-shaped `<h3>` headings. Start each answer with a direct one-sentence response.
+- Keep the Open Graph image at 1200x630 and use an absolute URL.
+
+### JSON-LD for a Landing Page
+
+```html
+<script type="application/ld+json">
+{
+  "@context": "https://schema.org",
+  "@graph": [
+    {
+      "@type": "Organization",
+      "@id": "https://example.com/#organization",
+      "name": "Example Inc",
+      "url": "https://example.com",
+      "logo": "https://example.com/images/logo.png"
+    },
+    {
+      "@type": "WebSite",
+      "@id": "https://example.com/#website",
+      "url": "https://example.com",
+      "name": "Example",
+      "publisher": { "@id": "https://example.com/#organization" }
+    },
+    {
+      "@type": "SoftwareApplication",
+      "name": "Example App",
+      "applicationCategory": "BusinessApplication",
+      "operatingSystem": "Web",
+      "url": "https://example.com",
+      "offers": {
+        "@type": "Offer",
+        "price": "0",
+        "priceCurrency": "USD"
+      }
+    },
+    {
+      "@type": "FAQPage",
+      "mainEntity": [
+        {
+          "@type": "Question",
+          "name": "Is there a free plan?",
+          "acceptedAnswer": {
+            "@type": "Answer",
+            "text": "Yes. The free plan covers one project with no time limit."
+          }
+        }
+      ]
+    }
+  ]
+}
+</script>
+```
+
+Include the `FAQPage` block only when the FAQ is actually visible on the page. Use `Product` instead of `SoftwareApplication` for a physical or ecommerce product.
+
+---
+
 ## Pre-Flight Checklist for Landing Pages
 
 - [ ] Does the hero section have exactly 1 high-contrast primary CTA button?
@@ -150,3 +216,5 @@ Use this guide when creating a marketing page, product launch screen, or SaaS ho
 - [ ] Are feature cards structured with varied visual weight (bento style) rather than copy-paste clones?
 - [ ] Is there zero horizontal page wobble when testing at 320px width?
 - [ ] Are all headlines scaled down comfortably on mobile to avoid breaking words into multiple lines?
+- [ ] Is there one H1, a unique title, a meta description, and an absolute Open Graph image?
+- [ ] Is the JSON-LD valid, type-appropriate, and free of validator errors?

package/skills/waitsec-quality/SKILL.md

@@ -21,22 +21,101 @@ Activate this skill whenever:
 
 ---
 
-## Core Guardrails
-
-### 1. Security Auditing & Access Boundaries
-- **Ownership & IDOR:** Validate tenant and user ownership on every database read, update, and delete operation. Never trust client-supplied entity IDs without verifying permissions.
-- **Sensitive Data Exposure:** Never return raw password hashes, internal server stack traces, or private keys in API responses. Use explicit serialization filters.
-- **Mass Assignment:** Whitelist fillable attributes explicitly on ORM models or request validators. Reject raw wildcard inserts.
-
-### 2. Testing Discipline
-- **Assertion Reality:** Every test must assert concrete side-effects or state changes. Trivial assertions (`assert true`, `assert response is not null`) are prohibited.
-- **Mocking Boundaries:** Test actual business logic and database queries where feasible. Never mock the system under test to force an artificial passing run.
-- **Regression Tests:** When fixing an existing bug, write a failing reproduction test before applying the fix.
-
-### 3. Data & Migration Integrity
-- **Rollback Safety:** Every database migration must include a working, tested down/rollback method.
-- **Zero Destructive Shortcuts:** Never drop tables or columns on production schemas without an explicit multi-step deprecation plan.
-- **Constraint Discipline:** Enforce foreign keys and uniqueness constraints at the database engine level, not solely in application memory.
+## Part 1: Security & Access Boundaries
+
+### 1. Trusting Client-Supplied IDs (IDOR)
+
+* **The Bad Habit:** Fetching a record straight from a request ID, like `Order::find($id)`, without checking who owns it.
+* **The Problem:** Any logged-in user can change the ID in the URL and read or edit someone else's record.
+* **Why It Fails:** This is a direct data breach. One guessed number exposes private orders, messages, or invoices.
+* **Clean Fix:** Scope every read, update, and delete to the authenticated user or tenant:
+  ```php
+  // Bad
+  $order = Order::find($id);
+
+  // Good
+  $order = auth()->user()->orders()->findOrFail($id);
+  ```
+* **The Waitsec Way:** Never trust an ID that came from the client. Verify ownership on every data access.
+
+### 2. Leaking Sensitive Data in Responses
+
+* **The Bad Habit:** Returning the whole model, including password hashes, internal flags, or stack traces.
+* **The Problem:** The API response exposes fields the user should never see.
+* **Why It Fails:** Leaked hashes and internal details hand attackers the first step of a break-in.
+* **Clean Fix:** Return explicit, whitelisted fields only. Use serialization filters or resource classes.
+* **The Waitsec Way:** Send the minimum the client needs. Everything else stays server-side.
+
+### 3. Mass Assignment
+
+* **The Bad Habit:** Passing the whole request payload into `create()` or `update()`.
+* **The Problem:** A crafted request can set fields the form never exposed, such as `isAdmin` or `price`.
+* **Why It Fails:** Attackers change roles and prices with a single extra parameter, and the database accepts it.
+* **Clean Fix:** Whitelist fillable attributes and pass only validated data:
+  ```php
+  // Forbidden
+  User::create($request->all());
+
+  // Required
+  User::create($request->validated());
+  ```
+* **The Waitsec Way:** Accept only the fields you meant to accept. Never forward raw input to the database.
+
+---
+
+## Part 2: Testing Discipline
+
+### 4. Trivial Assertions
+
+* **The Bad Habit:** Writing tests that assert `true`, assert the response is not null, or call an endpoint without checking the result.
+* **The Problem:** The suite is green while the feature is broken.
+* **Why It Fails:** A passing test that proves nothing gives false confidence. Bugs reach production behind a fake safety net.
+* **Clean Fix:** Assert a concrete outcome: the row was created, the balance changed, the status code is 403, or the field equals the expected value.
+* **The Waitsec Way:** A test must prove a behavior. If it cannot fail, it is not a test.
+
+### 5. Mocking the System Under Test
+
+* **The Bad Habit:** Mocking the very class or query the test is supposed to verify.
+* **The Problem:** The test only confirms that the mock returned what the mock was told to return.
+* **Why It Fails:** Real bugs live in the code that got mocked away. The suite passes and the feature still fails.
+* **Clean Fix:** Test real business logic and database behavior where feasible. Mock only true external boundaries.
+* **The Waitsec Way:** Test the real thing. Put mocks at the edges, never over the subject.
+
+### 6. Fixing Without a Reproduction Test
+
+* **The Bad Habit:** Fixing a reported bug immediately and moving on, with no test that captures the failure.
+* **The Problem:** Nothing stops the same bug from returning in the next refactor.
+* **Why It Fails:** Without a failing reproduction first, you cannot even prove the fix addresses the reported case.
+* **Clean Fix:** Write a failing test that reproduces the bug, then fix until it passes, then keep the test.
+* **The Waitsec Way:** A bug fix ships with proof. The reproduction test is that proof.
+
+---
+
+## Part 3: Data & Migration Integrity
+
+### 7. One-Way Migrations
+
+* **The Bad Habit:** Writing an `up()` migration with no working `down()` rollback.
+* **The Problem:** A bad deploy cannot be reversed cleanly.
+* **Why It Fails:** When the migration corrupts or blocks data, the team is stuck with a manual, risky recovery under pressure.
+* **Clean Fix:** Every migration gets a tested rollback that restores the previous schema state.
+* **The Waitsec Way:** A migration is a two-way door. If you cannot safely go back, you cannot safely go forward.
+
+### 8. Destructive Schema Shortcuts
+
+* **The Bad Habit:** Dropping a column or table in one migration to "clean up".
+* **The Problem:** Live data disappears the moment the migration runs, with no recovery path.
+* **Why It Fails:** Production data loss is permanent and often unrecoverable. One migration erases history.
+* **Clean Fix:** Deprecate in steps: stop writing, keep reading, back up, wait, then drop in a later release.
+* **The Waitsec Way:** Remove data only when you are certain nothing needs it. Prefer deprecation over destruction.
+
+### 9. Application-Only Constraints
+
+* **The Bad Habit:** Enforcing uniqueness or relationships only in application code.
+* **The Problem:** Race conditions and direct database writes slip past the checks.
+* **Why It Fails:** Duplicate or orphaned rows appear even though the app "always checks". Data integrity decays over time.
+* **Clean Fix:** Enforce foreign keys, unique indexes, and not-null rules at the database engine level.
+* **The Waitsec Way:** The database is the last line of defense. Let it enforce the invariants.
 
 ---