triples-agentic 2.4.0

package/src/knowledge/quality/testing-types.md

@@ -0,0 +1,84 @@
+---
+name: testing-types
+description: Unit, integration, and E2E test types — what to test, recommended tools, and platform-specific frameworks
+---
+
+# Testing Types & Tools
+
+## Unit Tests
+
+Test a single function/class in complete isolation. Use mocks/stubs for dependencies.
+
+**What to unit test**:
+- Business logic functions
+- Data transformation / mapping functions
+- Input validation rules
+- State machine transitions
+- Error handling paths
+- Edge cases (empty, null, boundary values)
+
+**What NOT to unit test**:
+- Framework internals
+- Simple getters/setters with no logic
+- Third-party library behaviour
+
+### Tools by Platform
+
+| Platform | Framework | Assertion / Mocking |
+|---|---|---|
+| Web (JS/TS) | Vitest / Jest | Testing Library, Mockito |
+| Node.js | Vitest / Jest | Supertest (HTTP) |
+| Android | JUnit 5 | Mockk, Turbine (Flow) |
+| iOS | XCTest / Swift Testing | Protocols + fakes |
+| Flutter | flutter_test | mockito / mocktail |
+
+## Integration Tests
+
+Test that two or more components work correctly together.
+
+**What to integration test**:
+- API endpoint handler + service + database (real DB in test mode)
+- Authentication middleware + protected route
+- Webhook receiver + event handler
+
+**Common patterns**:
+- **Test DB**: real DB with test fixtures; rollback after each test
+- **Mock external APIs**: WireMock, MSW, MockWebServer, http.Client mock
+
+## E2E Tests
+
+Test a complete user flow from UI to database.
+
+**What to E2E test** (keep the list short):
+- Login / registration flow
+- Core purchase / conversion flow
+- Critical admin operations
+- Signup → first meaningful action
+
+**Tools by Platform**
+
+| Platform | Tool |
+|---|---|
+| Web | Playwright (preferred), Cypress |
+| Android | Espresso, UIAutomator2 |
+| iOS | XCUITest |
+| Flutter | integration_test + flutter_driver |
+| API / Contract | Postman / Newman, REST-assured |
+
+## Test Data Factories
+
+Generate realistic test data:
+
+```typescript
+// TypeScript example
+function createUser(overrides: Partial<User> = {}): User {
+  return {
+    id: crypto.randomUUID(),
+    email: 'test@example.com',
+    name: 'Test User',
+    ...overrides,
+  };
+}
+```
+
+Never reuse test data between tests — each test should set up its own state.

package/src/knowledge/web/backend/api-design.md

@@ -0,0 +1,74 @@
+---
+name: api-design
+description: REST and GraphQL API design conventions — URL structure, versioning, pagination, filtering, and documentation
+---
+
+# API Design
+
+## REST URL Conventions
+
+- Use plural nouns for resources: `/users`, `/orders`, `/products`
+- Lowercase, hyphen-separated: `/user-profiles`, not `/UserProfiles`
+- Nested resources for clear ownership: `/users/:id/orders`
+- Query params for filtering/sorting: `/products?category=electronics&sort=price_asc`
+- Avoid verbs in URLs (the HTTP method IS the verb): `POST /orders` not `POST /createOrder`
+
+## Versioning
+
+- URL versioning: `/api/v1/users` — simple, explicit, cacheable
+- Header versioning: `Accept: application/vnd.myapp.v1+json` — cleaner URLs, harder to test
+- **Default**: URL versioning for public APIs
+
+## Pagination
+
+**Cursor-based** (preferred for large/live datasets):
+```json
+{
+  "data": [...],
+  "pagination": { "nextCursor": "eyJpZCI6MTAwfQ==", "hasMore": true }
+}
+```
+
+**Offset-based** (simpler for small, stable datasets):
+```json
+{
+  "data": [...],
+  "pagination": { "page": 1, "pageSize": 20, "total": 450 }
+}
+```
+
+## Filtering & Sorting
+
+```
+GET /products?category=electronics&minPrice=100&maxPrice=500
+GET /users?sort=created_at:desc,name:asc
+GET /orders?status=pending,processing
+```
+
+## GraphQL Conventions
+
+```graphql
+type User {
+  id: ID!
+  email: String!
+  orders(first: Int, after: String): OrderConnection!
+}
+
+type Mutation {
+  createUser(input: CreateUserInput!): CreateUserPayload!
+}
+```
+
+- Use Relay connection pattern for paginated lists
+- Mutations take `input` objects, return `payload` objects
+- Use `!` for non-nullable fields; nullable is the default
+
+## API Documentation
+
+Every endpoint needs:
+- Description, method, URL, headers, path/query params
+- Request body (with types and examples)
+- All response status codes with body shapes
+- A real request/response pair as example
+
+Tools: **OpenAPI 3.x (Swagger)** for REST, **GraphQL Playground** for GraphQL.

