waitsec 0.5.2 → 0.5.4

package/.cursor-plugin/plugin.json

@@ -2,7 +2,7 @@
   "name": "waitsec",
   "displayName": "waitsec",
   "description": "Practical guardrails for AI coding agents. Hold on, think first, code less.",
-  "version": "0.5.2",
+  "version": "0.5.4",
   "author": {
     "name": "fastroware"
   },

package/README.md

@@ -31,11 +31,11 @@ Most AI coding assistants do not fail because they lack knowledge. They fail bec
 
 ## The 5 Core Guardrails
 
-1. **`ask-first`** — If the prompt is missing essential decisions (schemas, storage locations, permissions), the AI must pause and ask 1 to 3 direct questions instead of guessing.
-2. **`anti-overengineering`** — Rejects unneeded design patterns, DTOs, and speculative abstractions. Keeps code lean while strictly enforcing authentication, authorization, and input validation.
-3. **`small-diff`** — Modifications stay strictly scoped to what solves the prompt. No cleaning up surrounding files, no global formatting passes, and no unnecessary dependency changes.
-4. **`debug-first`** — When something breaks, the AI must read the complete error message and stack trace. Never guess fixes or hide errors behind empty try/catch blocks.
-5. **`verify-first`** — Never declare a task complete without proof. Run tests, verify builds, test edge cases, and ensure no regressions occurred before reporting done.
+1. **`ask-first`**: If the prompt is missing essential decisions (schemas, storage locations, permissions), the AI must pause and ask 1 to 3 direct questions instead of guessing.
+2. **`anti-overengineering`**: Rejects unneeded design patterns, DTOs, and speculative abstractions. Keeps code lean while strictly enforcing authentication, authorization, and input validation.
+3. **`small-diff`**: Modifications stay strictly scoped to what solves the prompt. No cleaning up surrounding files, no global formatting passes, and no unnecessary dependency changes.
+4. **`debug-first`**: When something breaks, the AI must read the complete error message and stack trace. Never guess fixes or hide errors behind empty try/catch blocks.
+5. **`verify-first`**: Never declare a task complete without proof. Run tests, verify builds, test edge cases, and ensure no regressions occurred before reporting done.
 
 ---
 
@@ -91,23 +91,38 @@ vendor/bin/waitsec
 ```
 
 ### 7. Agent Skills Directory (skills.sh)
-Listed on [skills.sh/fastroware/waitsec](https://skills.sh/fastroware/waitsec). Install via the universal skills CLI:
+Listed on [skills.sh/fastroware/waitsec](https://skills.sh/fastroware/waitsec).
+
+The skills CLI does not pre-select anything for a GitHub repo, so you must choose at least one skill. To install every skill without any prompt:
+
+```bash
+npx skills add fastroware/waitsec -y
+```
+
+To install only the core guardrails:
 
 ```bash
-npx skills add fastroware/waitsec
+npx skills add fastroware/waitsec --skill waitsec
 ```
 
-Or install specifically the core guardrails module:
+To pick a specific set:
 
 ```bash
-# Individual guardrails
-npx skills add fastroware/waitsec/skills/waitsec            # All 5 core guardrails
-npx skills add fastroware/waitsec/skills/waitsec-ui         # Upcoming — UI optimizer & anti-slop copy
-npx skills add fastroware/waitsec/skills/waitsec-pagemaker  # Upcoming — Page architect (landing, blog, contact)
-npx skills add fastroware/waitsec/skills/waitsec-code       # Upcoming — Clean code & dependency hygiene
-npx skills add fastroware/waitsec/skills/waitsec-quality    # Upcoming — Security audits & test discipline
+npx skills add fastroware/waitsec --skill waitsec waitsec-pagemaker
 ```
 
+Available skills:
+
+| Skill | Purpose |
+| :--- | :--- |
+| `waitsec` | Core 5 guardrails: ask-first, anti-overengineering, small-diff, debug-first, verify-first |
+| `waitsec-pagemaker` | Page architect: project recon, design preferences, SEO/GEO, Schema.org, auth and UX rules |
+| `waitsec-code` | Clean code, anti-comment noise, dependency hygiene |
+| `waitsec-ui` | Anti-slop UI, responsive discipline, UI copy cleanup |
+| `waitsec-quality` | Security auditing, test discipline, migration safety |
+
+Tip: the CLI preselects all skills only when you install from a skills.sh pack URL. For a one-command install that selects everything by default, create a pack on [skills.sh](https://skills.sh) (sign in with Vercel, import this repository) and share the pack URL `https://skills.sh/p/<pack-id>`.
+
 ---
 
 ## Structure
