# ASAT Website — Master End-to-End Build Prompt

## 1. Mission

You are the lead autonomous software engineering agent responsible for designing, implementing, testing, documenting, securing, optimizing, and preparing for production deployment the complete ASAT website for **Arc. Shehu Ahmed Tukur (ASAT)**.

Build the system end-to-end. Do not stop at wireframes, mockups, scaffolds, pseudo-code, placeholder routes, or incomplete CMS screens. Continue until the public website, CMS, database, APIs, authentication, role-based permissions, media management, SEO, animations, automated tests, CI/CD, documentation, and production configuration are complete and coherent.

The project must use:

- **Backend:** Laravel 12+ / PHP 8.3+
- **Frontend:** React 19+ with TypeScript
- **Bridge / public rendering:** Inertia.js with server-side rendering for public content pages
- **Admin CMS:** React TypeScript application, optimized for client-side interactivity
- **Styling:** Tailwind CSS 4+ with reusable design tokens and component primitives
- **Animation:** GSAP 3+, ScrollTrigger, and native CSS/Web Animations where lighter-weight animation is preferable
- **Database:** MySQL 8+
- **Cache / queue / sessions:** Redis
- **Media:** local disk in development; S3-compatible object storage + CDN in production
- **Testing:** Pest/PHPUnit + React Testing Library/Vitest where appropriate + Playwright E2E
- **CI/CD:** GitHub Actions

Use the supplied ASAT requirements, philosophy/vision material, approved content, project information, and brand assets as authoritative source content. Do not invent factual claims about ASAT. Where source documents conflict, retain the documented source-of-truth decisions and verification flags instead of silently choosing facts.

---

## 2. Product Positioning

The website must position ASAT first as:

1. Architect
2. Development consultant
3. Practice leader
4. Institutional contributor
5. Civic/public leader

Civic and political leadership must be presented as an extension of professional discipline and service, not as the primary identity of the website.

Primary thematic statement:

> **Functionality. Character. Integrity. Service.**

Secondary thematic statement:

> **Architecture with Purpose. Design for Humanity.**

Architectural philosophy:

> **Purpose defines function. Function informs form. Architecture serves humanity.**

The dedicated philosophy material establishes **form follows function** as the governing architectural principle.

---

## 3. Non-Negotiable Delivery Rules

### 3.1 Complete implementation

Do not merely describe how a feature would work. Implement it.

For every feature:

- create database migrations if persistence is required;
- create Laravel models, policies, requests, services and controllers;
- create typed frontend interfaces;
- create responsive UI;
- create CMS controls where content must be editable;
- create validation and authorization;
- create tests;
- wire navigation and routes;
- handle empty/loading/error states;
- document important operational behavior.

Never leave TODO placeholders for core requirements.

### 3.2 CMS-first content architecture

**No editorial frontend content may be hardcoded in React components.**

React components may contain:

- component labels needed for behavior;
- accessibility strings;
- developer-facing fallback messages;
- non-editorial UI control text.

The following must be CMS-managed:

- page titles and body copy;
- hero copy;
- CTAs;
- navigation;
- footer sections;
- projects;
- project metrics;
- project galleries;
- biography content;
- vision / mission / philosophy;
- values;
- timeline records;
- awards/fellowships;
- board/service roles;
- development perspectives;
- posts/articles;
- speeches/publications/media features;
- testimonials or quotations if introduced;
- contact information;
- social links;
- SEO metadata;
- OpenGraph images;
- configurable announcement bars;
- newsletter settings;
- animation presets assigned to sections where appropriate.

Target success criterion: **100% of publishable frontend content editable from the CMS.**

### 3.3 Preserve factual integrity

Keep a `content_verification_status` mechanism for uncertain facts.

At minimum, preserve verification flags for:

- practice-leadership start year conflict (1997 vs 2001);
- Phoenix University chronology;
- professional suffix ordering;
- academic/graduation details not supplied;
- missing publication/social/media information.

Unverified content must be clearly labeled in the CMS and should not be published until approved unless an administrator with sufficient permission explicitly overrides the warning.

---

## 4. Information Architecture

Implement at least the following public route structure. Slugs must be CMS-configurable where feasible while preserving canonical route resolution.

### Core public pages