package/src/knowledge/web/backend/api-security.md

@@ -0,0 +1,54 @@
+---
+name: api-security
+description: API security — authentication headers, CORS policy, rate limiting, deprecation policy, and client error handling
+---
+
+# API Security & Lifecycle
+
+## Authentication
+
+- **Bearer token** (JWT): `Authorization: Bearer <token>` — stateless, works for mobile and web
+- **API Key**: `Authorization: ApiKey <key>` or `X-Api-Key: <key>` — for service-to-service
+- Always HTTPS — never send credentials over plain HTTP
+- Return `401 Unauthorized` for missing/invalid token, `403 Forbidden` for insufficient permissions
+
+## CORS
+
+```http
+Access-Control-Allow-Origin: https://app.example.com
+Access-Control-Allow-Methods: GET, POST, PATCH, DELETE
+Access-Control-Allow-Headers: Authorization, Content-Type
+Access-Control-Max-Age: 86400
+```
+
+- **Never** `Access-Control-Allow-Origin: *` for authenticated APIs
+- Whitelist specific origins per environment
+- Preflight requests (`OPTIONS`) must respond with `204 No Content`
+
+## Rate Limiting Headers
+
+```http
+X-RateLimit-Limit: 100
+X-RateLimit-Remaining: 42
+X-RateLimit-Reset: 1735689600
+Retry-After: 60
+```
+
+Always tell the client when they can retry.
+
+## Versioning & Deprecation Policy
+
+1. Introduce new field/endpoint alongside old one
+2. Mark old field as `deprecated` in schema / docs
+3. Announce deprecation with a removal date (minimum 6 months notice)
+4. Monitor usage before removal; don't remove when still used
+5. Remove only when usage is zero or all clients have migrated
+
+## Client Error Handling Rules
+
+- Always handle `401` by clearing auth state and redirecting to login
+- Implement exponential backoff for `429` and `503` responses
+- Cache responses where appropriate (`Cache-Control` header from server)
+- Use request cancellation to avoid race conditions in search/autocomplete
+- Never retry `400`/`422` (client errors) — fix the request instead
+- Log all 5xx responses on the client side for debugging

package/src/knowledge/web/backend/backend-security.md

@@ -0,0 +1,84 @@
+---
+name: backend-security
+description: Backend security — JWT auth patterns, RBAC, input validation, parameterized queries, and structured logging
+---
+
+# Backend — Security & Observability
+
+## Authentication Pattern (JWT)
+
+```
+1. Client sends credentials → POST /auth/login
+2. Server validates → returns { access_token, refresh_token }
+3. Client sends: Authorization: Bearer <access_token>
+4. Server validates JWT signature + expiry on every request
+5. Refresh via POST /auth/refresh with refresh_token
+```
+
+- **Access tokens**: short-lived (15–60 min)
+- **Refresh tokens**: long-lived (7–30 days), stored httpOnly cookie
+- Never store JWTs in localStorage (XSS risk)
+- Validate signature AND expiry on every protected route
+
+## RBAC Authorization
+
+```
+User → has Role(s) → Role has Permissions → Permission gates resources/actions
+```
+
+- Check authorization in the **service layer**, not the route handler
+- Never pass user-controlled values as part of the authorization check
+- Use allowlists, not denylists
+
+## Input Validation
+
+- Validate ALL inputs at the API boundary before processing
+- Use parameterized queries or ORM — never string concatenation in SQL
+- Validate content type, file size, and MIME type for uploads
+- Schema validation library: Zod (TypeScript), Pydantic (Python), Joi (Node.js)
+
+```typescript
+// Validate at the boundary
+const schema = z.object({
+  email: z.string().email(),
+  name: z.string().min(1).max(100),
+});
+const body = schema.parse(req.body); // throws if invalid
+```
+
+## Structured Logging
+
+```typescript
+logger.info({
+  event: 'user.login',
+  userId: user.id,
+  correlationId: req.id,
+  ip: req.ip,
+  durationMs: Date.now() - startTime,
+});
+```
+
+Log levels:
+- `debug` — dev only, verbose internal state
+- `info` — normal operations (requests, business events)
+- `warn` — unexpected but handled (retry succeeded, fallback used)
+- `error` — needs investigation (unhandled exception, external failure)
+
+**Never log**: passwords, tokens, full credit card numbers, PII in plain text.
+
+## Rate Limiting
+
+```typescript
+// Express rate-limit example
+const limiter = rateLimit({
+  windowMs: 15 * 60 * 1000, // 15 minutes
+  max: 100,
+  standardHeaders: true,
+  legacyHeaders: false,
+});
+app.use('/api/', limiter);
+```
+
+- Apply stricter limits to auth endpoints (`POST /auth/login`)
+- Return `429 Too Many Requests` with `Retry-After` header
+- Consider IP-based and user-based limits separately

