Landing Page & Public Site -- 5 Whys Root Cause Analysis¶

Generated: 2026-02-25 | Method: 5 Whys Deep Dive (symptom -> why chain -> root cause -> systemic fix) Source Deep-Dive: docs/deep-dive-landing-page-public-site.md Chains Analyzed: 6 symptom-to-root-cause chains covering broken caching, unsanitized HTML, zero test coverage, missing SEO, dead CTAs, and leaked console.log statements Analyst: Mary -- treasure hunter, follower of breadcrumbs, collector of smoking guns

Executive Summary¶

Six recurring failure patterns across 70 documented issues in the Landing Page & Public Site module trace back to 3 systemic root causes: absent automated quality gates, visual-demo-first development culture, and no security engineering discipline. These root causes are not independent -- they form a reinforcing triangle where each failure mode enables and conceals the other two. The good news? A single CI pipeline with 4 rules would have prevented 4 of 6 patterns entirely.

Chain A: Why Is unstable_cache Broken in ALL 5 Public API Functions?¶

Symptom: Every unstable_cache call in src/api/public/ uses a static cache key that ignores the function's parameters. getBlogs({ page: 2 }) returns page 1. getNavigationLinks("footer") returns navbar links. getSettingByGroup("contact") returns site settings. The entire public site's data layer is poisoned after the first cache population.

Root Cause: Copy-paste development without abstraction, enabled by total absence of code review and automated quality gates.

The Smoking Gun: settings.js:16 -- console.log("Failed to fetch navigation links"). This is the treasure-hunter's dream: a literal forensic fingerprint of copy-paste. The developer copied navigation-links.js to create settings.js, changed the fetch URL, but left the error messages AND the cache key pattern untouched. This single line proves the bug's propagation mechanism.

Pattern Name: "Clone and Forget" -- a working (or seemingly working) implementation is duplicated across files without understanding the invariants. Each clone inherits both the structure and the bugs.

Fix: Include parameters in cache keys (5 files, 1 line each, 30 min). Structural fix: Extract a shared cachedFetch(key, params, fetcher) utility so the cache-key-includes-params invariant is enforced once, not copy-pasted five times.

Chain B: Why Is dangerouslySetInnerHTML Used Without Sanitization?¶

Symptom: Raw HTML from the database is rendered directly into the DOM in 4 locations across the frontend -- 2 on public pages (blog content, dynamic page description) and 2 in the email template builder (template preview, template modal). No sanitization library is installed anywhere in the project.

Root Cause: No security engineering discipline -- no sanitization libraries, no security-focused lint rules, no threat modeling during development. Combined with the "trusted admin" assumption that collapses under the documented self-role-change vulnerability (PATCH /users/profile allows privilege escalation).

The Attack Chain: The documented self-role-change vulnerability means an attacker can: register -> escalate to admin via profile update -> create blog post or dynamic page with <script>document.cookie</script> -> every public visitor executes the attacker's JavaScript. This is not theoretical -- it is 4 API calls.

Evidence Inventory (9 total dangerouslySetInnerHTML locations): 1. blog-page-frontend.jsx:94 -- blog content (PUBLIC, XSS vector) 2. dynamic-page.jsx:20 -- dynamic page description (PUBLIC, XSS vector) 3. email-templates-page.jsx:805 -- template HTML preview (ADMIN, lower risk) 4. email-preview.jsx:288 -- col1Content (ADMIN, lower risk) 5. email-preview.jsx:292 -- col2Content (ADMIN, lower risk) 6. email-preview.jsx:297 -- col3Content (ADMIN, lower risk) 7. pages-page.jsx:503 -- page description in admin list (ADMIN, lower risk) 8. utils.js:39 -- utility line renderer (CONTEXT DEPENDENT) 9. chart.jsx:66 -- chart tooltip (ADMIN, lower risk)

Fix: Install DOMPurify, create a <SafeHTML> wrapper component, use it in all 9 locations (2 hours). Structural fix: Add react/no-danger ESLint rule as error (not warn) so future usages are blocked at lint time.

Chain C: Why Is There Zero Test Coverage on the Entire Public Site?¶

Symptom: No test files exist anywhere in the frontend codebase. No test runner is installed. No test dependencies in package.json. No test script in package.json. Statement, branch, function, and line coverage: 0% across all 81 files and ~8,200 lines of code.