- `/` — Homepage
- `/the-architect` — Professional biography and journey
- `/selected-works` — Project portfolio index
- `/selected-works/{slug}` — Project case study
- `/philosophy` — Architectural philosophy and Canonic design method
- `/perspectives` — Architecture and development perspectives
- `/professional-record` — fellowships, service, boards, teaching, honours
- `/insights` — articles, speeches, publications and media
- `/insights/{slug}` — individual article/publication/media entry
- `/contact` — professional, collaboration, speaking and media inquiry channels
- dynamic CMS pages `/p/{slug}` or clean resolved slugs using a page router

### Optional / configurable

- `/timeline`
- `/media`
- `/press`
- `/newsletter`
- privacy, cookies and terms pages

Generate XML sitemap(s), canonical URLs, robots directives, breadcrumb structured data, Organization/Person/Article/CreativeWork schema where appropriate.

---

## 5. Homepage Experience

The homepage should feel like a premium architecture monograph translated into an interactive digital experience rather than a generic corporate template.

### 5.1 Hero

Create a visually commanding full-viewport or near-full-viewport architectural hero.

Content includes CMS-driven:

- eyebrow;
- H1: “Functionality, Character, Integrity and Service” or current approved CMS variation;
- subtitle describing ASAT's architectural/development record;
- primary CTA to selected works;
- secondary CTA to professional journey;
- hero image/video/media selection;
- optional architectural linework overlay.

Animation direction:

- restrained entrance timeline;
- mask/clip-path headline reveal;
- subtle image scale from ~1.04 to 1;
- architectural rule lines drawing into place;
- CTA fade/translate;
- optional cursor-responsive image movement on capable desktop devices only.

Do not allow animation to delay LCP. The LCP media must render immediately and animation must enhance, not gate, meaningful content.

### 5.2 Authority metrics

CMS-driven metric strip:

- project experience across 27 states + FCT;
- practice leadership start year — verification aware;
- over three decades of practice;
- fellowships/honours.

Animate numeric/stat reveal only after content is visible. Do not rely on animation for comprehension.

### 5.3 Selected works

Use editorial project cards with:

- large responsive image;
- project name;
- category;
- location;
- year/status;
- concise challenge/impact statement;
- hover and keyboard focus behavior;
- optional horizontal or pinned storytelling on desktop with ordinary stacked rendering on mobile/reduced-motion mode.

Seed the four source projects:

1. Lafia Airport Project
2. Abaji Trailer Park and Container Terminal
3. NASENI Renewable Energy Industrial Park (NREIP)
4. Phoenix University

### 5.4 Philosophy

Create an immersive section based on:

**Understand → Analyse → Define Function → Develop Form → Integrate → Refine → Deliver**

Possible desktop experience:

- pinned narrative section;
- process nodes progressing along architectural linework;
- copy transitions with ScrollTrigger;
- schematic plan/grid background.

Mobile:

- vertical accessible stepper;
- no forced scroll hijacking;
- simplified transitions.

### 5.5 Journey

Create an architectural/professional timeline driven entirely from CMS records.

### 5.6 Development perspectives

Present the three supplied perspectives with distinctive editorial panels:

- Planned Communities, Better Living
- Resilient Infrastructure, Sustainable Communities
- Productive Places, Sustainable Growth

### 5.7 Professional record / engagement

Show fellowships, professional service, board roles, teaching, public engagement and calls to action.

### 5.8 Footer

CMS-manage all footer groups, legal links, contact data, social channels and newsletter visibility.

---

## 6. Visual Design System

### 6.1 Brand direction

Use the letterhead-derived working palette until exact official values are approved:

- Deep Navy: `#112945`
- Architectural Gold: `#AF872B`
- Brighter Gold Accent: `#C09338`
- Warm Cream: `#F6F2E8`
- Pale Slate: `#E5E8EA`
- Ink / Near-black: suitable high-contrast neutral
- White: `#FFFFFF`

Implement these as CSS variables/Tailwind tokens rather than scattered literals.

### 6.2 Visual language

Keywords:

- architectural;
- monumental;
- editorial;
- calm;
- precise;
- authoritative;
- contemporary;
- premium;
- civic without campaign-template aesthetics;
- high whitespace;
- measured use of brass/gold accents;
- fine rules and structural grids;
- strong typographic hierarchy.

Use architectural references abstractly:

- blueprint grids;
- elevation lines;
- site-plan curves;
- registration marks;
- scale ticks;
- construction geometry;
- sectional cuts;
- contour-inspired linework.

Do not overwhelm pages with ornamental graphics.

### 6.3 Typography

Use a refined serif for display headings paired with a high-legibility sans-serif for body copy.

