Executive Summary

Protocol5.com is currently a minimal ASP.NET site (likely MVC with Blazor components) hosting static math and UAI content. Its architecture appears monolithic, using static HTML and C# Blazor for an interactive calcul...

Metadata

Field	Value
Source site	aiwikis.org
Source URL	https://aiwikis.org/
Canonical AIWikis URL	https://aiwikis.org/files/aiwikis/raw-system-archives-protocol5-report-preservation-2026-05-02-agent-file-575124dc/
Source reference	raw/system-archives/protocol5/report-preservation/2026-05-02/agent-file-handoff/Archive/Current Site Audit Current Site Audit.md
File type	md
Content category	memory-file
Last fetched	2026-05-03T02:48:13.1276041Z
Last changed	2026-05-02T22:34:38.8925068Z
Content hash	sha256:575124dcc054868d816c4f608d4b677b6222cb13d283427b8956dab0fffa423f
Import status	unchanged
Raw source layer	data/sources/aiwikis/raw-system-archives-protocol5-report-preservation-2026-05-02-agent-file-handoff-archive-current-575124dcc054.md
Normalized source layer	data/normalized/aiwikis/raw-system-archives-protocol5-report-preservation-2026-05-02-agent-file-handoff-archive-current-575124dcc054.txt

Current File Content

Structure Preview

• Executive Summary
• Current Site Audit
• Cutting-Edge Web Examples and Trends
• Recommended ASP.NET Core MVC Architecture
• TypeScript Frontend Tooling (No Frameworks)
• 3D/WebGL Libraries and Use-Cases
• UI/UX & Design System Approach
• Performance, SEO, and Security
• CI/CD and Testing
• Hosting and Infrastructure Options
• Phased Migration Plan
• Prototypes and Metrics

Raw Version

# Executive Summary  
Protocol5.com is currently a minimal ASP.NET site (likely MVC with Blazor components) hosting static math and UAI content. Its architecture appears monolithic, using static HTML and C# Blazor for an interactive calculator. The redesign will upgrade to a modern **ASP.NET Core MVC** architecture with TypeScript-driven client-side logic and optional 3D/WebGL features, while eschewing large UI frameworks. We propose using a **layered (clean) architecture** with separate projects for UI, application core (domain), and infrastructure, enabling clear separation of concerns and testability【27†L87-L95】【29†L247-L254】. Frontend assets (TypeScript, CSS, 3D) will be managed with a modern bundler (e.g. Vite) and served via SSR pages by default for SEO, with progressive enhancement for interactive parts. A design system using semantic HTML, CSS methodologies (e.g. BEM or utility classes), and consistent animations/micro-interactions will ensure a polished UI. The plan includes phased migration (audit, scaffolding, content port, interactive features, optimization), each with milestones, rough timelines, and risk mitigation. We recommend GitHub Actions/Azure DevOps for CI/CD, xUnit/Playwright for testing, and hosting on a managed cloud platform (Azure App Service or similar) with auto-scaling. Cutting-edge examples (e.g. immersive 3D portfolio sites) show how WebGL, subtle animations, and responsive design can create highly engaging experiences【13†L55-L63】【16†L325-L333】. Our strategy emphasizes **performance (Core Web Vitals)**, **SEO (SSR and metadata)**, **accessibility (WCAG best practices)**, and **security (HTTPS, input validation, headers)**. We will prototype 3D elements (using Three.js or Babylon.js) and animations, and track success via metrics (Lighthouse scores, traffic, engagement).  

# Current Site Audit  
**Architecture/Stack:** The existing protocol5.com appears to be an **ASP.NET MVC** app (URLs like `/Home/About`) on Windows IIS. It uses plain HTML/CSS and likely C# with some Blazor for math tools (“Blazor calculator shell” mentioned on About page). No database is evident – content is static pages. The site has minimal assets and likely a monolithic codebase. *Assumption:* The backend is an ASP.NET Core or .NET Framework app with no external services.  

**Assets:** There are virtually no images or media except a small logo. No CSS framework or JS libraries are loaded. The UI is basic, indicating a very lightweight asset footprint (good for performance but stale in style).  

**Content Structure:** Navigation is simple (“Home”, “About”, “Contact”, “Calculator”, etc). Pages are mostly text lists of links and descriptions of math/UAI tools. No rich content hierarchy or templates (each page bespoke).  