package/src/knowledge/web/backend/backend-structure.md

@@ -0,0 +1,78 @@
+---
+name: backend-structure
+description: Backend project structure, API response conventions, database best practices, and error handling patterns
+---
+
+# Backend — Structure & Conventions
+
+## Core Principles
+
+1. **Reliability over cleverness.** Boring code that works beats clever code that surprises you at 3am.
+2. **Fail explicitly.** Return specific error codes and messages. Never silently swallow errors.
+3. **Idempotency.** Design operations that can be safely retried.
+4. **Defense in depth.** Validate at the API layer AND at the database layer.
+
+## Project Structure (Layered)
+
+```
+src/
+├── api/          # Route handlers (HTTP layer only — no business logic)
+│   └── routes/
+├── services/     # Business logic (pure functions where possible)
+├── repositories/ # Database access (single source of truth for queries)
+├── models/       # Data models / schemas / types
+├── middleware/   # Auth, logging, rate limiting, error handling
+├── utils/        # Pure utility functions
+└── config/       # Environment configuration
+```
+
+## API Response Conventions
+
+```json
+// Success
+{ "data": { ... }, "meta": { "page": 1, "total": 100 } }
+
+// Error
+{ "error": { "code": "VALIDATION_ERROR", "message": "Email is required", "field": "email" } }
+```
+
+### Status Codes
+- `200 OK` — successful GET/PATCH
+- `201 Created` — successful POST (include `Location` header)
+- `204 No Content` — successful DELETE
+- `400 Bad Request` — invalid data (include field-level errors)
+- `401 Unauthorized` — missing or invalid authentication
+- `403 Forbidden` — authenticated but not authorized
+- `404 Not Found` — resource doesn't exist
+- `409 Conflict` — duplicate resource or state conflict
+- `422 Unprocessable Entity` — failed business rule validation
+- `429 Too Many Requests` — rate limit hit (include `Retry-After` header)
+- `500 Internal Server Error` — never expose stack traces in production
+
+## Database Best Practices
+
+- **Migrations**: every schema change is a migration file (never edit production schema manually)
+- **Transactions**: wrap multi-step operations that must succeed or fail together
+- **Indexes**: index foreign keys, columns used in WHERE/ORDER BY, and unique constraints
+- **N+1 prevention**: use joins or batch loading — never query in a loop
+- **Soft deletes**: `deleted_at TIMESTAMP` instead of hard DELETE for auditable data
+- **Timestamps**: every table has `created_at` and `updated_at` (auto-managed)
+
+## Error Handling
+
+```typescript
+// Centralized error handler (Express)
+app.use((err, req, res, next) => {
+  logger.error({ err, correlationId: req.id, method: req.method, url: req.url });
+
+  if (err instanceof ValidationError) {
+    return res.status(400).json({ error: { code: 'VALIDATION_ERROR', ...err.details } });
+  }
+  if (err instanceof NotFoundError) {
+    return res.status(404).json({ error: { code: 'NOT_FOUND', message: err.message } });
+  }
+  return res.status(500).json({ error: { code: 'INTERNAL_ERROR', message: 'An unexpected error occurred' } });
+});
+```
+
+Never expose stack traces or internal error messages to clients in production.