Prefer self-hosted or privacy-respecting fonts with appropriate licensing. Use variable fonts where beneficial. Subset production fonts and use `font-display: swap` or `optional` according to measured UX.

Build a responsive type scale with `clamp()`.

### 6.4 Layout

Create a 12-column desktop grid, fluid tablet layout, and mobile-first stacked system.

Suggested breakpoints:

- mobile: `< 768px`
- tablet: `768–1199px`
- desktop: `>= 1200px`
- optional wide display enhancement `>= 1536px`

Use logical spacing tokens and container sizes. Avoid arbitrary one-off spacing unless the design requires it.

---

## 7. Motion & Interaction System

### 7.1 GSAP architecture

Create a reusable motion layer rather than embedding raw GSAP logic throughout page components.

Recommended abstractions:

- `useGsapContext`
- `useReveal`
- `useSplitTextReveal` using safe text segmentation rather than inaccessible DOM duplication
- `useParallax`
- `useScrollProgress`
- `usePinnedStory`
- `useMagneticButton`
- `MotionSection`
- `ReducedMotionProvider`

Register ScrollTrigger once.

Always scope and clean GSAP contexts on unmount/navigation so Inertia transitions never create duplicate triggers or memory leaks.

Refresh ScrollTrigger after relevant image/font/layout changes in a controlled manner.

### 7.2 Allowed effects

Use selectively:

- opacity/translate reveals;
- clip-path/mask reveals;
- architectural line draw animations;
- slow parallax;
- pinned project storytelling;
- image scale/crop transitions;
- horizontal desktop sequences;
- scroll progress indicators;
- staggered grid/card reveals;
- subtle magnetic buttons on pointer devices;
- tasteful hover image displacement or scale;
- number counters;
- page transition overlays if they remain fast and accessible.

### 7.3 Prohibited motion patterns

Do not:

- hijack scrolling;
- make text unreadable until JavaScript runs;
- animate every element;
- use autoplay audio;
- create aggressive cursor followers;
- use long intro loaders;
- run perpetual heavy animations;
- use effects that create layout shift;
- block navigation while transitions finish.

### 7.4 Reduced motion

Honor `prefers-reduced-motion: reduce` globally.

Reduced-motion mode must:

- disable parallax;
- disable pinned/horizontal artificial sequences;
- shorten or eliminate transforms;
- render content in final visible state;
- maintain the complete information hierarchy.

### 7.5 Mobile motion

Do not simply shrink desktop effects.

On mobile:

- simplify timelines;
- avoid large pinned sections;
- avoid costly scroll listeners;
- remove magnetic/cursor effects;
- retain subtle opacity/translate reveals only where performance is strong.

---

## 8. Rendering Architecture: SSR + CSR

### 8.1 Public website

Use Laravel + Inertia SSR for all public content-rich routes.

SSR must deliver:

- meaningful body content;
- title/meta tags;
- canonical URL;
- OpenGraph metadata;
- structured data;
- navigation/footer content;
- primary project/page content.

No public page may render as an empty shell waiting for client JavaScript.

### 8.2 Hydration safety

Avoid hydration mismatches by:

- not referencing `window`, `document`, current viewport or random values during server render;
- isolating browser-only code in effects/hooks;
- keeping date formatting deterministic;
- ensuring CMS payloads serialize consistently;
- preventing GSAP from mutating markup before React hydration completes.

Add automated E2E checks that fail on hydration warnings/errors.

### 8.3 CMS/admin

The CMS can use CSR because SEO is irrelevant and highly interactive editing benefits from client navigation.

Set CMS routes to `noindex,nofollow`.

---

## 9. CMS Requirements

Build a complete editorial CMS. It must be usable by non-technical administrators.

### 9.1 Dashboard

Dashboard cards:

- drafts awaiting publication;
- scheduled content;
- recently edited pages;
- recent media;
- inquiries;
- content verification warnings;
- broken link/SEO alerts;
- user activity;
- storage usage;
- quick-create actions.

### 9.2 Page builder

Implement structured sections, not unrestricted raw HTML as the primary editing approach.

Support section types such as:

- hero;
- rich text;
- image/text split;
- statistics;
- project grid;
- featured project;
- gallery;
- timeline;
- quote;
- values;
- philosophy/process;
- perspective cards;
- logo/affiliation list;
- CTA;
- contact panel;
- article feed;
- video/embed;
- spacer/divider only where controlled.

Each section must support:

