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	protocol5.com
Source URL	https://protocol5.com/
Canonical AIWikis URL	https://aiwikis.org/protocol5/files/raw-system-archives-protocol5-report-preservation-2026-05-02-agent-file-bcc63b57/
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-06-22T01:56:21.9510185Z
Last changed	2026-05-02T22:34:38.8925068Z
Content hash	sha256:bcc63b5744323b4c7c626ff08d548d93cd43592eba4d9b8a81c9ff42340b3e55
Import status	unchanged
Raw source layer	data/sources/protocol5/raw-system-archives-protocol5-report-preservation-2026-05-02-agent-file-handoff-archive-current-bcc63b574432.md
Normalized source layer	data/normalized/protocol5/raw-system-archives-protocol5-report-preservation-2026-05-02-agent-file-handoff-archive-current-bcc63b574432.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

This public page shows a bounded preview of a large source file. The complete source remains in the raw and normalized source layers named in metadata, with the SHA-256 hash above for verification.

• Source characters: 31182
• Preview characters: 11909

# 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.

Why This File Exists

This is a memory-system evidence file from protocol5.com. 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

• Source overview
• Site file index
• Site report index
• UAI system index
• Source provenance
• Site directory
• Organization reports

Provenance And History

• Current observation: 2026-06-22T01:56:21.9510185Z
• Source origin: current-source-workspace
• Retrieval method: local-source-workspace
• Duplicate group: sfg-909 (primary)
• Historical hash records are stored in data/hashes/source-file-history.jsonl.

Machine-Readable Metadata

{
    "title":  "Executive Summary",
    "source_site":  "protocol5.com",
    "source_url":  "https://protocol5.com/",
    "canonical_url":  "https://aiwikis.org/protocol5/files/raw-system-archives-protocol5-report-preservation-2026-05-02-agent-file-bcc63b57/",
    "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:bcc63b5744323b4c7c626ff08d548d93cd43592eba4d9b8a81c9ff42340b3e55",
    "last_fetched":  "2026-06-22T01:56:21.9510185Z",
    "last_changed":  "2026-05-02T22:34:38.8925068Z",
    "import_status":  "unchanged",
    "duplicate_group_id":  "sfg-909",
    "duplicate_role":  "primary",
    "related_files":  [

                      ],
    "generated_explanation":  true,
    "explanation_last_generated":  "2026-06-22T01:56:21.9510185Z"
}