package/src/knowledge/web/frontend/frontend-components.md

@@ -0,0 +1,49 @@
+---
+name: frontend-components
+description: Component-driven UI development — React/Vue/Angular patterns, component design rules, and CSS architecture
+---
+
+# Frontend — Components & Frameworks
+
+## Core Principles
+
+1. **Component-driven development.** Build UIs as a tree of composable, reusable components.
+2. **State is the enemy.** Minimize local state. Lift state when shared, externalize when global.
+3. **Performance is a feature.** Users feel latency. Design for the P95 experience, not localhost.
+4. **Accessible by default.** Screen reader support and keyboard navigation are not optional extras.
+
+## Framework Conventions
+
+### React
+- Prefer functional components + hooks over class components
+- `useState` for local UI state; `useReducer` for complex local state
+- Avoid prop drilling beyond 2 levels — lift to context or state manager
+- Server Components (Next.js 13+): use for data-fetching; Client Components only for interactivity
+- `useEffect` dependency arrays must be exhaustive — lint rule: `react-hooks/exhaustive-deps`
+
+### Vue 3
+- Composition API preferred over Options API for new code
+- `ref()` for primitives, `reactive()` for objects
+- Pinia for global state (not Vuex)
+- `<script setup>` shorthand for all SFCs
+
+### Angular
+- Standalone components (Angular 14+) — no NgModule unless maintaining legacy
+- Signals for reactive state (Angular 17+)
+- OnPush change detection by default for performance
+
+## Component Design Rules
+
+- One component = one responsibility
+- Props down, events up (unidirectional data flow)
+- Keep components small: if it needs a scroll to read, split it
+- Naming: `UserProfileCard`, not `Card3` or `ProfileThing`
+- Extract presentational components from smart/container components
+
+## CSS Architecture
+
+- **Utility-first (Tailwind)**: fast iteration, no CSS naming decisions, co-located styles
+- **CSS Modules**: scoped styles without a framework; pairs well with React/Vue
+- **BEM**: use only in large teams where Tailwind is not adopted
+
+Avoid global CSS except for: CSS resets, font imports, CSS custom properties (tokens).

package/src/knowledge/web/frontend/frontend-performance.md

@@ -0,0 +1,41 @@
+---
+name: frontend-performance
+description: Frontend performance budgets, Core Web Vitals targets, bundle optimization, and frontend testing strategies
+---
+
+# Frontend — Performance & Testing
+
+## Performance Budgets
+
+| Metric | Target | Tool |
+|---|---|---|
+| Largest Contentful Paint (LCP) | < 2.5s | Lighthouse |
+| First Input Delay (FID) | < 100ms | Web Vitals |
+| Cumulative Layout Shift (CLS) | < 0.1 | Lighthouse |
+| Bundle size (initial JS) | < 200KB gzipped | webpack-bundle-analyzer |
+| Image size (hero) | < 200KB WebP | Squoosh / ImageOptim |
+
+## Bundle Optimization
+
+- Code-split at the route level — each route loads only its own JS
+- Tree-shake unused exports (ensure your bundler config enables it)
+- Audit bundle size before merging large dependency additions
+- Prefer lighter alternatives: `date-fns` over `moment`, `zod` over `yup`
+
+## Render Performance
+
+- Avoid unnecessary re-renders: use `memo`, `useMemo`, `useCallback` only when measured, not preemptively
+- Use `React.lazy` / dynamic imports for below-fold components
+- Use `ListView.builder` pattern (virtual list) for large dynamic lists
+- Avoid inline object/function creation in JSX that defeats memoization
+
+## Testing Frontend Code
+
+- **Unit test**: pure functions, custom hooks, utility functions
+- **Component test**: render component → simulate user action → assert output (Testing Library)
+- **E2E test**: critical user flows only (login, checkout, core CRUD) — Playwright or Cypress
+
+### Testing Library Principles
+- Query by role, label, or text — not by CSS class or test ID
+- Test what the user sees, not implementation details
+- `getByRole('button', { name: /submit/i })` not `getByTestId('submit-btn')`

package/src/knowledge/web/frontend/frontend-state.md