- enabled/disabled;
- drag sorting;
- content fields;
- media selection;
- theme/background variant;
- width/layout variant;
- anchor ID;
- animation preset;
- optional animation intensity/speed constrained to safe predefined values;
- visibility scheduling if useful.

Avoid giving editors arbitrary JavaScript or arbitrary GSAP configuration.

### 9.3 Visual preview

Provide:

- draft preview;
- desktop/tablet/mobile preview modes;
- secure signed preview URLs;
- preview without publishing;
- preview of scheduled content.

### 9.4 Projects

Project CMS fields should include:

- title;
- slug;
- location;
- client;
- category;
- date/year range;
- status;
- area/scale;
- hero media;
- gallery;
- challenge/context;
- architectural strategy;
- design outcome/impact;
- services/scope;
- project metrics;
- collaborators where approved;
- featured status;
- sort order;
- SEO;
- publication status;
- verification status;
- related projects.

### 9.5 Posts / insights

Support types:

- article;
- speech;
- publication;
- media feature;
- interview;
- press/update.

Include author, date, host/publication, excerpt, body, media, external source link, SEO and taxonomy.

### 9.6 Media library

Implement:

- image upload;
- video metadata/embed support;
- PDF/document upload;
- folders/collections/tags;
- search and filtering;
- alt text;
- title/caption/credit;
- focal point;
- responsive derivative generation;
- WebP/AVIF conversion;
- usage references (“used on X pages”);
- duplicate detection where feasible;
- safe delete protection when media is in use;
- image dimensions/file size visibility.

### 9.7 Navigation

Provide nested drag-and-drop menu management for:

- primary navigation;
- footer menus;
- optional utility navigation.

Support internal page selection and external URLs.

### 9.8 Global settings

CMS-editable settings:

- site identity;
- default SEO;
- contact information;
- social channels;
- office address;
- footer text;
- logo variants;
- favicon;
- theme tokens if enabled;
- analytics IDs;
- cookie/consent settings;
- newsletter configuration;
- default share image;
- maintenance mode content.

### 9.9 Workflow

Statuses:

- draft;
- in review;
- approved;
- scheduled;
- published;
- archived.

Support:

- autosave drafts;
- revision history;
- restore previous revision;
- compare revision data;
- schedule publication/unpublication;
- publication audit trail;
- optional approval requirement by role.

### 9.10 Inquiries

Create configurable inquiry categories:

- architectural/professional;
- collaborations;
- speaking;
- media;
- general.

CMS users can:

- view submissions;
- search/filter;
- assign owner;
- set status;
- add internal notes;
- export CSV where permitted;
- mark spam;
- archive;
- receive notifications.

Protect public forms with rate limiting, honeypot and optional privacy-conscious CAPTCHA/Turnstile integration.

---

## 10. Authentication & RBAC

Use secure session authentication for CMS users.

Suggested roles:

- **Super Admin** — full system access
- **Administrator** — site operations except sensitive infrastructure actions
- **Editor** — edit and publish approved content areas
- **Author** — create/edit own assigned content, submit for review
- **Media Manager** — media assets only plus relevant read access
- **Reviewer** — review/approve without system administration

Define granular permissions rather than relying solely on roles.

Examples:

- `pages.view`
- `pages.create`
- `pages.edit`
- `pages.publish`
- `pages.delete`
- `projects.*`
- `posts.*`
- `media.*`
- `navigation.manage`
- `settings.manage`
- `users.manage`
- `roles.manage`
- `inquiries.view`
- `inquiries.export`
- `revisions.restore`
- `verification.override`

Enforce permission checks on the backend regardless of frontend visibility.

Support password reset, optional email verification, secure session invalidation and optional TOTP 2FA for privileged users.

---

## 11. Data Model

At minimum implement normalized models/tables for:

- users
- roles/permissions
- pages
- page_sections
- projects
- project_media / relationships
- project_metrics
- posts
- categories/tags
- media_assets
- navigation_menus
- navigation_items
- site_settings
- social_links
- professional_records
- timeline_entries
- perspectives
- inquiries
- inquiry_notes
- content_revisions
- redirects
- seo_metadata or morphable SEO fields
- audit/activity logs
- scheduled publication jobs where needed.

Use foreign keys, indexes, soft deletes where useful, unique constraints and appropriate JSON fields only where structured relational tables would not be better.

---

## 12. API and Backend Engineering Standards

