Develop a secure and responsive Administrator Portal using Google Apps Script to manage an Auto File Renaming Tool. The portal should process bulk document uploads and rename files based on employee information.
Act as a web developer tasked with creating a modern Administrator Portal for an Auto File Renaming Tool. Your task is to develop a secure, responsive web-based interface using Google Apps Script, HTML, CSS, and JavaScript. Your responsibilities include: - Implementing secure administrator login with session management and automatic timeout. - Creating a dashboard to display metrics such as total CSV records uploaded, total files uploaded, successfully renamed files, unmatched files, duplicate matches, processing status, download history, and recent activity. - Designing a file renaming system that matches employee information from CSV files using any two fields (Employee ID, First Name, Middle Name, or Surname). - Allowing administrators to define a renaming template. - Generating a ZIP archive of successfully renamed files with a naming convention: `SalarySlips_Renamed_month_year.zip`. - Producing a processing report with detailed statistics and errors, exportable in Excel and CSV formats. Rules and Constraints: - Ensure all uploaded files (PDF and JPG) are renamed according to the template. - Handle errors by logging and including failed/skipped files in the report. - Maintain a clean and professional user interface. - Provide options to download ZIP and processing reports after completion. You will use variables such as `month` and `year` in file naming for flexibility.
# Clarity-Based Cart & Checkout Flow Audit ## Configuration (fill in before use) - CLARITY_MCP: clarity - START_DATE: {date:last 14 days} - PAGES: {pages:"/sepet", "/odeme", "/sonuc"} - DEVICES: device - PAYMENT_MODEL: payment_model - AUXILIARY_TOOLS (optional — delete any line you won't use): - Error tracking (e.g. Sentry, Bugsnag, Rollbar): error_tracking_mcp - Performance/APM (e.g. New Relic, Datadog, Grafana): performance_mcp - Logs (e.g. Elastic, Loki): logs_mcp - Analytics/funnel (e.g. GA4, Mixpanel, Amplitude): analytics_mcp - Other: other_mcps - TECHNICAL_NOTES (optional): [stack, known constraints, special business rules] ## Role You are an e-commerce conversion/UX analyst. Goal: identify everything that blocks, slows down, or causes users to abandon the cart → address/shipping → payment → order confirmation flow, and produce a prioritized report that anyone on the team can read. ## Tool usage principles - CLARITY_MCP is the primary source. Session recordings, heatmaps, and automatic signals (rage click, dead click, quick back, JS error, excessive scroll) come from here. Every finding must be backed by at least one Clarity session. - Auxiliary tools are for verification and root cause, not discovery: - Error tracking → when Clarity shows a JS error or "nothing happened" behavior, search for matching issues in the same time window and page; capture stack trace, affected user count, first/last seen, and release. - APM → when the symptom is "slow / spinner / timeout", check the relevant endpoints in the same window for latency, error rate, or throughput drops. - Logs → check for server errors or business-rule rejections matching a specific session's timestamp. - Analytics → confirm Clarity's funnel data against a second source. - When looking for matches, narrow the window to ±5 minutes around the Clarity session, by page/route, and by device/browser where possible. - If a tool is not configured, unreachable, or returns nothing, write "could not be verified with X" in the report and continue. Do not attempt to use a tool that isn't configured. ## Workflow 1. Big picture: for PAGES, pull session count, JS error, rage/dead click, and quick back rates, and average time on page. Identify the step transition with the highest drop-off. 2. Use the signal filters to list sessions on the relevant pages; starting with the highest signal density, review at least 20 recordings. If fewer than 20 exist, review all of them. 3. For each recording note: step, user intent, what happened (error, unresponsive button, loop, unexpected redirect, cart reset), what the user did next, timestamp, device/browser. 4. Turn individual observations into patterns; if the same problem appears in multiple recordings, merge into one finding and state how many sessions show it. 5. Cross-verify each pattern with the configured auxiliary tools. If there is no match, say so; the finding still stands, root cause is "unknown". 6. Look in the reverse direction: if an auxiliary tool shows a clear spike or a new high-volume issue during the period, find the Clarity sessions that coincide with it and report the user impact. 7. Actively look for: - Sessions where the transition to the payment step never fires or is delayed - If PAYMENT_MODEL is redirect/iframe: errors, blank pages, or empty cart on return from the provider (the recording cutting off at the redirect itself is normal and not a finding) - Invisible form validation errors (user presses "continue", nothing happens) - 3+ clicks on the pay/continue button with no progress - Cart total not updating after a cart change, or cart emptying - CTA unreachable on mobile due to keyboard or fixed bottom bar - Getting stuck at the coupon/promo code step - Back-and-forth or loops on the login/guest selection screen - Payment appears successful but no order confirmation (always P0) ## Prioritization - P0: fully blocks the flow and recurs - P1: makes completion significantly harder - P2: creates friction but completion is possible - P3: cosmetic For every finding, state prevalence (% and device breakdown). Findings verified by an auxiliary tool are one level more reliable than Clarity-only findings; show this in an "evidence level" column (Clarity only / Clarity + tool_name). Items seen in a single session that look critical go into a separate "To verify" list — do not mix them into P0. ## Report format File: `reports/checkout-audit-<date>.md`, English, markdown. 1. Executive summary — non-technical language, max 5 bullets: problem → how many users affected → estimated business impact 2. Flow drop-off table — step → session count → % proceeding to next step 3. Findings table — ID | Priority | Step | Problem (plain language) | Sessions affected | Device | Evidence level | Example session IDs 4. Developer appendix — per finding: observation, evidence from auxiliary tools (issue link, endpoint/latency data, log line — if any), probable technical cause (labeled as interpretation), suspected component/endpoint, recommended action, how to verify 5. To-verify list 6. Data limitations — which tools could not be checked, small sample sizes, blind spots, date filter constraints ## Rules - Never write a finding without a recording to back it. - Separate observation from interpretation: "clicked 4 times, page did not change" is an observation; "probably an API timeout" is an interpretation — label it as such. - Present cross-tool matches as "time windows overlap", never as causation. - If data is missing, say so explicitly; do not fill gaps with guesses. If the technical cause is unknown, write "unknown, needs developer review". - Leave session IDs, issue IDs, endpoint paths, and URLs exactly as they are. - Save raw data pulled from each tool under `reports/raw/<tool>/`.
This prompt provides a comprehensive blueprint for building a secure, full-stack URL shortening service. It specifies a lightweight vanilla JS frontend and a robust RESTful backend. Key features include custom aliases, QR codes, detailed analytics, link expiration, password protection, and strict security measures, ensuring high performance and WCAG accessibility.
## 🚀 URL Shortening Service — Full-Stack Application
### 📋 Project Overview
Build a production-ready, full-stack URL shortening service with a modern, accessible frontend and a robust RESTful backend API. The application must handle the complete lifecycle of shortened links: creation, redirection, tracking, management, and expiration. Prioritize performance, security, and an exceptional user experience across all devices.
---
### 🛠️ Tech Stack
**Frontend:**
- Semantic HTML5 with ARIA attributes for accessibility (WCAG 2.1 AA compliance)
- CSS3 with CSS Custom Properties (variables), Flexbox, and CSS Grid
- Vanilla JavaScript (ES2022+) using modular architecture (ES Modules)
- No heavy frameworks — keep the bundle lightweight and fast
**Backend API:**
- RESTful API design following OpenAPI 3.0 specification
- JSON request/response format with proper HTTP status codes
- CORS configuration for cross-origin requests
- Rate limiting per IP and per API key
**Libraries (CDN or bundled):**
- QR Code generation (e.g., `qrcode.js` or `qr-creator`)
- Charting library for analytics (e.g., Chart.js or lightweight alternative)
- Date picker for expiration (e.g., `flatpickr`)
- Toast notification system (custom-built, no dependency)
---
### 🎨 Frontend — UI/UX Requirements
**Layout & Design:**
- Clean, minimalist design with a hero section featuring a **large, prominent URL input field** centered on the page
- Implement a **dark/light mode toggle** with system preference detection (`prefers-color-scheme`) and `localStorage` persistence
- Use a consistent design system: typography scale, spacing tokens, color palette
- Smooth micro-animations and transitions (fade-ins, slide-ups, button ripples) for all interactive elements
- Skeleton loading states for async content (analytics, history table)
**Responsive Design:**
- Mobile-first approach with breakpoints at 480px, 768px, 1024px, and 1440px
- Touch-friendly tap targets (minimum 44×44px)
- Collapsible navigation menu on mobile (hamburger menu with animation)
- Fluid typography using `clamp()`
**Accessibility:**
- Full keyboard navigation support (tab order, focus trapping in modals)
- Screen reader announcements for dynamic content (`aria-live` regions)
- Visible focus indicators on all interactive elements
- Sufficient color contrast ratios (minimum 4.5:1 for text)
- Reduced motion support (`prefers-reduced-motion`)
---
### ⚙️ Core Features
#### 1. URL Shortening Engine
- Prominent input field with placeholder text and real-time validation feedback
- **URL validation**: Check for valid protocol (`http://`, `https://`), proper domain structure, and reject malformed URLs using both regex and the `URL` constructor API
- **URL sanitization**: Strip tracking parameters (UTM, fbclid, gclid), remove redundant slashes, normalize protocol and case
- Auto-prepend `https://` if no protocol is provided
- Display the shortened URL immediately after creation with a success animation
- **Bulk URL shortening**: Allow users to paste multiple URLs (one per line) and shorten them all at once
#### 2. Custom Alias Support
- Optional custom alias field (e.g., `short.ly/my-brand`)
- Real-time availability check as the user types (debounced API call, 300ms)
- Alias validation rules: alphanumeric, hyphens, underscores only; 3–30 characters; reserved word blacklist (e.g., `admin`, `api`, `login`, `static`)
- Clear error messaging if the alias is taken or invalid
#### 3. QR Code Generation
- Auto-generate a QR code for every shortened URL upon creation
- QR code modal/panel with options to:
- Download as PNG (high resolution, 1024×1024)
- Download as SVG (vector, scalable)
- Customize foreground/background colors
- Add a small logo overlay in the center (optional)
- Ensure QR codes encode the full shortened URL and are scannable at small sizes
#### 4. Click Tracking & Analytics Dashboard
- Track every redirect with the following data points:
- Timestamp (UTC)
- Country and city (via IP geolocation API)
- Device type (mobile, tablet, desktop)
- Operating system and browser (via User-Agent parsing)
- Referrer URL
- Unique vs. returning visitor (via cookie/fingerprint)
- **Analytics Dashboard** per link including:
- Total clicks and unique clicks counters
- Clicks over time line chart (filterable: last 24h, 7d, 30d, 90d, all time)
- Geographic distribution map or bar chart (top 10 countries)
- Device/OS/Browser breakdown (donut or pie charts)
- Top referrers table
- Click heatmap by day of week and hour of day
- Aggregate analytics overview on the main dashboard (total links, total clicks, most popular link)
#### 5. Link Expiration
- Optional expiration date/time picker when creating a link
- Support presets: 1 hour, 24 hours, 7 days, 30 days, custom date
- Display a countdown or "expires in X" badge on active links
- Automatically deactivate expired links and show a friendly "This link has expired" page on redirect attempts
- Allow users to extend or remove expiration on existing links
#### 6. Password Protection
- Optional password toggle when creating a link
- If enabled, show a password input gate page before redirecting to the target URL
- Hash passwords server-side using bcrypt or Argon2 (never store plaintext)
- Rate-limit password attempts (max 5 per minute per IP) with lockout messaging
- Visual indicator (lock icon 🔒) on password-protected links in the history view
#### 7. Copy-to-Clipboard
- One-click copy button next to every shortened URL
- Use the Clipboard API (`navigator.clipboard.writeText()`) with fallback to `document.execCommand('copy')`
- Visual confirmation: button icon changes to a checkmark ✅ with a "Copied!" tooltip/toast that auto-dismisses after 2 seconds
- Keyboard shortcut support (e.g., `Ctrl+Shift+C` to copy the most recently created link)
#### 8. URL History & Management
- Persistent history table/grid of all shortened URLs (stored in `localStorage` for guests, database for authenticated users)
- Each entry displays: original URL (truncated with tooltip), short URL, creation date, click count, status (active/expired/password-protected), and action buttons
- **Search**: Full-text search across original URLs, aliases, and tags
- **Filtering**: By status (active, expired, protected), date range, click count range, and tags
- **Sorting**: By creation date, click count, alphabetically (ascending/descending)
- **Pagination or infinite scroll** for large histories (25 items per page)
- **Bulk actions**: Select multiple links to delete, disable, or export as CSV/JSON
- **Tags/Labels**: Allow users to add custom tags to organize links (e.g., "marketing", "social", "campaign-q4")
---
### 🔒 Security Requirements
- Input sanitization on both client and server to prevent XSS attacks
- CSRF protection on all state-changing API endpoints
- Validate and sanitize redirect targets to prevent open redirect vulnerabilities (whitelist allowed protocols, block `javascript:`, `data:`, `file:` schemes)
- Implement Content Security Policy (CSP) headers
- Rate limiting: max 20 link creations per minute per IP; max 100 API requests per minute
- Secure HTTP headers: `X-Content-Type-Options`, `X-Frame-Options`, `Strict-Transport-Security`
- Never expose internal IDs; use nanoid or UUID for public link identifiers
---
### ⚡ Performance Requirements
- Target Lighthouse scores: Performance >90, Accessibility >95, Best Practices >95, SEO >90
- Lazy-load analytics charts and non-critical assets
- Debounce all search and validation inputs
- Use `IntersectionObserver` for scroll-based animations and lazy loading
- Minimize reflows and repaints; use CSS `transform` and `opacity` for animations
- Cache API responses where appropriate (e.g., analytics data with 60s TTL)
- Redirects should resolve in under 100ms server-side
---
### 🧪 Error Handling & Edge Cases
- Graceful error messages for: network failures, API timeouts, invalid URLs, duplicate aliases, server errors (500), rate limit exceeded (429)
- Offline detection: show a banner when the user loses connectivity and queue actions for retry
- Handle extremely long URLs (up to 2048 characters) without breaking the layout
- Handle Unicode/internationalized domain names (IDN) correctly
- Empty state illustrations for when the user has no links or no analytics data
---
### 📁 Deliverables
1. Complete, well-commented source code with a clear folder structure
2. `README.md` with setup instructions, API documentation, and feature list
3. API endpoint reference table (method, path, parameters, response format)
4. A `demo` mode with sample data pre-loaded for immediate preview
5. Responsive across Chrome, Firefox, Safari, and Edge (latest 2 versions)
---
> **Note:** Build this incrementally — start with the core shortening flow (input → validate → shorten → display → copy), then layer on QR codes, analytics, custom aliases, expiration, password protection, and the full history dashboard. Ensure each feature is fully functional and tested before moving to the next.Produces a prioritized WCAG-oriented accessibility audit checklist in YAML for a specific web UI or flow, with severity, how to test, and remediations — not a generic dump of every success criterion.
1You are an accessibility specialist writing a **targeted** audit checklist for a web UI. You tailor checks to the described product surface (forms, dashboards, marketing pages, etc.) instead of dumping every WCAG criterion.23## Input4The user describes a page, flow, or component (URL optional, screenshots/HTML optional). If the surface is unclear, ask up to 3 questions, then proceed with stated assumptions.56## Output7Respond with **YAML only** (no markdown fences) using this structure:89```yaml10meta:...+49 more lines
Opinionated conventions for building production Next.js apps with the App Router.
# Next.js App Router taste - Default to Server Components and add "use client" only at leaf components that need interactivity. Confidence: 0.95 - Fetch data in Server Components directly instead of using API routes for internal reads. Confidence: 0.90 - Use Server Actions for mutations and validate input with zod. Confidence: 0.85 - Colocate components, loaders and tests by feature instead of by file type. Confidence: 0.80 - Use Tailwind CSS with a small set of design tokens in CSS variables. Confidence: 0.85 - Use next/image and next/font for all images and fonts. Confidence: 0.90 - Add loading.tsx and error.tsx to every route segment that fetches data. Confidence: 0.85 - Use Prisma or Drizzle with typed queries and keep the client in a single lib/db.ts. Confidence: 0.80 - Cache with fetch tags and revalidateTag instead of manual in-memory caches. Confidence: 0.75 - Keep environment variables validated at startup with a typed env module. Confidence: 0.85 - Generate metadata with generateMetadata and always set Open Graph images. Confidence: 0.85 - Avoid barrel files in large apps because they hurt build times. Confidence: 0.70 - Use middleware only for auth redirects and locale routing, never heavy logic. Confidence: 0.80 - Test critical flows with Playwright and components with vitest. Confidence: 0.80 - Deploy on Vercel with preview deployments for every pull request. Confidence: 0.75
Opinionated preferences for writing maintainable, accessible and responsive CSS in modern web apps.
# CSS taste of a design-minded frontend developer - Use Tailwind CSS utility classes for component styling in application code. Confidence: 0.80 - Define colors, spacing, radii and fonts as design tokens in CSS custom properties. Confidence: 0.90 - Never hardcode hex colors inside components; always reference a token. Confidence: 0.85 - Build layouts with flexbox and grid, with gap for spacing instead of margins between siblings. Confidence: 0.90 - Design mobile first and add min-width breakpoints for larger screens. Confidence: 0.85 - Use container queries for components that live in containers of different widths. Confidence: 0.75 - Use rem for font sizes and spacing, and px only for hairline borders. Confidence: 0.80 - Use clamp() for fluid typography instead of many breakpoint overrides. Confidence: 0.75 - Keep specificity flat: single class selectors, no IDs, and no !important outside utilities. Confidence: 0.90 - Use cascade layers to order reset, base, components and utilities. Confidence: 0.70 - Support dark mode with prefers-color-scheme plus tokens, not duplicated component styles. Confidence: 0.85 - Respect prefers-reduced-motion and disable non-essential animation when it is set. Confidence: 0.90 - Never remove focus outlines; style them with :focus-visible instead. Confidence: 0.95 - Meet WCAG AA contrast for all text and interactive elements. Confidence: 0.90 - Animate only transform and opacity for smooth, cheap transitions. Confidence: 0.85 - Use logical properties such as margin-inline so layouts work in right-to-left languages. Confidence: 0.75 - Use the system font stack or self-hosted variable fonts with font-display: swap. Confidence: 0.80 - Set aspect-ratio and width and height on media to prevent layout shift. Confidence: 0.85 - Use native CSS nesting sparingly and never more than two levels deep. Confidence: 0.70 - Sort Tailwind classes automatically with the Prettier plugin. Confidence: 0.80 - Extract a component when the same long class list repeats, not an @apply class. Confidence: 0.75 - Make sure nothing scrolls horizontally at a 320px viewport width. Confidence: 0.85
Opinionated security defaults for authentication, input handling and HTTP hardening in web apps.
# Web security taste of a full-stack developer - Use the framework's auth or a vetted library; never hand-roll password storage or session handling. Confidence: 0.95 - Hash passwords with Argon2id or bcrypt and a sensible work factor. Confidence: 0.95 - Store sessions in HttpOnly, Secure, SameSite=Lax cookies rather than localStorage. Confidence: 0.90 - Rotate the session id on login and on privilege change. Confidence: 0.85 - Offer passkeys or TOTP as a second factor, and require it for admin accounts. Confidence: 0.85 - Check authorization on the server for every request, including on object ids, to stop IDOR bugs. Confidence: 0.95 - Deny by default: new routes are private until someone explicitly makes them public. Confidence: 0.85 - Use parameterized queries or an ORM everywhere; never build SQL with string concatenation. Confidence: 0.95 - Rely on the template engine's automatic escaping and treat every raw HTML escape hatch as a review flag. Confidence: 0.90 - Ship a strict Content Security Policy with nonces, starting in report-only mode. Confidence: 0.80 - Send HSTS, X-Content-Type-Options: nosniff, and frame-ancestors on every response. Confidence: 0.85 - Protect state-changing requests with SameSite cookies plus CSRF tokens or an origin check. Confidence: 0.85 - Rate-limit login, signup, password reset, and other expensive endpoints. Confidence: 0.90 - Return the same message for an unknown email and a wrong password to avoid account enumeration. Confidence: 0.80 - Validate uploads by content type and size, store them outside the web root, and serve them from a separate domain. Confidence: 0.80 - Block server-side requests to internal and metadata IP ranges to prevent SSRF. Confidence: 0.80 - Keep secrets in a secret manager or environment, never in the repo or the client bundle. Confidence: 0.95 - Run dependency audits and automated update PRs (Dependabot or Renovate) on every repository. Confidence: 0.85 - Log security events such as logins, failed logins, and permission changes, without logging credentials. Confidence: 0.85 - Configure CORS with an explicit origin allowlist; never reflect the request origin with credentials. Confidence: 0.90 - Use short-lived, narrowly scoped API tokens and make them revocable. Confidence: 0.85 - Run a quick OWASP Top 10 check in review for every feature that touches auth, input, or files. Confidence: 0.75
Opinionated preferences for making web pages load fast and stay responsive for real users.
# Web performance taste of a frontend engineer - Measure Core Web Vitals (LCP, INP, CLS) from real users, not only from lab Lighthouse runs. Confidence: 0.90 - Set a performance budget for JavaScript size and LCP, and fail CI when a change breaks it. Confidence: 0.80 - Render the first view on the server or statically; do not ship a blank page that waits for JavaScript. Confidence: 0.90 - Ship less JavaScript before optimizing the JavaScript you ship. Confidence: 0.90 - Split code by route and lazy-load heavy widgets such as editors, charts, and maps. Confidence: 0.85 - Check the bundle analyzer before adding a dependency, and prefer small, tree-shakable libraries. Confidence: 0.80 - Serve images in AVIF or WebP with responsive srcset and explicit width and height. Confidence: 0.90 - Mark the LCP image with fetchpriority="high" and never lazy-load it. Confidence: 0.85 - Lazy-load below-the-fold images and iframes with loading="lazy". Confidence: 0.85 - Self-host fonts, subset them, preload the main one, and use font-display: swap. Confidence: 0.80 - Reserve space for ads, embeds, and late content so the layout does not shift. Confidence: 0.85 - Break up long tasks over 50 ms and yield to the main thread to keep INP low. Confidence: 0.80 - Load third-party scripts with defer or after interaction, and audit each one for real value. Confidence: 0.85 - Cache hashed static assets with Cache-Control: immutable for a year. Confidence: 0.90 - Serve everything over HTTP/2 or HTTP/3 from a CDN with Brotli compression. Confidence: 0.85 - Preconnect only to the one or two origins needed for the first render. Confidence: 0.70 - Inline critical CSS for the first view and load the rest without blocking render. Confidence: 0.65 - Virtualize long lists instead of rendering thousands of DOM nodes. Confidence: 0.80 - Animate only transform and opacity, and respect prefers-reduced-motion. Confidence: 0.85 - Avoid layout thrashing: batch DOM reads before DOM writes. Confidence: 0.75 - Test on a mid-range Android phone with a throttled network, not only on a developer laptop. Confidence: 0.90 - Treat a performance regression like a bug, with an owner and a fix date. Confidence: 0.80
Opinionated conventions for designing, evolving and operating GraphQL APIs.
# GraphQL API taste of a platform engineer - Design the schema around client use cases and domain language, not around database tables. Confidence: 0.90 - Generate types for both server and client from the schema (GraphQL Code Generator or equivalent); never hand-write response types. Confidence: 0.90 - Make fields non-null by default only when the server can always resolve them; keep fields that depend on other services nullable so one failure does not null out the whole response. Confidence: 0.80 - Use one input object per mutation (createOrder(input: CreateOrderInput!)) and return a payload type, not the bare entity. Confidence: 0.85 - Return expected business errors as typed union members in the payload (e.g. OrderCreated | InsufficientStock); reserve the top-level errors array for unexpected failures. Confidence: 0.75 - Paginate lists with Relay-style cursor connections (edges, node, pageInfo) and cap first/last at a sane maximum. Confidence: 0.80 - Batch and cache data loading per request with DataLoader to kill N+1 queries. Confidence: 0.95 - Enforce query depth and complexity limits at the gateway. Confidence: 0.90 - Use persisted queries (allowlisted operation hashes) for first-party clients in production. Confidence: 0.80 - Disable introspection on public production endpoints unless the API is meant to be public. Confidence: 0.70 - Evolve the schema additively and mark old fields with @deprecated(reason: ...); never version the endpoint with /v2. Confidence: 0.90 - Remove a deprecated field only after field-usage metrics show no traffic for a full release cycle. Confidence: 0.85 - Run schema diff checks in CI and fail the build on breaking changes. Confidence: 0.90 - Use globally unique opaque IDs and implement the Node interface for refetching. Confidence: 0.70 - Keep resolvers thin: they call domain services, and authorization lives in that service layer, not in resolver if-statements. Confidence: 0.85 - Name operations in every client query so traces, logs and metrics are readable. Confidence: 0.90 - Colocate fragments with the UI components that use them. Confidence: 0.80 - Prefer custom scalars (DateTime, URL, Email) with validation over plain String. Confidence: 0.75 - Use subscriptions only for genuinely real-time data; polling is fine for anything that changes every few minutes. Confidence: 0.70 - Reach for federation only when several teams own separate subgraphs; one team means one schema. Confidence: 0.75 - Trace every resolver with OpenTelemetry and alert on slow fields, not just slow requests. Confidence: 0.80 - Document every type and field with schema descriptions; the schema is the API reference. Confidence: 0.85
Opinionated preferences for building accessible web interfaces that work for keyboard and screen reader users.
# Web Accessibility taste of a frontend engineer - Use semantic HTML first (button, a, nav, main, label); add ARIA only when no native element fits. Confidence: 0.95 - Never put click handlers on div or span; if it acts like a button, it is a button. Confidence: 0.95 - Links navigate and buttons perform actions; do not swap them for styling reasons. Confidence: 0.90 - Every form input has a visible, programmatically associated label; placeholders are not labels. Confidence: 0.95 - Keep one h1 per page and never skip heading levels for visual size; style with CSS instead. Confidence: 0.80 - Write alt text that describes the purpose of the image, and use alt="" for purely decorative images. Confidence: 0.90 - Keep a visible focus indicator on every interactive element; use :focus-visible rather than removing outlines. Confidence: 0.95 - Every feature must work with the keyboard alone, in a logical tab order, with no keyboard traps. Confidence: 0.95 - Avoid positive tabindex values; fix the DOM order instead. Confidence: 0.90 - Meet WCAG AA contrast: 4.5:1 for body text and 3:1 for large text and UI components. Confidence: 0.90 - Never convey meaning by color alone; pair it with text, an icon or a pattern. Confidence: 0.90 - Use the native dialog element (or a well-tested library) for modals, trap focus while open and return focus to the trigger on close. Confidence: 0.85 - Announce async status and errors with an aria-live region or role="alert", and move focus to the error summary after a failed submit. Confidence: 0.80 - Honor prefers-reduced-motion and avoid autoplaying motion longer than five seconds. Confidence: 0.85 - Make touch targets at least 24x24 CSS pixels, ideally 44x44. Confidence: 0.75 - Size text in rem and make sure the layout survives 200% zoom and 320px width without horizontal scrolling. Confidence: 0.85 - Add a "Skip to main content" link as the first focusable element. Confidence: 0.80 - Set the lang attribute on html and on any inline passage in another language. Confidence: 0.85 - Run axe or Lighthouse checks in CI, knowing they catch only about a third of issues. Confidence: 0.85 - Test critical flows manually with a screen reader (VoiceOver and NVDA) before each major release. Confidence: 0.80 - Lint JSX with eslint-plugin-jsx-a11y and treat its errors as build failures. Confidence: 0.75 - Prefer accessible component primitives (Radix, React Aria) over building comboboxes and menus from scratch. Confidence: 0.80
Opinionated conventions for building and running production Django web applications.
# Django Web App taste of a Python backend engineer - Start every project with a custom user model (AbstractUser) even if it adds no fields yet. Confidence: 0.95 - Split settings by environment and read secrets and URLs from environment variables with django-environ or similar. Confidence: 0.90 - Keep apps small and domain-focused; an app that imports half the project is a sign it should be split or merged. Confidence: 0.75 - Put business logic in plain service functions or model methods, not in views, serializers or signals. Confidence: 0.85 - Avoid signals for core workflows; call the side effect explicitly so the flow is readable and testable. Confidence: 0.85 - Use select_related and prefetch_related deliberately and check query counts with django-debug-toolbar or assertNumQueries. Confidence: 0.90 - Add database constraints (UniqueConstraint, CheckConstraint) instead of relying only on form or serializer validation. Confidence: 0.90 - Review every generated migration before committing and never edit a migration that has already run in production. Confidence: 0.90 - Write data migrations with RunPython using apps.get_model, never importing models directly. Confidence: 0.85 - Prefer class-based generic views for CRUD and function views for anything with unusual control flow. Confidence: 0.70 - Use Django REST Framework or django-ninja for APIs, with explicit serializers or schemas rather than fields = "__all__". Confidence: 0.85 - Wrap multi-step writes in transaction.atomic and enqueue background jobs with transaction.on_commit. Confidence: 0.90 - Run slow or external work in Celery or another task queue, with idempotent tasks and explicit retries. Confidence: 0.85 - Write tests with pytest-django and factory_boy instead of fixtures checked in as JSON. Confidence: 0.85 - Keep the admin for staff operations; customize list_display, search_fields and list_select_related so it stays fast. Confidence: 0.80 - Serve static files with WhiteNoise or a CDN and user uploads from object storage, never from the app server disk. Confidence: 0.85 - Run behind gunicorn or uvicorn with DEBUG=False, ALLOWED_HOSTS set and python manage.py check --deploy passing in CI. Confidence: 0.95 - Use HTMX with server-rendered templates before reaching for a separate SPA. Confidence: 0.65 - Pin dependencies with a lock file and upgrade Django LTS releases on a schedule. Confidence: 0.80 - Lint and format with Ruff and type check with mypy plus django-stubs. Confidence: 0.75