@@ -0,0 +1,59 @@
+---
+name: frontend-state
+description: Frontend state management decision guide, routing conventions, and form handling patterns
+---
+
+# Frontend — State, Routing & Forms
+
+## State Management Decision
+
+```
+Is the state:
+├── Used by one component only?          → useState / ref()
+├── Used by a subtree of components?     → Context / provide-inject
+├── Used app-wide, changes frequently?   → Zustand / Pinia / NgRx
+└── Server data (API responses)?         → React Query / SWR / TanStack Query
+```
+
+Never use global state for server data — that's what data-fetching libraries are for.
+
+## Recommended Libraries
+
+| Need | React | Vue 3 | Angular |
+|---|---|---|---|
+| Server state | TanStack Query / SWR | VueQuery | NgRx/data or custom |
+| Global client state | Zustand / Jotai | Pinia | NgRx |
+| Forms | React Hook Form + Zod | VeeValidate + Zod | Reactive Forms |
+| Routing | React Router / Next.js | Vue Router / Nuxt | Angular Router |
+
+## Routing Conventions
+
+- File-based routing where supported (Next.js, Nuxt, SvelteKit)
+- Route names map to user intent: `/dashboard`, `/settings/profile`, not `/page3`
+- Lazy-load route components to reduce initial bundle
+- Guard authenticated routes at the router level, not inside components
+
+## Form Handling
+
+- **React**: React Hook Form (minimal re-renders) + Zod for schema validation
+- **Vue**: VeeValidate + Zod
+- **Angular**: Reactive Forms + Zod or built-in validators
+- Never submit a form without client-side validation
+- Never trust client-side validation on the server — validate both sides
+
+## Data Fetching Patterns
+
+```typescript
+// React Query example
+const { data, isLoading, error } = useQuery({
+  queryKey: ['users', userId],
+  queryFn: () => fetchUser(userId),
+  staleTime: 5 * 60 * 1000, // 5 minutes
+});
+
+// Mutation
+const mutation = useMutation({
+  mutationFn: updateUser,
+  onSuccess: () => queryClient.invalidateQueries({ queryKey: ['users'] }),
+});
+```

package/src/knowledge/web/frontend/web-accessibility.md

@@ -0,0 +1,51 @@
+---
+name: web-accessibility
+description: WCAG 2.1 AA compliance — semantic HTML, ARIA patterns, keyboard navigation, and color contrast
+---
+
+# Web Accessibility (a11y)
+
+Target: **WCAG 2.1 AA**
+
+## Semantic HTML
+
+Use the correct element for the job:
+- `<button>` for actions, `<a>` for navigation — never `<div>` with onClick
+- `<nav>`, `<main>`, `<aside>`, `<footer>` for landmark regions
+- Heading hierarchy: one `<h1>` per page, `<h2>` for sections (no skipping)
+- `<table>` with `<thead>`, `<th scope="col">`, `<caption>` for data tables
+- `<form>` with `<label>` associated to every input (via `for` attribute or wrapping)
+
+## ARIA
+
+Use ARIA only when semantic HTML is insufficient:
+- `aria-label` — when text content doesn't describe the element (icon-only buttons)
+- `aria-expanded` — for accordion/disclosure patterns
+- `aria-live="polite"` — for dynamic content updates (loading states, notifications)
+- `aria-describedby` — to link error messages to their input fields
+- Never add `role="button"` to a `<div>` — use `<button>` instead
+
+## Keyboard Navigation
+
+- All interactive elements must be reachable via `Tab`
+- All actions must be triggerable via `Enter` / `Space`
+- Focus must be visible (`:focus-visible` CSS, never `outline: none` without a replacement)
+- Modal dialogs must trap focus while open; restore focus on close
+- Skip nav link: `<a href="#main-content" class="skip-link">Skip to main content</a>`
+
+## Color & Contrast
+
+- Text contrast ratio ≥ 4.5:1 (normal text), ≥ 3:1 (large text: 18px+ or bold 14px+)
+- Never use color alone to convey information — add icons, patterns, or text
+- Check with: WebAIM Contrast Checker, axe DevTools browser extension
+
+## Common Mistakes to Avoid
+
+| Mistake | Fix |
+|---|---|
+| `<div onClick>` | Use `<button>` or `<a>` |
+| Missing alt text | Add `alt=""` for decorative, meaningful alt for content |
+| Form inputs without labels | Add `<label for="id">` or `aria-label` |
+| Low contrast text | Minimum 4.5:1 ratio |
+| Focus indicator hidden | Never `outline: none` without a visible replacement |
+| Only color indicates errors | Add icon + text alongside color |