**SEO:** Basic page titles and text exist, but no sophisticated metadata or sitemap is visible. With SSR pages, content is crawlable, but no structured data or SEO optimizations are present. No Google Analytics or SEO hints are apparent.  

**Performance:** The site loads quickly due to its simplicity (essentially zero JS/CSS). Lighthouse on the current site would score high performance but low in **interactivity** and “visual design” (an aesthetic issue more than metric).  

**Accessibility:** The site uses semantic headings and links, which is good. However, no mention of alt text on any images (though few exist) and no ARIA usage. Contrast is default (black on white). Likely keyboard navigation is possible given simple HTML, but forms/buttons may need review.  

**Unspecified:** It’s unclear how code is organized (one project vs many), whether any tests or CI exist, and where the source code resides. We assume minimal automated testing. No CDN or global deployment strategy is used.  

# Cutting-Edge Web Examples and Trends  
Modern “bleeding-edge” sites use rich visuals and interactivity without sacrificing performance or accessibility. Common trends include **immersive 3D**, **scrollytelling**, **micro-interactions**, and **progressive enhancement**. For example, award-winning portfolios often integrate **WebGL/Three.js** scenes or scroll-driven canvas animations to wow users【13†L55-L63】【16†L325-L333】. The Orpetron list of 3D web projects highlights sites where 3D objects, parallax, and animations drive engagement (e.g. interactive product models, mini-games embedded in marketing pages). Likewise, design showcases (like Rimbo’s top sites 2025) note micro-animations, fluid transitions, and even sound cues for immersion【22†L187-L194】【22†L195-L201】. Performance remains critical: these sites use techniques like lazy loading, code-splitting, and SSR to ensure fast LCP (Largest Contentful Paint) and FID (First Input Delay) despite heavy graphics. Accessibility is also increasingly prioritized: semantic HTML, keyboard support, ARIA labels, and alt text ensure users with disabilities are served. Progressive enhancement ensures that if WebGL or JS fails, core content remains accessible. Examples: 
- **WebGL Portfolios:** Sites like a creative designer’s portfolio or a product showcase using Three.js where a 3D scene responds to scroll or cursor (visual cues, storytelling). 
- **Interactive Data Vizzes:** Dashboard-like UIs with WebGL charts (e.g. Company annual report with 3D charts). 
- **Brand Experiences:** E.g. technology brands’ sites built as mini web-apps (high performance, tested for SEO via SSR or pre-rendering). 
These examples share traits: crisp, low-level control of graphics (often using Three.js or Babylon.js), custom animations (using CSS or GSAP), and responsive layouts that degrade gracefully【13†L55-L63】【50†L61-L70】. In summary, cutting-edge means **enticing visuals + seamless UX** (animation and feedback, per NNGroup), **fast performance** (Core Web Vitals compliance), and **inclusive design**.  

# Recommended ASP.NET Core MVC Architecture  
**Layered (Clean) Architecture:** We recommend a Clean (onion/hexagonal) architecture【29†L247-L254】. This means distinct projects/layers: 
- **Application Core** (business/domain model): Entities, value objects, domain services, interfaces (e.g. ICalculator, IDataProvider). No external dependencies.  
- **Infrastructure**: Data access (EF Core, other DB or API clients), logging, file storage, email/SMS services, etc. Implements interfaces from Core【29†L247-L254】.  
- **Web (UI)**: The ASP.NET Core MVC project with Controllers, Views, ViewModels. It references Application Core interfaces and uses DI to inject infrastructure implementations【29†L323-L333】【29†L369-L378】.  
- **Tests**: Separate projects for unit tests and integration tests. Controllers and services are tested via xUnit or NUnit, using in-memory DB and mock services. The UI can be tested with automated browser tests (Playwright/Selenium).  

Using separate projects avoids “spaghetti code”【27†L99-L104】 and makes swapping components (e.g. DB engine) easier【27†L125-L134】【29†L261-L269】. The recommended solution structure is:  
```
/src
  /MyApp.Web (ASP.NET Core MVC) – references Core
  /MyApp.Core (Class Library) – domain entities, interfaces
  /MyApp.Infrastructure (Class Library) – EF DbContext, Repos, API clients (refs Core)
  /MyApp.Tests (xUnit) – unit and integration tests for Core and Infrastructure
```
The Clean Architecture ensures the **Application Core** has no dependencies on .NET or EF, only on .NET Standard libraries【29†L247-L254】【29†L323-L333】. Controllers in Web should only depend on interfaces/services from Core, never on EF types directly【29†L369-L378】. Diagrammatically:  