- Thin controllers.
- Form Request classes for validation.
- Policies/permissions for authorization.
- Service/action classes for substantial business workflows.
- API Resources/DTOs for stable frontend payloads.
- Transactions for multi-record editorial operations.
- Domain events/listeners for publishing, cache invalidation, search indexing, notifications and media processing.
- Queue expensive media operations.
- Avoid N+1 queries.
- Paginate large CMS listings.
- Cache public content intelligently and invalidate on publish.
- Add redirect handling for changed slugs.
- Add health/readiness endpoints suitable for deployment monitoring.

---

## 13. SEO

Every public page must support CMS-editable:

- title;
- meta description;
- canonical URL override;
- robots policy;
- OpenGraph title/description/image;
- Twitter/X card metadata;
- schema configuration where appropriate.

Implement:

- XML sitemap;
- sitemap index if content volume grows;
- robots.txt;
- canonical tags;
- breadcrumb schema;
- Person schema for ASAT;
- Article schema for insights;
- image alt text;
- semantic heading hierarchy;
- redirect manager;
- 404 page;
- social sharing metadata.

---

## 14. Accessibility

Target **WCAG 2.2 AA**.

Requirements:

- semantic landmarks;
- skip-to-content;
- keyboard navigation;
- visible focus states;
- minimum touch target sizes;
- proper form labels/errors;
- alt text management;
- correct color contrast;
- reduced-motion support;
- no keyboard traps;
- accessible modals/dialogs;
- meaningful link text;
- heading hierarchy;
- screen-reader announcements for dynamic CMS controls;
- carousel/slider alternatives where used.

Animation must never be required to understand content.

---

## 15. Performance / Core Web Vitals

Performance objectives:

- representative 4G first meaningful load: target `< 2 seconds` where infrastructure and media allow;
- LCP `<= 2.5s`, target `< 2.0s`;
- INP `<= 200ms`;
- CLS `<= 0.1`.

Implement:

- route-level code splitting;
- dynamic import for GSAP-heavy components where practical;
- tree-shake GSAP modules;
- responsive image `srcset/sizes`;
- AVIF/WebP;
- explicit media dimensions/aspect-ratio;
- CDN;
- font subsetting;
- preload only actual critical assets;
- lazy-load below-fold media;
- deferred third-party scripts;
- HTTP caching;
- Redis content caching;
- Brotli/gzip;
- HTTP/2 or HTTP/3 at edge;
- immutable fingerprinted assets;
- database indexes;
- queue image processing;
- avoid oversized JS bundles.

Run Lighthouse or equivalent budgets in CI when practical.

---

## 16. Security

Implement defense in depth.

### Laravel/backend

- CSRF protection;
- XSS-safe rendering;
- sanitized rich content;
- prepared ORM queries;
- rate limiting;
- session fixation protection;
- secure cookie settings;
- password hashing using Laravel defaults;
- authorization policies;
- signed preview URLs;
- upload MIME detection;
- randomized filenames;
- file-size/type restrictions;
- prevent executable uploads;
- optional malware scanning hook;
- mass-assignment protection;
- secrets only in environment/secret manager;
- audit logging;
- sensitive logs redaction.

### Headers/infrastructure

Configure:

- CSP;
- HSTS in production;
- X-Content-Type-Options;
- Referrer-Policy;
- Permissions-Policy;
- frame protections via CSP `frame-ancestors`;
- TLS 1.2+;
- sensible CORS;
- firewall/minimal exposed ports.

Do not loosen CSP globally merely to make animations or third-party scripts easier.

---

## 17. Browser & Device Compatibility

Validate current stable versions of:

- Chrome
- Firefox
- Safari
- Edge

Test desktop, tablet and representative mobile viewport sizes.

Use progressive enhancement. Premium effects may simplify on older/less-capable devices, but content and navigation must remain fully functional.

---

## 18. Testing Requirements

### Backend

Create tests for:

- content models;
- publication workflow;
- RBAC/policies;
- page/project CRUD;
- validation;
- revision restore;
- scheduled publishing;
- redirects;
- inquiry submission/rate limiting;
- caching invalidation;
- media metadata;
- sitemap/SEO output;
- unauthenticated CMS protection.

### Frontend component tests

Test critical reusable controls and CMS editors.

### E2E

Playwright must cover:

- homepage renders without hydration errors;
- primary navigation;
- selected works listing;
- case-study route;
- responsive mobile navigation;
- contact form;
- CMS login;
- create/edit/preview/publish page;
- project CRUD;
- media upload/select;
- RBAC restrictions;
- revision restore;
- mobile no-horizontal-overflow;
- reduced-motion path;
- cross-browser public flows.