Root Cause: Absent SDLC -- no CI/CD, no quality gates, no automated feedback loops. Testing requires infrastructure that enforces it; without that infrastructure, zero test coverage is the natural equilibrium.

What Zero Tests Enable (the cascade): - Cache key bugs (Chain A) ship undetected -- a single test expect(getBlogs({page:1})).not.toEqual(getBlogs({page:2})) would catch C1-C5 - XSS vulnerabilities (Chain B) persist -- a test rendering <script>alert(1)</script> would verify sanitization - SEO metadata gaps (Chain D) go unnoticed -- a test checking generateMetadata output would catch H2, M2-M4 - Dead CTAs (Chain E) are invisible -- a test asserting expect(button).toHaveAttribute('href') would catch H1 - console.log statements (Chain F) slip through -- a test or lint rule would flag them

The Damning Statistic: 81 files. 8,200+ lines of code. 70 documented issues. 0 tests. 0 test files. 0 test dependencies. 0%.

Fix: Initialize Vitest + Testing Library (1 hour setup). Write smoke tests for the 5 public API functions and 7 route pages (4 hours). Structural fix: CI pipeline that blocks merge on test failure (ADR-5 in the ADR document).

Chain D: Why Is SEO Metadata Missing on 4 of 7 Public Routes?¶

Symptom: Only 3 of 7 public routes have generateMetadata exports: /blogs, /blogs/[slug], /[slug]. The remaining 4 -- homepage (/), author (/author/[slug]), category (/category/[slug]), and contact (/contact) -- have no SEO metadata. The MOST important page (homepage) has the LEAST SEO optimization.

Root Cause: No cross-cutting product ownership and no definition of done that includes SEO. Metadata is treated as a code task rather than a product requirement, so it only appears where the code naturally supplies it.

The Irony: The root layout (layout.js) has a sophisticated generateMetadata function that fetches settings from the API, builds Open Graph tags, Twitter cards, and title templates. Someone clearly understood SEO for the root layout. But that knowledge did not propagate to the 4 child routes. The SEO implementation is "all or nothing" depending on whether that specific developer built that specific page.

Evidence -- The 4 Missing Routes:

Fix: Add generateMetadata to all 4 routes (45 min). Structural fix: Pre-merge checklist or CI audit that verifies every route in (main-layout)/ exports metadata.

Chain E: Why Are All 7 CTA Buttons Non-Functional?¶

Symptom: The landing page has 7 call-to-action buttons across 3 sections (hero, pricing, CTA). Every single one renders visually -- styled, animated, responsive -- but does absolutely nothing when clicked. No href, no onClick, no router.push(). The primary conversion pathway for the entire marketing site is decorative.

Root Cause: Visual-demo mindset -- modules built to LOOK complete rather than BE complete. The landing page and the application are parallel universes with contradictory data, connected only by sharing a node_modules directory.

The Pricing Contradiction (Exhibit A):

These two files exist in the same repository, describe the same product, and agree on nothing.

The Button Inventory:

Fix: Wire buttons to /register and /contact (30 min). Unify pricing data source (2 hours). Structural fix: Integration test that verifies every <Button> on the landing page has either href or onClick.

Chain F: Why Are console.log Statements Left in Production Code?¶

Symptom: At least 3 console.log statements exist in production route handlers: category/[slug]/page.js:19 logs "category blogs" with the full data array, [slug]/page.js:42 logs the slug, blog-page-frontend.jsx:10 logs the full blog object. Additionally, the copy-pasted error logs in settings.js and all API modules log to console on every error.

Root Cause: No automated quality gates -- no no-console ESLint rule, no pre-commit hooks, no CI enforcement. Console.log statements are the visible symptom of a deeper absence of linting discipline.

The Evidence Trail: - eslint.config.mjs: extends("next/core-web-vitals") only -- no no-console rule - package.json: no Husky, no lint-staged, no pre-commit hook dependencies - No .husky/ directory - No .github/workflows/ directory - 3+ explicit console.log statements in route handlers, plus copy-pasted error logs in all 5 API modules

Fix: Add no-console: ["error", { allow: ["warn", "error"] }] to ESLint config (5 min). Remove existing console.log statements (15 min). Structural fix: Husky + lint-staged pre-commit hook that runs ESLint on staged files.

Root Cause Map¶