【66†embed_image】 *Figure: “Onion” view of Clean Architecture. The UI (controllers, view models) and Infrastructure (data, services) depend on the Application Core (entities, interfaces)【29†L247-L254】.*  

**C# Patterns:** Use DI (built-in ASP.NET Core DI) to inject services into controllers【29†L277-L284】. Patterns like Repository & Unit-of-Work for data (if complex) are common【29†L345-L354】. Consider Command-Query Responsibility Segregation (CQRS) or MediatR for complex logic. Use _async/await_ throughout for scalable I/O. Keep controllers thin: delegate to services in Application Core. Use strongly-typed ViewModels for passing data to Razor views.  

**API Design:** If external data is needed (e.g. third-party math APIs), create explicit service classes in Infrastructure with interfaces in Core. Design RESTful Web APIs (if adding public APIs), version them, and document with OpenAPI/Swagger. Rate-limit and validate inputs.  

**SSR vs SPA trade-offs:** Given the content (static info + specialized calculators), **server-side rendering (Razor views)** is preferable for initial loads and SEO. We can SSR the main pages (so bots see content easily), then enhance with client-side scripts (TypeScript) for interactivity. A full SPA (e.g. Angular/React) is not needed and was explicitly to be avoided. However, for highly interactive tools (calculators, 3D canvases), we will use client scripts loaded into Razor pages. This hybrid approach maximizes SEO and performance (critical images/HTML delivered from server) while still allowing rich client experiences. If considering Blazor components (C# in browser) – note current site uses it – one could stick with Blazor WASM for math tools, but the requirement to use TypeScript suggests implementing interactivity in JS/TS instead. In summary: **Razor pages + partial client-side enhancements** is recommended, not a pure SPA. SSR also helps with performance (LCP)【54†L281-L290】.  

# TypeScript Frontend Tooling (No Frameworks)  
**Build Tool and Bundler:** We recommend using **Vite** (with vanilla TS) or **esbuild** for bundling. Vite (Rollup-based in production) offers near-instant dev server and HMR【31†L60-L69】. It “supports importing `.ts` files out of the box”【36†L211-L219】 and is now the standard for new projects【31†L72-L74】【32†L146-L150】. A sample TL;DR from 2026 says *“Use Vite for new web apps”*【31†L72-L74】. If ultimate speed is needed, esbuild (written in Go) is extremely fast but has less plugin ecosystem【31†L60-L69】. We can summarize bundler pros/cons:

| Bundler    | Dev Startup  | HMR Speed      | Code-Splitting | Ecosystem    | Use Case             |
|------------|-------------|----------------|---------------|--------------|----------------------|
| Webpack    | Slow        | Slow on large  | Excellent     | Massive      | Legacy/Complex apps  |
| Vite       | Fast (~ms)  | Near-instant   | Good (Rollup) | Growing fast | New TS/Vanilla apps【31†L60-L69】 |
| esbuild    | Instant     | N/A (no server)| Basic         | Limited      | CLI tools, libraries|
*(Based on benchmarks【31†L60-L69】.)*  

For this project, **Vite** is ideal: modern, quick dev, supports TS natively【36†L211-L219】, and simple config. (It uses esbuild under the hood for TS transpile.) A `tsconfig.json` with `"isolatedModules": true` fits Vite’s on-demand compile【36†L269-L278】. Build output (JS+CSS+assets) should go to `wwwroot/` for serving by ASP.NET. Use `<script type="module" src="...">` in Razor pages.  

**Module Strategy:** Develop with ES modules (`import`/`export`). Use dynamic `import()` for lazy-loading heavy code (e.g. 3D scene) only when needed. This split ensures initial pages load quickly. Mark critical assets with `rel="preload"` or `fetchPriority="high"` (for images/scripts) as recommended【54†L285-L294】.  

**No UI Framework:** We avoid Angular/React/Vue. Instead use vanilla TS or small libraries. For DOM manipulation or state, consider **Stimulus** or **HTMX** style progressive enhancements if needed (though HTMX is more for HTML). Micro-libraries (like Alpine.js or lit-html) could be allowed if they don’t count as “full frameworks” (but user said avoid frameworks). Likely we just use plain TS with querySelector, and utilities for small widgets. Tailor bundle size accordingly.  

**CSS Tooling:** We can use a preprocessor (Sass) or PostCSS for convenience (variables, nesting), but not a UI kit. CSS files should be modular (per component) or use BEM naming. Collect common variables in one root file. Use `@media` queries and fluid layouts for responsiveness.  

# 3D/WebGL Libraries and Use-Cases  
For “futuristic” visuals, a JavaScript 3D library is key. The three main contenders are **Three.js**, **Babylon.js**, and **PlayCanvas**【44†L84-L92】【44†L101-L109】:

| Library      | Purpose             | Ease/Size            | Notable Use-Cases                    |
|--------------|---------------------|----------------------|--------------------------------------|
| Three.js     | Low-level 3D engine | **Most popular** (~5M weekly downloads【44†L86-L94】); ~168 KB gz | Custom 3D scenes, data viz, creative effects |
| Babylon.js   | Full game engine    | ~13K downloads; ~1.4 MB | VR/AR experiences, physics demos, games |
| PlayCanvas   | Cloud-based engine  | ~15K downloads; ~300 KB | Teams prototyping with visual editor    |

According to a 2026 survey, *“Three.js dominates the ecosystem with 5 million weekly downloads – 300x more than Babylon or PlayCanvas”*【44†L86-L94】. It’s a rendering foundation (scene/mesh/lights) with no built-in physics or UI – you assemble everything. Babylon.js is “batteries-included” (includes physics, audio, XR out of box)【44†L86-L94】, but heavier. PlayCanvas offers an online IDE for rapid prototyping (useful if non-coders on team). 

**Recommendation:** Use **Three.js** for maximum flexibility and community support, especially for custom visuals. It also now supports WebGPU seamlessly (no extra setup)【44†L86-L94】. For example, a rotating 3D logo or interactive calculator could be built with Three.js (perhaps with React-Three-Fiber if we used React, but we avoid that). If needing physics or a quick demo, Babylon.js could be considered (its Node Materials and physics engine are handy)【44†L86-L94】. We can integrate either by loading the library via npm/Vite and writing TS modules. GLTF/GLB model loading is supported by both (for any complex 3D assets).

**Use-Cases:** In Protocol5’s context, possible 3D enhancements include:  
- A 3D “Math Cube” visualizing number bases or formulas.  
- A dynamic, rotating UAI logo or interactive orbit of AI concepts.  
- Animated 3D charts of mathematical sequences or random distributions.  
These elements should be optional (wrapped in `<noscript>` or fallback) so that if WebGL fails, the site still shows core info. 

See the comparison **Table** above or [44†L101-L109] for more on features (GPU support, engines, etc.).  

# UI/UX & Design System Approach  
**CSS Architecture:** Adopt a component-based CSS approach (e.g. **BEM** or **SMACSS**). Each UI component (nav, button, card) has its own styles. For example, `.btn`, `.btn--primary` modifiers, etc., as shown in design system examples【46†L85-L93】. This avoids global conflicts. Alternatively, CSS modules (scoped CSS) via bundler could be used. Define design tokens (colors, spacing, fonts) in a root CSS (or SCSS) file for consistency. Use `rem` units and CSS Grid/Flexbox for fluid layouts. No Bootstrap – all layout and components are hand-crafted or utility-based (e.g. minimal utility classes if used, but not a full Tailwind integration).

**Responsive Design:** Use a mobile-first breakpoints strategy (e.g. max-width queries). Ensure layout adapts from single-column mobile to multi-column desktop. Images and canvases use `max-width: 100%` for fluidity. 

**Animations and Micro-interactions:** Small animations make the site feel alive. Use **CSS transitions** and `transform: translate/scale` for hover/focus states on buttons/links (fast, GPU-accelerated). Keyframe animations can be used for entrance effects or looping visuals. For more complex sequences or timeline control, a JS library like **GSAP** or **Anime.js** may be used (GSAP is powerful and widely used). However, use them sparingly to avoid performance cost. 

**Micro-interactions** (e.g. a slight bounce when clicking a button, a spinner when loading data, or a highlight on focus) should follow UX best practices. As Nielsen Norman Group explains, micro-interactions give feedback, communicate status, and enhance engagement【50†L61-L70】. For example, when a calculation is performed, a short success animation (e.g. a checkmark fade-in) or an error shake effect can confirm to the user that something happened. These effects should be quick (100–300ms) and only where they improve clarity. 

**Accessibility in UI:** Use semantic HTML tags (`<header>`, `<main>`, `<nav>`, `<footer>`, `<button>`, `<form>` etc) for meaning【57†L308-L317】. All images/canvases get descriptive `alt` or `aria-label`. Ensure tab order is logical (focusable elements). Contrast should meet WCAG AA (e.g. dark text on light background 4.5:1 contrast【57†L263-L272】). Interactive elements should have clear focus styles. 

# Performance, SEO, and Security  
**Performance:** Aim to optimize **Core Web Vitals**. Follow Google’s web.dev guidance on key metrics. In particular, **avoid long JS tasks** that block the main thread【52†L151-L159】. For example, break up heavy computations or loading into smaller async chunks. Avoid shipping unused JS; use Vite’s code-splitting and remove dead code【54†L183-L192】. Defer or lazy-load any non-critical scripts or images (e.g. third-party widgets) so initial render is fast. Preload key assets (CSS, hero images) to speed LCP. Use `rel="preload"` or `fetchPriority="high"` on critical resources【54†L281-L290】. Ensure images are optimized (compress, use WebP/AVIF) and set proper width/height to avoid layout shifts.

From web.dev: “When you ship too much JavaScript, tasks compete for the main thread’s attention, hurting responsiveness【54†L183-L192】.” So we will keep JS minimal and lazy-load heavy modules (like 3D). We will enable gzip/Brotli on the server and use caching headers. We should integrate Lighthouse or WebPageTest in CI to track performance budgets. 

**SEO:** Use SSR to ensure all content appears in HTML (good for crawlers). Include `<title>`, `<meta name="description">`, and open graph tags on each page. Generate an XML sitemap and submit to Google Search Console. Ensure URLs and navigation use text links (not JS-only links). Use semantic markup (headings hierarchy)【57†L308-L317】. For any dynamically-loaded content (e.g. 3D or canvas charts), provide alternative text or summarizing text. Use structured data (schema.org) if applicable (e.g. a FAQ section could use FAQ schema for better search snippets). Since SSR is used, Google can index pages normally; avoid hidden content or fragments that require JS. For dynamic routes (e.g. `/calculator`), ensure server route exists or pre-render it.

**Accessibility:** Follow WCAG 2.1 AA guidelines. Use semantic HTML, labels on form inputs, alt text on images, and ARIA roles if we use custom widgets【57†L263-L272】. Ensure keyboard support (e.g. custom scripts don’t hijack tab). Use `aria-live` regions for dynamic status messages. Maintain color contrast ≥4.5:1【57†L263-L272】. Test with automated tools (axe, Lighthouse a11y) and manual checks (screen reader, keyboard-only). Accessibility improves SEO too (semantics, alt text).

**Security:** Use HTTPS (already in place). Sanitize all inputs on server side to prevent SQL injection/XSS (though little input form). Use ASP.NET Core’s built-in request validation (`[ValidateInput]` etc) and Razor’s automatic HTML encoding. Enable anti-forgery tokens on forms (MVC does by default). Set security headers (CSP, HSTS, X-Frame-Options) via middleware. Ensure dependencies (NuGet, npm) are kept up-to-date to avoid vulnerabilities. Use OWASP guidelines for .NET. For any APIs, use HTTPS, auth tokens, rate limiting as needed.

# CI/CD and Testing  
**CI/CD:** Adopt an automated pipeline (e.g. GitHub Actions or Azure Pipelines). On each push/pull-request to `main`:  
- **Build** the .NET solution (dotnet build).  
- **Run Unit Tests** (dotnet test) and fail on errors.  
- **Lint/Type-check TS** (e.g. `tsc --noEmit`).  
- **Run Accessibility/Performance Checks:** Optionally run `dotnet tool run cherow` or Lighthouse CI.  
- **Publish Artifacts:** On successful build, publish to a `dev` slot or container registry.  
- **Deployment:** Merge to `production` triggers deployment to Azure App Service or other host. Use deployment slots (staging/production) for zero-downtime.  

GitHub Actions has official templates for .NET builds【60†L91-L99】. Use the `actions/checkout`, `actions/setup-dotnet`, and steps for `dotnet build`, `test`, `publish`. Store secrets (DB connection strings, API keys) as encrypted repo secrets【60†L118-L127】. Optionally include CodeQL or SonarCloud for security analysis【60†L107-L115】.  

**Testing:** Unit-test C# code with **xUnit** (or NUnit). Write tests for services (e.g. number conversion logic, math functions) using in-memory data or mocking as needed. For critical functions (calculator), cover edge cases. For UI, use **ASP.NET TestServer** for integration tests of controllers, or **Playwright/Selenium** for end-to-end tests. For example, a Playwright test can launch Chrome and verify the Calculator page, entering values, checking results. Use these to prevent regressions. Also write some JS unit tests (e.g. for any TypeScript utilities) using Jest or Vitest. Incorporate testing into CI: fail builds on test failures.  

Maintain a test project structure:  
```
/tests
   /MyApp.Core.Tests (xUnit)
   /MyApp.Web.Tests (xUnit, using WebApplicationFactory)
   /E2E (Playwright project)
```
Use mocking frameworks like Moq for isolating dependencies. Cover controllers via `TestServer` and assert HTTP responses or HTML content.  

# Hosting and Infrastructure Options  
For hosting the ASP.NET Core app, we consider cloud PaaS or containers. Below are some options:

| Option                 | Description                                        | Pros                              | Cons                             |
|------------------------|----------------------------------------------------|-----------------------------------|----------------------------------|
| **Azure App Service**  | Managed PaaS for .NET apps. Auto-scaling, Windows or Linux. | Easy deployment (Git/GitHub), built-in auto-scaling and monitoring, .NET optimized【60†L41-L44】. Integration with Azure DB, CDN. Good support for SSR. | Less control over OS. Windows hosting can be pricier. Vendor lock-in. |
| **AWS Elastic Beanstalk** | PaaS for .NET (on EC2), auto-scaling, Windows or Linux.    | Easy .NET support (AWS Toolkit), auto-scaling and LB【64†L101-L109】, runs on familiar AWS infra.  | Complex config (VPC, etc) vs Azure. Different deployment model. |
| **Docker + Containers** | Self-managed on Azure Container Instances, AKS, ECS, etc.      | Full control, portable (runs anywhere). Can use Linux containers to reduce cost.  | More DevOps overhead (container build, orchestration). Need to manage scaling. |
| **Static Site + Functions** | Host static content (HTML/CSS/JS) in Azure Static Web Apps or AWS S3+CloudFront, with Azure Functions/AWS Lambda for dynamic (calculators). | Very scalable; pay-per-use; SSR possible via prerender.   | More complex to implement SSR and dynamic logic (e.g. recoding C# logic to functions or using minimal API). |
| **Other Clouds (GCP App Engine)** | Similar managed hosting for .NET Core. | Global infra, competitive pricing. | Less native .NET integration, smaller community for .NET on GCP. |

*Comparison:* Azure App Service is often easiest for ASP.NET Core and integrates well with Azure DevOps/GitHub. AWS Elastic Beanstalk is analogous and automates scaling【64†L101-L109】 but might require more AWS-specific config. For a small site, a **single App Service instance (with auto-scale)** is simple. We may start with Azure App Service (Linux plan) for cost-efficiency. If using containers, Azure Container Apps or Azure Kubernetes Service could be options, but overkill for a modest site. For global CDN, use Azure Front Door or AWS CloudFront to cache static assets.  

*SSL & CDN:* Enforce HTTPS (Azure App Service has free TLS). Offload static assets (images/scripts) to CDN to speed delivery.  

Cost-wise, App Service basic tier (~$50/mo) can suffice initially. Plan to scale up if traffic grows (App Service can scale out automatically).  

# Phased Migration Plan  

We propose a multi-phase rollout. Each phase has deliverables, estimated effort, and risks:

1. **Phase 1 – Discovery & Planning (2 weeks)**  
   - **Activities:** Audit current site (content mapping), define architecture (diagram), set up repos and project plan. Create wireframes or style samples. Prototype key interactions (simple TS demo).  
   - **Deliverables:** Audit report, architecture diagram (Mermaid clean-arch), Styleguide draft (colors/fonts). Updated content inventory.  
   - **Effort:** 1 developer (~2w).  
   - **Risks:** Misunderstanding scope (mitigate by stakeholder review).  

2. **Phase 2 – Project Setup (3 weeks)**  
   - **Activities:** Scaffold ASP.NET Core solution with layered projects. Configure CI/CD (GitHub Actions pipeline). Integrate Vite for TS bundling (with sample hello-world script). Implement global layout, _Shared views_, and navigation. Basic responsive CSS setup.  
   - **Deliverables:** Working solution with CI: build passes, dev site on dev server. Initial homepage with nav and footer. Vite build outputs in wwwroot.  
   - **Effort:** 1 dev (~3w).  
   - **Risks:** Build tooling integration issues (address early with sample builds).  

3. **Phase 3 – Content & Static Pages Migration (4 weeks)**  
   - **Activities:** Port all static content (About, Contact, links) into Razor views/partials. Implement main site pages in MVC (Views and controllers). Ensure SEO metadata for each page. Add basic mobile-friendly layout (grid or flex).  
   - **Deliverables:** Feature-complete site content, accessible via navigation. Dev URL accessible publicly. Preliminary SEO: sitemap.xml generated, meta tags.  
   - **Effort:** 1–2 devs (~4w).  
   - **Risks:** Content gaps or formatting issues (mitigate by mapping old pages carefully).  

4. **Phase 4 – Interactive Tools & 3D Prototypes (5 weeks)**  
   - **Activities:** Port or rewrite calculators/tools. For simple tools, implement in TS (e.g. number base converter) integrated in pages. Introduce 3D element prototypes (using Three.js) on relevant pages (e.g. interactive UAI logo in About). Ensure these are lazy-loaded. Develop micro-interactions (CSS/GSAP animations) on hover or scroll.  
   - **Deliverables:** Working calculators (client-side), at least one polished 3D interactive demo, CSS animations, unit tests for core logic. Load times acceptable (performance test).  
   - **Effort:** 1–2 devs (~5w).  
   - **Risks:** Performance issues with WebGL (mitigate via testing on multiple devices; use simple scenes). Overcomplex animations (use profiling to keep FPS high).  

5. **Phase 5 – Optimization & Testing (3 weeks)**  
   - **Activities:** Audit performance (Lighthouse), fix issues (image sizes, caching headers). Full accessibility audit (axe). Write remaining tests. Implement analytics/tracking. Harden security (headers, validate all inputs). Finalize CI/CD to include tests.  
   - **Deliverables:** Performance targets met (e.g. 90+ lighthouse), accessibility score AAA, all automated tests passing. Documentation.  
   - **Effort:** 1 dev (~3w).  
   - **Risks:** Unfixed performance bottlenecks (mitigate by incremental profiling).  

6. **Phase 6 – Launch (2 weeks)**  
   - **Activities:** Deploy to production (swap slots), conduct final QA, user acceptance testing, bug fixes. Monitor logs, performance after launch.  
   - **Deliverables:** Live site, rollback plan, metrics baseline. Project hand-off.  
   - **Effort:** 1 dev (~2w).  
   - **Risks:** Deployment issues (use staging slot for rehearse), DNS downtime (prepare TTL changes).  

Total ~19 weeks (~5 months) for single developer; scale with team to shorten duration. 

**Milestones & Metrics:** Each phase ends with a demo and review. Success metrics include performance scores (Lighthouse), SEO (indexed pages in Google), accessibility (axe CI > 90), and user feedback on UX. 

```mermaid
gantt
    title Protocol5 Redesign Migration Plan
    dateFormat  YYYY-MM-DD
    section Planning
    Architecture design      :done,   arch, 2026-05-03, 2026-05-14
    section Setup
    Project scaffolding      :        setup, after arch, 2w
    CI/CD pipeline           :        cicd, 1w
    section Content
    Migrate static pages     :        pages, after cicd, 3w
    SEO & Sitemap            :        seo, 1w
    section Features
    TS Calculators & 3D demos:        tools, after pages, 3w
    Animations & microinter. :        anim, 2w
    section Optimization
    Performance tuning       :        perf, after tools, 2w
    Accessibility fixes      :        acc, 1w
    Testing (unit+E2E)       :        test, 1w
    section Launch
    Final QA & deployment    :        launch, after perf, 2w
```

# Prototypes and Metrics  
**Prototypes:** Early prototypes for demonstration could include: 
- A **3D Interactive Logo** on the homepage (Three.js scene rotating an AI/Math themed shape). 
- A **Procedural Visualization** (e.g. draw a Mandelbrot fractal or animate Pi digits in a spiral). 
- A **Math Toolkit** Single Page (with TS-driven sliders and live-updating charts).
These will be mini apps using pure TS or a small 3D lib. Tools like CodePen or local test pages can refine these.  

**Success Metrics:** 
- *Performance:* >90 in Lighthouse Performance on desktop/mobile (First Contentful Paint <1s, TTI <2s). 
- *SEO:* All pages indexed (Google Search Console), organic traffic growth. 
- *Accessibility:* WCAG AA compliance (automated score >90). 
- *Engagement:* Time-on-site increase, tool usage stats (if tracked). 
- *Stability:* All tests passing, <X bugs per month in next cycle. 

Continuous monitoring (e.g. with Azure Application Insights) and user feedback will guide refinements. 

**Conclusion:** This redesign will transform Protocol5 into a modern, high-performance web platform that showcases cutting-edge web design (3D, animations) and solid engineering (Clean architecture, CI/CD) while keeping focus on content and usability【13†L55-L63】【50†L61-L70】. The combination of official guidance (Microsoft architecture docs), up-to-date web tooling (Vite/Three.js), and accessibility/performance best practices will make the new Protocol5 a “website of the future.”  

**Sources:** Authoritative guides (Microsoft Docs on Clean Architecture【29†L247-L254】【29†L323-L333】, Google web.dev on performance【52†L124-L133】【54†L183-L192】, Nielsen Norman on microinteractions【50†L61-L70】) and recent analyses (bundler comparisons【31†L60-L69】【32†L146-L150】, 3D lib survey【44†L86-L94】, design trend articles【13†L55-L63】【22†L187-L194】) were used to inform recommendations. All proposed tools and patterns reflect 2024–2026 best practices.

Why This File Exists

This is a memory-system evidence file from aiwikis.org. It is shown here because AIWikis.org is demonstrating the real source files that make the UAIX / LLM Wiki memory system work, not only summarizing those systems after the fact.

Role

This file is memory-system evidence. It records source history, archive transfer, intake disposition, or another piece of provenance that should be retrievable without becoming an unsupported public claim.

Structure

The file is structured around these visible headings: Executive Summary; Current Site Audit; Cutting-Edge Web Examples and Trends; Recommended ASP.NET Core MVC Architecture; TypeScript Frontend Tooling (No Frameworks); 3D/WebGL Libraries and Use-Cases; UI/UX & Design System Approach; Performance, SEO, and Security. Those headings are retrieval anchors: a crawler or LLM can decide whether the file is relevant before reading every line.

Prompt-Size And Retrieval Benefit

Keeping this material in a separate file reduces prompt pressure because an agent can load this exact unit only when its role, source site, category, or hash is relevant. The surrounding index pages point to it, while this page preserves the full content for audit and exact recall.

How To Use It

• Humans should read the metadata first, then inspect the raw content when they need exact wording or provenance.
• LLMs and agents should use the source site, category, hash, headings, and related files to decide whether this file belongs in the active prompt.
• Crawlers should treat the AIWikis page as transparent evidence and follow the source URL/source reference for authority boundaries.
• Future maintainers should regenerate this page whenever the source hash changes, then review the explanation if the role or structure changed.

Update Requirements

When this source file changes, update the raw source layer, normalized source layer, hash history, this rendered page, generated explanation, source-file inventory, changed-files report, and any source-section index that links to it.

Related Pages

• Global File Index
• Reports

Provenance And History

• Current observation: 2026-05-03T02:48:13.1276041Z
• Source origin: current-source-workspace
• Retrieval method: local-source-workspace
• Duplicate group: sfg-163 (primary)
• Historical hash records are stored in data/hashes/source-file-history.jsonl.

Machine-Readable Metadata

{
    "title":  "Executive Summary",
    "source_site":  "aiwikis.org",
    "source_url":  "https://aiwikis.org/",
    "canonical_url":  "https://aiwikis.org/files/aiwikis/raw-system-archives-protocol5-report-preservation-2026-05-02-agent-file-575124dc/",
    "source_reference":  "raw/system-archives/protocol5/report-preservation/2026-05-02/agent-file-handoff/Archive/Current Site Audit Current Site Audit.md",
    "file_type":  "md",
    "content_category":  "memory-file",
    "content_hash":  "sha256:575124dcc054868d816c4f608d4b677b6222cb13d283427b8956dab0fffa423f",
    "last_fetched":  "2026-05-03T02:48:13.1276041Z",
    "last_changed":  "2026-05-02T22:34:38.8925068Z",
    "import_status":  "unchanged",
    "duplicate_group_id":  "sfg-163",
    "duplicate_role":  "primary",
    "related_files":  [

                      ],
    "generated_explanation":  true,
    "explanation_last_generated":  "2026-05-03T02:48:13.1276041Z"
}