The CI build must fail on browser console hydration errors for core SSR pages.

---

## 19. CI/CD

Create GitHub Actions stages:

1. dependency install/cache;
2. PHP lint/static analysis;
3. backend tests;
4. frontend lint/typecheck;
5. frontend/unit tests;
6. production build;
7. SSR build validation;
8. Playwright E2E where environment permits;
9. security/dependency audit;
10. deploy on approved branch/tag;
11. run migrations with safe strategy;
12. restart queue and SSR processes;
13. health check;
14. rollback or stop promotion on health failure.

Never commit `.env`, secrets, API tokens or production private keys.

---

## 20. Production Deployment Topology

Recommended:

- Nginx reverse proxy
- PHP-FPM
- Laravel app
- Inertia SSR Node service managed by Supervisor/systemd
- MySQL 8
- Redis
- queue worker(s)
- scheduler
- S3-compatible storage
- CDN
- SSL/TLS
- automated backups
- centralized/error monitoring
- uptime monitoring

Provide deployment commands/runbook and environment-variable documentation.

---

## 21. Required CMS UX Quality

The CMS must look and behave like a polished modern product, not a default CRUD dashboard.

Use:

- command/search palette;
- collapsible navigation;
- breadcrumb trail;
- contextual page actions;
- keyboard-friendly editing;
- clean tables/cards;
- bulk actions;
- filters with URL persistence;
- optimistic UI only where safe;
- toast notifications;
- clear destructive action confirmations;
- autosave state indicators;
- unsaved-change protection;
- skeleton states;
- robust error states;
- responsive admin UX.

Animation inside CMS should be subtle and functional. GSAP is primarily for the public experience; use lighter transitions for routine CMS interactions unless GSAP materially improves an interaction.

---

## 22. Source-Specific Content to Seed

Seed content from the approved ASAT project sources, including:

- ASAT biography;
- vision;
- mission;
- core values;
- philosophy;
- Canonic design method;
- authority metrics;
- four selected projects;
- three development perspectives;
- professional service/roles;
- fellowships/honours;
- engagement categories;
- letterhead-derived contact information where approved.

Do not fabricate missing images, dates, publications, social URLs or achievements. Use CMS verification state/placeholders for missing content.

---

## 23. Definition of Done

The project is complete only when all of the following are true:

- all public routes work;
- all public editorial content is CMS-managed;
- public content pages SSR correctly;
- no React hydration warnings appear;
- CMS CRUD/workflows are complete;
- RBAC is enforced server-side;
- media library works;
- preview/publish/revisions work;
- navigation and global settings are CMS-managed;
- GSAP animation system is implemented responsibly;
- reduced-motion mode is complete;
- mobile layouts are polished;
- Chrome/Firefox/Safari/Edge core flows pass;
- automated tests pass;
- production build passes;
- CI/CD is configured;
- production deployment runbook exists;
- security headers/configuration are documented and implemented;
- SEO metadata/sitemap/schema are implemented;
- Lighthouse/Core Web Vitals targets are pursued and regressions documented;
- no core feature is left as pseudo-code/TODO;
- README documents setup, development, testing, deployment and CMS bootstrap.

---

## 24. Autonomous Execution Protocol

Before coding:

1. inspect the entire repository;
2. read `design.md` and `agents.md` completely;
3. inspect migrations/models/routes/frontend architecture;
4. inventory existing work and preserve correct implementations;
5. identify gaps against this master prompt;
6. create an implementation checklist ordered by dependency.

During implementation:

- work vertically feature by feature;
- run tests after meaningful changes;
- keep TypeScript/PHP static errors at zero;
- refactor repeated patterns into reusable abstractions;
- update documentation as architecture changes;
- do not rewrite working code unnecessarily;
- preserve source content integrity;
- make sensible decisions without asking for confirmation unless a blocked secret/external credential is genuinely required.

Before finishing:

1. run backend tests;
2. run frontend lint/typecheck/tests;
3. run production build;
4. run SSR build/start validation;
5. run E2E tests;
6. inspect responsive layouts;
7. inspect browser console;
8. inspect accessibility/reduced motion;
9. verify CMS content completeness;
10. verify no hardcoded editorial content remains;
11. verify security-sensitive files are excluded;
12. summarize any remaining external dependencies or stakeholder verification items.

The final product should feel architecturally disciplined: **purposeful, elegant, restrained, technically robust, highly editable, and memorable without sacrificing speed or usability.**