All 6 chains converge on 3 systemic root causes. Here is the mapping:

                      ┌─────────────────────────────┐
                      │  ROOT CAUSE #1               │
                      │  No Automated Quality Gates  │
                      │  (No CI, No hooks, No lint)  │
                      └──────────┬──────────────────-┘
                                 │
              ┌──────────────────┼──────────────────┐
              │                  │                  │
              ▼                  ▼                  ▼
        ┌──────────┐     ┌──────────┐      ┌──────────┐
        │ Chain A  │     │ Chain C  │      │ Chain F  │
        │ Broken   │     │ Zero     │      │ console  │
        │ Cache    │     │ Tests    │      │ .log in  │
        │ Keys     │     │          │      │ prod     │
        └──────────┘     └──────────┘      └──────────┘

                      ┌─────────────────────────────┐
                      │  ROOT CAUSE #2               │
                      │  Visual-Demo Mindset         │
                      │  (Look like SaaS, not be it) │
                      └──────────┬──────────────────-┘
                                 │
                      ┌──────────┼──────────┐
                      │                     │
                      ▼                     ▼
                ┌──────────┐         ┌──────────┐
                │ Chain D  │         │ Chain E  │
                │ Missing  │         │ Dead     │
                │ SEO      │         │ CTAs     │
                └──────────┘         └──────────┘

                      ┌─────────────────────────────┐
                      │  ROOT CAUSE #3               │
                      │  No Security Discipline      │
                      │  (No sanitize, no threat     │
                      │   model, no security lint)   │
                      └──────────┬──────────────────-┘
                                 │
                                 ▼
                           ┌──────────┐
                           │ Chain B  │
                           │ Unsani-  │
                           │ tized    │
                           │ HTML     │
                           └──────────┘

Cross-chain reinforcement: - Root Cause #1 enables Root Cause #3: if there were a CI pipeline, react/no-danger would be enforceable - Root Cause #1 enables Root Cause #2: if there were tests, dead CTAs and missing SEO would be caught - Root Cause #2 enables Root Cause #1: "it's just a demo" mindset deprioritizes testing and CI investment - Chain C (zero tests) is both a symptom of Root Cause #1 AND an amplifier of all other chains

3 Systemic Issues¶

Systemic Issue #1: Total Absence of Feedback Loops¶

Chains affected: A, B, C, F (4 of 6)

This codebase has no mechanism for telling the developer "something is wrong." No tests fail. No lint rules block. No CI rejects. No pre-commit hook catches. The developer's feedback loop is: write code -> look at browser -> looks okay -> push.

How it manifests: - unstable_cache with wrong keys LOOKS correct -- the page renders, just with wrong data (Chain A) - dangerouslySetInnerHTML LOOKS correct -- the HTML renders beautifully, the XSS is invisible until exploited (Chain B) - Console.log LOOKS harmless -- the page works fine, the logs are invisible unless you check server output (Chain F) - Zero tests means zero failures -- a false green signal (Chain C)

The insight: Every bug in this codebase is a bug that LOOKS correct to a human eye in a browser. The bugs are semantic, not visual. Only automated tooling can catch semantic bugs at scale. This project has zero automated tooling.

Systemic Issue #2: Modules as Islands¶

Chains affected: A, D, E (3 of 6)

Every module was built as a self-contained island. The landing page does not know about the registration flow. The pricing constants do not know about the subscription module. The blog routes do not know about SEO requirements. The 5 API files do not know they are copies of each other.

How it manifests: - 5 API files copy-pasted instead of sharing an abstraction -- each island reinvents the unstable_cache wrapper (Chain A) - Landing page pricing (\(29/\)79/\(199) contradicts dashboard pricing (\)19/\(29/\)59/$99) -- two islands with different realities (Chain E) - SEO metadata appears only where a specific developer thought about it -- no island-crossing requirement (Chain D)

The insight: There is no "architect" role in this project -- no one whose job is to see how the islands connect. Each file was written by someone solving a local problem without awareness of the global system.

Systemic Issue #3: Security as Afterthought¶

Chains affected: B (and implicitly A via data integrity)

Security is not a design constraint in this codebase. It is neither considered during development (no threat modeling), nor enforced during review (no security lint rules), nor verified during testing (no security tests). The dangerouslySetInnerHTML API is a bright red warning sign from React itself -- and it is used 9 times without a single safety measure.