@@ -115,7 +130,7 @@ npx skills add fastroware/waitsec/skills/waitsec-quality    # Upcoming — Secur
 ```text
 waitsec/
 ├── skills/
-│   ├── waitsec/                   # ACTIVE — Core 5-phase guardrails
+│   ├── waitsec/                   # ACTIVE: Core 5-phase guardrails
 │   │   ├── SKILL.md               # Hub: pipeline overview + links to detail files
 │   │   └── references/            # Deep-dive guardrails & UI copy rules
 │   │       ├── ask-first.md           # Phase 1: Clarify requirements before coding
@@ -125,14 +140,20 @@ waitsec/
 │   │       ├── verify-first.md        # Phase 5: Proof before declaring done
 │   │       └── write-info-analyzer.md # Simple rules for UI text and clean labels
 │   │
-│   ├── waitsec-ui/                # UPCOMING — Anti-slop CSS, UI copy restraint, responsive
+│   ├── waitsec-ui/                # ACTIVE: Anti-slop CSS, UI copy restraint, responsive
 │   │   └── SKILL.md
-│   ├── waitsec-pagemaker/         # UPCOMING — Page architect (landing, blog, articles, contact)
-│   │   ├── SKILL.md
+│   ├── waitsec-pagemaker/         # ACTIVE: Page architect (landing, blog, articles, auth, contact)
+│   │   ├── SKILL.md               # Recon, design preferences, SEO/GEO, Schema.org, UX
 │   │   └── references/            # Blueprints per archetype
-│   ├── waitsec-code/              # UPCOMING — Clean code, anti-comment pollution
+│   │       ├── landing-page.md
+│   │       ├── blog-index.md
+│   │       ├── article-single.md
+│   │       ├── about-me.md
+│   │       ├── contact-page.md
+│   │       └── auth-pages.md      # Login, register, password reset, lockout states
+│   ├── waitsec-code/              # ACTIVE: Clean code, anti-comment pollution
 │   │   └── SKILL.md
-│   └── waitsec-quality/           # UPCOMING — Security auditing, testing discipline
+│   └── waitsec-quality/           # ACTIVE: Security auditing, testing discipline
 │       └── SKILL.md
 │
 ├── rules/
@@ -150,9 +171,7 @@ waitsec/
 ## Roadmap: Core & Extensions
 
 - **Core (Active)**: The 5 foundational guardrails (`ask-first`, `anti-overengineering`, `small-diff`, `debug-first`, `verify-first`).
-- **Quality (Upcoming)**: Specialized deep-dives for `security`, `testing`, `performance`, and `accessibility`.
-- **Code (Upcoming)**: Anti-slop comments, naming conventions, and dependency discipline.
-- **UI (Upcoming)**: Anti-slop interface rules, responsive standards, and clean typography.
+- **Extensions (Active)**: `waitsec-pagemaker` for page building, `waitsec-code` for code hygiene, `waitsec-ui` for UI restraint, and `waitsec-quality` for security and testing discipline.
 
 ---
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "waitsec",
-  "version": "0.5.2",
+  "version": "0.5.4",
   "description": "Practical guardrails for AI coding agents. Hold on, think first, code less.",
   "main": "rules/waitsec.md",
   "bin": {

package/plugin.json

@@ -1,5 +1,5 @@
 {
   "name": "waitsec",
   "description": "Practical guardrails for AI coding agents. Hold on, think first, code less.",
-  "version": "0.5.2"
+  "version": "0.5.4"
 }

package/skills/waitsec-pagemaker/SKILL.md

@@ -18,7 +18,7 @@ Treat this section as the prompt you must satisfy every time you generate a page
 1. **Recon before markup.** Run Part 0, then state the detected stack, template engine, styling system, load method, version, and icon library in one short block.
 2. **Follow the project.** Use the framework, template syntax, and styling system that already exist. Never add a second CSS system. Ask before switching a native CSS project to a framework.
 3. **Install with the right method.** Tailwind with an existing build step installs through npm. Tailwind in a static project uses the CDN unless the user asks for a local install. Bootstrap and other requested frameworks install locally.
-4. **Every generated page includes JSON-LD.** Add a valid Schema.org block in `<head>`, with the type matched to the page (see Part 8). No page ships without structured data.
+4. **Every generated page includes JSON-LD.** Add a valid Schema.org block in `<head>`, with the type matched to the page (see Part 8). No page ships without structured data. Auth and error pages use a minimal `WebPage` node and are set to `noindex`.
 5. **Icons only from a library.** Use the project's existing icon library, or Lucide from CDN as the default. Never use an emoji as an icon. Never hand-write inline SVG markup. Never use an image as a UI icon.
 6. **No em dash and no en dash.** Use colons, commas, periods, parentheses, or plain hyphens in every word of the output.
 7. **No emoji anywhere.** Not in headings, body copy, buttons, badges, alt text, or metadata.
@@ -26,6 +26,7 @@ Treat this section as the prompt you must satisfy every time you generate a page
 9. **The navbar must be responsive.** A working menu button on mobile, a solid sticky background, 4 to 5 primary links, and a visible active and focus state.
 10. **Meet the SEO and GEO bar.** One H1, a unique title and meta description, a canonical URL, Open Graph tags, and answer-first content that machines can quote.
 11. **Finish with the Pre-Flight Checklist.** Do not report the page as done until every box is checked.
+12. **Translate vague style words.** When the user says minimalist, modern, clean, premium, bold, or similar, convert the word into concrete tokens using Part 10, reuse the project tokens first, and state the translation before generating. Never treat a style word as a license for gradients, glass, or heavy shadows.
 
 ---
 
@@ -40,6 +41,7 @@ Activate this skill whenever:
 - Structuring multi-section web views or routes (`/`, `/about`, `/contact`, `/blog`, `/blog/[slug]`).
 - Writing layout containers, responsive grids, navigation bars, and design themes.
 - Adding SEO metadata, Open Graph tags, or Schema.org structured data to a page.
+- Building authentication screens (login, register, password reset) or account lockout and rate-limit pages.
 
 ---
 
@@ -498,6 +500,7 @@ Structured data helps search engines and answer engines understand what the page
 | Single article or post | `Article` or `BlogPosting`, `BreadcrumbList`, `Person` as author, `Organization` as publisher |
 | About or portfolio | `ProfilePage`, `Person`, `Organization` |
 | Contact page | `ContactPage`, `Organization`, `ContactPoint` |
+| Auth page (login, register, reset, locked) | minimal `WebPage`, with the page set to `noindex, nofollow` |
 | FAQ section | `FAQPage` |
 | Any page with breadcrumbs | `BreadcrumbList` |
 
@@ -575,7 +578,22 @@ Each page blueprint in `references/` includes the exact JSON-LD block for that p
 
 ## Part 9: Page Archetypes & Blueprint Routing
 
-When the user asks for a specific type of page, read its dedicated reference guide. Each reference includes the page anatomy, the 5-point pitfalls, the SEO and GEO notes, and the exact JSON-LD block for that page type.
+### Routing Rules
+
+Each reference includes the page anatomy, the 5-point pitfalls, the SEO and GEO notes, and the exact JSON-LD block for that page type. Choose the reference like this:
+
+1. **The user names or clearly describes an archetype** (for example "about me", "contact page", "login"): read that reference first, then build.
+2. **The request is vague or random** (for example "make a page", "build something nice"): infer the closest archetype from the user's intent and the project, then read that reference. If two archetypes are plausible and the choice changes the structure, ask one short question.
+3. **The request is outside the listed archetypes** (for example pricing, dashboard, settings, search results, 404, FAQ, changelog): use the general preference below, and adapt the closest blueprint instead of forcing an unrelated one.
+4. **Always state which blueprint you are following** in the recon summary before you generate.
+
+### General Preference for Unlisted Pages
+
+- Keep every rule from Parts 0 to 8: recon, styling, UX, navbar, SEO, GEO, and structured data.
+- Reuse the anatomy of the nearest archetype. A settings page follows the form layout of the contact page, a search results page follows the list layout of the blog index, and a pricing page follows the section rhythm of a landing page.
+- Pick the Schema.org type that matches the content. Use `FAQPage` for an FAQ, `Product` or `SoftwareApplication` for pricing, and a minimal `WebPage` for utility pages such as 404 or search.
+- If no listed type fits, use a minimal `WebPage` node and keep every field accurate.
+- Never stretch a blueprint to fit a page it was not designed for.
 
 ### 1. Marketing & Conversion Pages
 * **Includes:** SaaS homepages, landing pages, product launch screens.
@@ -599,6 +617,116 @@ When the user asks for a specific type of page, read its dedicated reference gui
   - Contact Page: [`skills/waitsec-pagemaker/references/contact-page.md`](./references/contact-page.md)
   - About / Portfolio: [`skills/waitsec-pagemaker/references/about-me.md`](./references/about-me.md)
 
+### 4. Authentication & Account Access Pages
+* **Includes:** Login, register, forgot password, reset password, remember me, account locked, and login rate-limit screens.
+* **Key Blueprint:** Single-purpose centered form, one primary action, clear error and lockout states, and no user enumeration.
+* **Schema:** Minimal `WebPage` with the page set to `noindex, nofollow`.
+* *Detailed Guide:* [`skills/waitsec-pagemaker/references/auth-pages.md`](./references/auth-pages.md)
+
+---
+
+## Part 10: Design Preference Translation (Minimalist, Modern, and Similar Words)
+
+Users often describe the look with one or two vague words: "minimalist", "modern", "clean", "premium", "bold", "playful". Treat these as direction, not as a license to add generic AI decoration. Translate the word into concrete design decisions, then say the translation out loud before generating.
+
+### 1. Rules
+
+- A style word is a direction, not a spec. Convert it into decisions about color, spacing, radius, borders, shadow, typography, motion, density, and imagery.
+- The project's existing design tokens win. A style word only fills gaps the project does not already define.
+- "Modern" never means purple gradients, glassmorphism, huge soft shadows, all-pill shapes, or animated everything. Those are AI slop, not modern design.
+- If the word conflicts with the project's design language, tell the user and ask whether to follow the project or deliberately override it.
+- If two words conflict ("minimalist but bold"), resolve them by function: let the layout word drive hierarchy and density, and let the mood word drive color and decoration. State the resolution, and ask only if the conflict changes the structure.
+- If the user points to a reference site or brand, extract concrete tokens from it (type scale, accent color, spacing, radius, density) instead of copying the whole look.
+- State the final token summary in one short block before writing markup. Do not silently guess.
+
+### 2. Translator Table
+
+| User says | Usually means | Does NOT mean |
+| :--- | :--- | :--- |
+| Minimalist / Minimal | Few colors (neutrals plus one accent), generous spacing, type-led hierarchy, flat surfaces, thin or no borders | Empty pages with no hierarchy, gray-on-gray text, removing all images |
+| Modern / Contemporary | Clean type, clear grid, consistent radius, subtle borders, restrained motion | Purple gradients, glass everywhere, big shadows, neon glows, pill everything |
+| Clean | Aligned grid, consistent spacing, high-contrast text, few effects | Making everything white, tiny light-gray text, removing all styling |
+| Simple | Fewer sections, one primary action, plain language, minimal form fields | Hiding needed information, removing navigation, blank screens |
+| Premium / Luxury | Generous space, strong type contrast, one refined accent, quality imagery, restrained motion | Gold gradients, fake 3D, heavy glossy shadows, shiny badges |
+| Corporate / Professional | Structured sections, muted palette, clear typography, trust signals | Stock-photo collages, blue gradient hero, generic icon walls |
+| Playful / Fun | One brighter accent, consistent rounded radius, friendly copy, small motion | Emoji, rainbow palettes, bouncy animation on everything, comic fonts |
+| Bold | Large type, strong contrast, big sections, one loud accent | Heavy shadows alone, clashing colors, oversized everything |
+| Elegant | Refined typography, thin rules, calm palette, lots of breathing room | Script fonts, gold shimmer, over-decoration |
+| Dark | Solid dark surfaces, checked contrast, muted borders, one accent | Pure black with low-contrast gray text, neon outlines everywhere |
+| Warm / Friendly | Warm neutrals, softer radius, human copy | Orange overload, gradients everywhere, rounded everything |
+
+Local slang works the same way. "Estetik", "kece", "clean banget", "kayak startup", or "kayak Stripe" is still a direction. Map it to a row above, or ask one question with two concrete options.
+
+### 3. Handling Steps
+
+1. Map the word with the translator table.
+2. Read the project theme: existing colors, fonts, spacing scale, radius, and components. Reuse them.
+3. If the project already has a strong design language, follow it and say so. Only override when the user confirms.
+4. Resolve conflicting words by function, then state the resolution.
+5. For a reference site or brand, extract tokens, not pixels.
+6. Print the token summary: palette, accent, type scale, spacing, radius, border and shadow policy, motion.
+7. Build, then check the result against the summary.
+
+### 4. Default Tokens (When Nothing Is Specified)
+
+- **Color:** a neutral scale plus exactly one accent. Body text at least 4.5:1 contrast.
+- **Spacing:** a 4px and 8px scale, with consistent gaps between sections.
+- **Radius:** `rounded-lg` for cards, `rounded-md` for buttons and inputs. Pills only for small tags.
+- **Borders:** 1px neutral borders for structure. Shadows only for overlays such as dropdowns and modals.
+- **Type:** one sans-serif family. Body line-height around 1.5, headings around 1.2, with a fluid scale using `clamp()`.
+- **Motion:** 150ms to 200ms, only for state changes such as hover, focus, and open. Respect `prefers-reduced-motion`.
+- **Density:** comfortable on mobile, a little more generous on desktop. Never giant empty gaps by default.
+
+### 5. Pitfalls
+
+#### 1. Treating "Modern" as a Slop License
+
+* **The Bad Habit:** Reading "modern" and adding a purple gradient hero, glass cards, and floating shadows.
+* **The Problem:** The page looks like every other generated template, and the eye has no clear focus.
+* **Why It Fails:** Users recognize the generic AI look and trust the product less.
+* **Clean Fix:** Translate "modern" into clean type, a clear grid, one accent, and restrained motion. Use no gradient unless the brand already uses one.
+* **The Waitsec Way:** Modern is restraint and clarity, not decoration.
+
+#### 2. Over-Rounding and Over-Shadowing for "Premium"
+
+* **The Bad Habit:** Making every card `rounded-full` with a large soft shadow to look expensive.
+* **The Problem:** Shapes lose meaning and surfaces turn blurry.
+* **Why It Fails:** Depth cues stop working, and the page reads as cheap rather than premium.
+* **Clean Fix:** Use one consistent radius and crisp borders. Reserve shadow for real overlays, and use space and type contrast for a premium feel.
+* **The Waitsec Way:** Premium comes from space, type, and consistency, not from glow.
+
+#### 3. Going Low-Contrast for "Minimalist"
+
+* **The Bad Habit:** Choosing light gray text on white and thin faint lines to feel minimal.
+* **The Problem:** Text becomes hard to read and controls become hard to find.
+* **Why It Fails:** Minimalism is often mistaken for low contrast, and real users cannot read the result.
+* **Clean Fix:** Keep strong contrast and a clear hierarchy. Simplify with space, not with faintness.
+* **The Waitsec Way:** Minimal means fewer elements, not weaker ones.
+
+#### 4. Copying a Reference Site Blindly
+
+* **The Bad Habit:** Recreating another product's exact layout, palette, and motion.
+* **The Problem:** The result looks like a clone, and it may not fit this product's content or brand.
+* **Why It Fails:** It ignores the project's own identity and can raise legal and trust concerns.
+* **Clean Fix:** Extract the principles (spacing, type scale, accent, density) and rebuild them with the project's content and tokens.
+* **The Waitsec Way:** Learn the recipe, do not steal the dish.
+
+#### 5. Overriding the Project's Design System
+
+* **The Bad Habit:** Ignoring existing tokens and introducing new colors, fonts, and spacing because the user said "make it modern".
+* **The Problem:** The page no longer matches the rest of the product.
+* **Why It Fails:** Inconsistency across screens confuses users and multiplies maintenance work.
+* **Clean Fix:** Reuse the project tokens first. Ask before deviating, and if the user confirms, keep the change minimal and note it.
+* **The Waitsec Way:** The design system is the source of truth. A style word does not outrank it.
+
+#### 6. Conflicting Words Resolved Silently
+
+* **The Bad Habit:** Getting "minimalist but bold" and quietly picking one, then delivering a page that matches neither.
+* **The Problem:** The user expected both directions to be visible.
+* **Why It Fails:** The mismatch surfaces in review, and the work is redone.
+* **Clean Fix:** Resolve by function and state the resolution. If the conflict changes structure, ask one short question.
+* **The Waitsec Way:** Say how you resolved the brief instead of guessing in silence.
+
 ---
 
 ## Pre-Flight Checklist
@@ -620,3 +748,7 @@ Before returning generated page code to the user, verify:
 - [ ] Does the page have one `<h1>`, a unique title and meta description, a canonical URL, and Open Graph tags?
 - [ ] Is the main content server-rendered and structured so answer engines can quote it?
 - [ ] Is the JSON-LD block present, type-appropriate, using absolute URLs and ISO 8601 dates, and validated with no errors?
+- [ ] If the page is an auth page, is it set to `noindex` with a minimal `WebPage` node, does it avoid user enumeration, and does any lockout state explain the reason and offer recovery?
+- [ ] If the requested page is outside the listed archetypes, did I state the closest blueprint I adapted and keep the general preferences?
+- [ ] If the user gave a vague style word, did I translate it into concrete tokens (palette, type, spacing, radius, border and shadow policy, motion) and state the translation?
+- [ ] Did I reuse the project's design tokens before inventing new ones?

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?