package/src/knowledge/web/frontend/web-performance.md

@@ -0,0 +1,51 @@
+---
+name: web-performance
+description: Web performance optimization — critical rendering path, loading strategies, caching, image optimization, and PWA
+---
+
+# Web Performance
+
+## Critical Rendering Path
+
+```
+HTML parsed → DOM built → CSS parsed → CSSOM built → Render Tree → Layout → Paint → Composite
+```
+
+Minimize blocking resources in `<head>`. Defer non-critical JS. Inline critical CSS.
+
+## Loading Strategies
+
+- **Images**: `loading="lazy"` for below-fold; `loading="eager"` + preload for hero
+- **Fonts**: `font-display: swap` to prevent FOIT; preload primary font file
+- **Scripts**: `defer` or `async` for non-critical; module scripts are deferred by default
+- **CSS**: inline critical CSS; load rest with `rel="preload"` as stylesheet
+
+## Caching
+
+- **Static assets**: `Cache-Control: max-age=31536000, immutable` (with content hash in filename)
+- **API responses**: `Cache-Control: private, max-age=60` or `no-cache` based on freshness needs
+- **Service Worker**: cache-first for shell, network-first for API data
+
+## Image Optimization
+
+- Use `<picture>` with `srcset` for responsive images
+- WebP for photographs, SVG for icons and illustrations
+- Always set explicit `width` and `height` attributes to prevent CLS
+- Use a CDN with on-the-fly image resizing for user-generated content
+- Target hero images < 200KB, other content images < 100KB
+
+## PWA Checklist
+
+- [ ] HTTPS
+- [ ] Web App Manifest with icons, name, theme color
+- [ ] Service Worker with offline fallback
+- [ ] Responsive design (passes mobile-friendly test)
+- [ ] Fast initial load (LCP < 2.5s)
+- [ ] Installable (meets browser criteria)
+
+## Browser Compatibility
+
+Target: last 2 stable versions of Chrome, Firefox, Safari, Edge.
+- Check support at: caniuse.com
+- Use feature detection, not user-agent sniffing
+- **Test in Safari** — it's the new IE for many modern web features

package/src/knowledge/web/frontend/web-security.md

@@ -0,0 +1,59 @@
+---
+name: web-security
+description: Web security — CSP, HTTPS/HSTS, XSS prevention, CSRF protection, and Subresource Integrity
+---
+
+# Web Security
+
+## Content Security Policy (CSP)
+
+Block inline scripts and unauthorized origins:
+
+```http
+Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{random}'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:
+```
+
+- Never use `'unsafe-inline'` for scripts in production
+- Use nonces for inline scripts that cannot be moved to external files
+- Report violations with `Content-Security-Policy-Report-Only` before enforcing
+
+## HTTPS & Transport Security
+
+```http
+Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
+X-Frame-Options: DENY
+X-Content-Type-Options: nosniff
+Referrer-Policy: strict-origin-when-cross-origin
+```
+
+- Enforce HTTPS at the load balancer; never serve on HTTP
+- Register for HSTS preload at hstspreload.org for maximum protection
+
+## XSS Prevention
+
+- Never use `innerHTML`, `outerHTML`, or `document.write` with user content
+- Use `textContent` for text nodes
+- Sanitize HTML with DOMPurify when rich HTML input is required
+- React, Vue, Angular escape by default — use their escape hatches (`dangerouslySetInnerHTML`) only with pre-sanitized content
+
+## CSRF Protection
+
+- Use `SameSite=Lax` or `SameSite=Strict` cookies for session tokens
+- Add CSRF tokens to all state-changing form submissions
+- Double-submit cookie pattern for stateless CSRF protection
+
+## Subresource Integrity (SRI)
+
+Add `integrity` attributes to third-party scripts and styles:
+
+```html
+<script src="https://cdn.example.com/lib.js"
+        integrity="sha384-abc123..."
+        crossorigin="anonymous"></script>
+```
+
+## Third-Party Scripts
+
+- Audit every third-party script — each is a potential XSS vector
+- Load analytics, chat widgets, etc. with `async` and in a sandboxed context
+- Regularly audit what third-party scripts have access to (use browser devtools)