How it manifests: - 9 dangerouslySetInnerHTML usages, 0 sanitization calls (Chain B) - No DOMPurify, no sanitize-html in package.json (Chain B) - No react/no-danger ESLint rule (Chain B) - No CSRF protection on contact form (Expert Panel finding #56) - No rate limiting on any public endpoint

The insight: Security is not "one more feature to add." Security is a property of the development PROCESS. You cannot bolt security onto a codebase that was built without it -- you have to retrofit it into the development workflow (lint rules, CI checks, dependency audits).

Fix-One-Fix-Many: The Leverage Points¶

The beauty of systemic root causes is that a single fix at the root prevents multiple symptoms. Here is the leverage analysis:

Highest Leverage: CI Pipeline with 4 Rules (Root Cause #1)¶

A single GitHub Actions workflow that enforces these 4 checks would have prevented 4 of 6 chains:

Effort: 8-12 hours (ADR-5 from the ADR document) Impact: Prevents recurrence of 4/6 root patterns across ALL future modules, not just the public site

Second Leverage: Shared Utility Abstraction (Chain A specific)¶

// src/api/public/cached-fetch.js -- the function that should exist
import { unstable_cache } from "next/cache";

export function createCachedFetch(name, fetcher) {
  return (params = {}) => {
    const cacheKey = [name, JSON.stringify(params)];
    return unstable_cache(
      () => fetcher(params),
      cacheKey,
      {
        revalidate: (parseInt(process.env.NEXT_PUBLIC_CACHE_TIME) || 1) * 60 * 60,
        tags: [name],
      }
    )();
  };
}

Effort: 30 minutes to create + 30 minutes to migrate 5 files Impact: Eliminates the copy-paste pattern entirely. The cache-key-includes-params invariant is defined once. Future API functions cannot get it wrong because they do not handle cache keys at all.

Third Leverage: <SafeHTML> Component (Chain B specific)¶

// src/components/common/safe-html.jsx
import DOMPurify from "dompurify";

export function SafeHTML({ html, className }) {
  const clean = DOMPurify.sanitize(html || "");
  return <div className={className} dangerouslySetInnerHTML={{ __html: clean }} />;
}

Effort: 15 minutes to create + 30 minutes to replace all 9 raw usages Impact: Eliminates ALL stored XSS vectors. New developers use <SafeHTML> instead of dangerouslySetInnerHTML directly. The react/no-danger lint rule catches anyone who tries to bypass it.

Ordered List of Systemic Fixes¶

Prioritized by leverage (impact per hour of effort), not by severity:

Phase 1 (Ship Blockers): Items 1-5 -- ~3 hours, resolves 15 issues including all 7 Criticals Phase 2 (Structural Prevention): Items 6-12 -- ~14 hours, prevents all 6 patterns from recurring

Total: ~17 hours of investment to resolve 15 immediate issues and structurally prevent 6 systemic failure patterns across all current and future modules.

The Reinforcing Cycle¶

    ┌──────────────────┐
    │ No Quality Gates │◄───── "It's just a boilerplate"
    │ (CI, hooks, lint)│         (visual-demo mindset)
    └────────┬─────────┘                ▲
             │                          │
             ▼                          │
    ┌──────────────────┐       ┌────────┴─────────┐
    │  Can't Catch     │──────►│  Copy-Paste &    │
    │  Bugs at         │       │  Island-Building │
    │  Commit/Merge    │       │  Feel "Efficient"│
    └──────────────────┘       └────────┬─────────┘
                                        │
                                        ▼
                               ┌──────────────────┐
                               │  Bugs Accumulate  │
                               │  Invisibly         │
                               │  (70 issues, 0     │
                               │  ever caught       │
                               │  automatically)    │
                               └──────────────────┘

Breaking the cycle: Attack Priority #1 (fix cache keys) for immediate relief. Then attack Priority #7-9 (testing + hooks + CI) to install the feedback loops that prevent the cycle from restarting. Without feedback loops, every fix in this document is a one-time patch. With feedback loops, every fix is a permanent guard rail.

Cross-References¶

• ADRs (architectural solutions): docs/extra-docs/landing-page-adrs.md
• Attack scenarios (exploitation of Chain B): docs/extra-docs/landing-page-attack-scenarios.md
• Pre-mortem (failure consequences): docs/extra-docs/landing-page-pre-mortem.md
• Email template root cause analysis (same patterns found): docs/extra-docs/email-template-root-cause-analysis.md
• RBAC deep-dive (#76, super_admin bypass -- same root as Chain B): docs/deep-dive-user-management-rbac.md

Generated by BMAD Advanced Elicitation -- 5 Whys Deep Dive method | 2026-02-25