Runtime

Master Build Prompt — GgufRuntime.com Custom WordPress Developer Portal

Report summary

Act as a senior WordPress architect, product designer, accessibility engineer, frontend performance engineer, technical writer, and QA lead. Build a production-grade replacement for the current GgufRuntime.com WordPress starter site.

Status
Research archive item
Category
Runtime
Length
6,414 words
Reading time
30 minutes
Report type
strategy

Key topics

  • Runtime
  • AI
  • UAIX
  • WordPress
  • SEO
  • .NET
  • SQL
  • Angular

Research provenance

Archive status
Research archive item
Content identity
sha256:a3ee86fd1efb73501397adc185af835d7fe542298133af6267f214a0fef850e0

For citation, use the report title and canonical URL. Archival presence does not establish authorship or promote report statements into portfolio evidence.

This page renders the archived Markdown as safe, formatted HTML. It is background research and does not become a portfolio claim without evidence review.

Full report

On this page

Role

Act as a senior WordPress architect, product designer, accessibility engineer, frontend performance engineer, technical writer, and QA lead. Build a production-grade replacement for the current GgufRuntime.com WordPress starter site.

Do not deliver a generic mockup, a page-builder configuration, a child theme, or a superficial landing page. Deliver a complete, maintainable, custom WordPress implementation with a purpose-built block theme, a small companion plugin for durable site functionality, starter content, automated tests, documentation, and release-ready ZIP packages.

The finished site must look and behave like a premium developer portal for experienced C#/.NET engineers. It must communicate technical scope precisely, make roadmap status unambiguous, and remain fast and usable without JavaScript.

1. Source Material and Authority Order

Use these project documents as content and product-planning inputs:

  1. GGUF Runtime Roadmap Planning.md
  2. UIUX Integration for UAIX.LmRuntime.md
  3. GgufRuntime.com Roadmap and Architecture Overview.md

Use these public runtime pages as the authority for current runtime behavior and claim boundaries:

  • https://lmruntime.com/
  • https://lmruntime.com/packages/
  • https://lmruntime.com/architecture/
  • https://lmruntime.com/status/
  • https://lmruntime.com/security/
  • https://lmruntime.com/roadmap/

The planning documents contain proposals, comparisons, example schedules, and future UI concepts. They must not be converted into present-tense product claims unless the current authoritative runtime documentation or reproducible project evidence confirms them.

Authority rules

  • Current runtime documentation outranks planning prose.
  • Current public package APIs outrank speculative sample code.
  • A roadmap entry is not a shipped feature.
  • A package registration or compatibility declaration is not proof of successful execution.
  • Never invent package counts, supported model lists, benchmark results, API methods, release dates, download statistics, platform certifications, or GPU execution claims.
  • If two sources disagree, use the more recent authoritative source and record the conflict in project notes.
  • Add a visible “Last reviewed” date and source link to technical pages. Store custom timestamps in UTC using ISO 8601.
  • Use version-free NuGet installation commands in public documentation. Applications may pin versions in their own lock files, but the website must not publish stale package pins.

2. Product Definition

Site name

GGUF Runtime

Site purpose

GgufRuntime.com is the developer-facing roadmap, architecture, and implementation guidance hub for a cross-platform C# UI layer built around the UAIX.LmRuntime local GGUF runtime family.

It is not a hosted inference service, model marketplace, automatic model downloader, cloud API provider, benchmark leaderboard, or claim of universal GGUF compatibility.

Primary audiences

  1. Senior C# and .NET application engineers.
  2. Desktop and mobile UI engineers evaluating Avalonia or other .NET UI approaches.
  3. Runtime engineers who need visibility into GGUF metadata, tokenization, tensors, sessions, backends, and evidence boundaries.
  4. Technical leads evaluating local inference architecture, resource ownership, security, and deployment constraints.
  5. Contributors tracking roadmap phases, requirements, evidence, and implementation status.

Core positioning

Use concise, technically precise language. The visual and editorial experience should communicate:

  • Local execution and explicit host ownership.
  • Verified GGUF artifact intake.
  • Managed CPU execution as the proven application path unless newer evidence says otherwise.
  • Explicit backend registration, probing, selection, diagnostics, and visible fallback behavior.
  • No hidden provider API, model downloader, telemetry, or automatic authority expansion.
  • A roadmap for developer-focused interfaces, inspection tools, telemetry, and cross-platform application work.
  • Evidence before claims.

Suggested home-page hero copy

Eyebrow: C# · .NET · Local GGUF

H1: Build transparent local GGUF interfaces in C#.

Supporting copy:

Explore the architecture, evidence boundaries, and implementation roadmap for a cross-platform UI layer built around UAIX.LmRuntime.

Primary CTA: Explore the roadmap

Secondary CTA: Review the runtime foundation

Command panel:

dotnet add package UAIX.LmRuntime.LocalEndpoint

Label this command as the runtime foundation quick start, not as an installation command for a finished GgufRuntime UI package unless such a package actually exists.

3. Non-Negotiable Constraints

Frontend prohibitions

  • No Bootstrap.
  • No jQuery.
  • No Tailwind CSS or other frontend CSS framework.
  • No React, Vue, Angular, Svelte, Alpine, HTMX, or similar frontend application framework.
  • No Elementor, Divi, WPBakery, Beaver Builder, Oxygen, Bricks, or other page builder.
  • No Font Awesome, icon font, or remote icon kit.
  • No externally hosted Google Fonts or other remote font service.
  • No CDN-hosted runtime JavaScript or CSS dependency.
  • No stock “AI robot,” glowing brain, humanoid android, or generic circuit-board photography.
  • No autoplay media, scroll hijacking, parallax dependency, or decorative animation that blocks interaction.
  • No carousel.
  • No client-side rendering requirement for primary content.
  • No fake terminal typing effect.
  • No filler text, lorem ipsum, dead links, placeholder cards, or fabricated testimonials.

Required frontend approach

  • Semantic HTML5.
  • Modern native CSS.
  • CSS Grid for macro layout.
  • Flexbox for local alignment.
  • CSS Custom Properties and theme.json design tokens.
  • CSS cascade layers.
  • Vanilla JavaScript using browser APIs only.
  • Progressive enhancement.
  • Server-rendered primary navigation, content, search results, roadmap entries, metadata, and page structure.
  • Inline SVG only for bundled, trusted icons and diagrams.
  • Native browser features such as IntersectionObserver, AbortController, matchMedia, URLSearchParams, Clipboard, details, and dialog where appropriate.

jQuery enforcement

The theme and companion plugin must not declare jQuery as a dependency and must not use $, jQuery, .ready(), or jQuery plugins.

Do not blindly deregister WordPress core jQuery because an unrelated plugin or the admin area may require it. Instead:

  • Keep the theme and approved production plugin list jQuery-free.
  • Audit the public-page network waterfall and generated HTML.
  • Fail CI if theme or companion-plugin source imports or references jQuery.
  • Document any third-party plugin that introduces jQuery as a launch blocker.

4. Architecture Decision

Build two installable packages.

A. Custom block theme

Folder: ggufruntime

Text domain: ggufruntime

The theme owns:

  • Visual design.
  • theme.json tokens and editor controls.
  • Block templates and template parts.
  • Block patterns.
  • Core-block style variations.
  • Layout CSS.
  • Presentation-only JavaScript.
  • Frontend assets.
  • Theme screenshot and metadata.

B. Companion plugin

Folder: ggufruntime-core

Text domain: ggufruntime-core

The plugin owns durable, non-presentational functionality:

  • Custom post types.
  • Custom taxonomies.
  • Registered post meta.
  • Capabilities.
  • Dynamic data-driven blocks.
  • REST search endpoint.
  • Roadmap query and filtering logic.
  • Source-verification metadata.
  • Structured data that depends on content type.
  • WP-CLI starter-content importer.
  • Optional content migration utilities.

This separation is mandatory. Content models and functional blocks must survive a future theme change. The theme must not fatal-error when the companion plugin is disabled; it should continue rendering standard posts and pages with graceful omissions.

5. WordPress Compatibility

At implementation time, verify the latest stable WordPress release and current official APIs.

  • Support the latest stable WordPress release and the immediately previous supported major branch unless a documented API requirement prevents it.
  • Use the latest stable theme.json schema version supported by the declared minimum WordPress version.
  • Do not copy an outdated schema version from examples without verification.
  • Set accurate Requires at least, Requires PHP, and Tested up to metadata.
  • Target PHP versions actively supported by the deployment environment, preferably PHP 8.2 and newer, while testing the exact supported matrix in CI.
  • Follow current WordPress PHP, HTML, CSS, JavaScript, accessibility, and documentation coding standards.
  • Use WordPress APIs instead of custom SQL whenever a suitable API exists.
  • Use native block editor and Site Editor capabilities.
  • Use show_in_rest => true for custom content intended for the block editor or public REST reads.
  • Use current script-module APIs when they are stable for the target version; otherwise enqueue small vanilla scripts with the appropriate defer strategy.

6. Theme File Structure

Use a structure comparable to the following. Adjust only when a current WordPress API provides a better convention.

ggufruntime/
├── style.css
├── theme.json
├── functions.php
├── README.md
├── LICENSE
├── screenshot.png
├── templates/
│   ├── index.html
│   ├── front-page.html
│   ├── page.html
│   ├── single.html
│   ├── archive.html
│   ├── search.html
│   ├── 404.html
│   ├── single-gguf_doc.html
│   ├── archive-gguf_doc.html
│   ├── single-gguf_roadmap.html
│   ├── archive-gguf_roadmap.html
│   ├── single-gguf_example.html
│   └── archive-gguf_example.html
├── parts/
│   ├── header.html
│   ├── footer.html
│   ├── docs-sidebar.html
│   └── page-utility-bar.html
├── patterns/
│   ├── hero-developer.php
│   ├── runtime-boundaries.php
│   ├── architecture-overview.php
│   ├── roadmap-preview.php
│   ├── status-matrix.php
│   ├── code-command.php
│   ├── platform-matrix.php
│   ├── latest-updates.php
│   └── call-to-action.php
├── styles/
│   ├── light.json
│   ├── dark.json
│   └── high-contrast.json
├── assets/
│   ├── css/
│   │   ├── app.css
│   │   ├── editor.css
│   │   ├── print.css
│   │   └── blocks/
│   ├── js/
│   │   ├── theme-preference.js
│   │   ├── copy-code.js
│   │   ├── search-dialog.js
│   │   ├── roadmap.js
│   │   └── navigation.js
│   ├── icons/
│   ├── images/
│   └── fonts/
└── inc/
    ├── setup.php
    ├── assets.php
    ├── block-styles.php
    ├── patterns.php
    ├── editor.php
    └── integrations.php

Required block-theme files must be present, including style.css and templates/index.html. Include theme.json, a professional screenshot.png, and complete documentation.

7. Companion Plugin Structure

ggufruntime-core/
├── ggufruntime-core.php
├── composer.json
├── package.json
├── readme.txt
├── README.md
├── LICENSE
├── languages/
├── src/
│   ├── Plugin.php
│   ├── Activation.php
│   ├── Capabilities.php
│   ├── Content/
│   │   ├── PostTypes.php
│   │   ├── Taxonomies.php
│   │   ├── Meta.php
│   │   └── AdminColumns.php
│   ├── Blocks/
│   │   ├── RoadmapQueryBlock.php
│   │   ├── StatusMatrixBlock.php
│   │   ├── DocumentationTocBlock.php
│   │   └── PackageBoundaryBlock.php
│   ├── Rest/
│   │   └── SearchController.php
│   ├── Seo/
│   │   └── StructuredData.php
│   ├── Import/
│   │   ├── StarterContent.php
│   │   └── Command.php
│   └── Support/
│       ├── Date.php
│       ├── Sanitization.php
│       └── SourceVerification.php
├── blocks/
│   ├── roadmap-query/
│   ├── status-matrix/
│   ├── documentation-toc/
│   └── package-boundary/
├── tests/
│   ├── phpunit/
│   └── e2e/
└── build/

Use a PHP namespace such as GGUFRuntime\Core. Prefix any unavoidable global function, hook name, option, transient, REST namespace, capability, and meta key with ggufruntime_ or _ggufruntime_.

No public class or function may be undocumented.

8. Content Model

Use native WordPress posts and pages where appropriate. Add only the custom content types needed for consistent developer-documentation and roadmap administration.

8.1 Documentation post type

Post type: gguf_doc

Characteristics:

  • Public.
  • Hierarchical.
  • Available in REST.
  • Supports title, editor, excerpt, revisions, author, thumbnail where useful, custom fields, and page attributes.
  • Archive slug: /docs/.
  • Single slug: /docs/%postname%/.

Registered metadata:

  • _ggufruntime_summary
  • _ggufruntime_source_url
  • _ggufruntime_source_reviewed_at_utc
  • _ggufruntime_claim_scope
  • _ggufruntime_prerequisites
  • _ggufruntime_estimated_read_minutes
  • _ggufruntime_related_content_ids
  • _ggufruntime_canonical_url

8.2 Roadmap post type

Post type: gguf_roadmap

Characteristics:

  • Public.
  • Non-hierarchical.
  • Available in REST.
  • Supports title, editor, excerpt, revisions, and custom fields.
  • Archive slug: /roadmap/.

Registered metadata:

  • _ggufruntime_status: one of proposed, planned, in_progress, blocked, validated, complete, deferred, not_claimed.
  • _ggufruntime_phase_order
  • _ggufruntime_item_order
  • _ggufruntime_target_window
  • _ggufruntime_started_at_utc
  • _ggufruntime_completed_at_utc
  • _ggufruntime_dependencies
  • _ggufruntime_deliverables
  • _ggufruntime_acceptance_criteria
  • _ggufruntime_evidence_url
  • _ggufruntime_source_url
  • _ggufruntime_source_reviewed_at_utc
  • _ggufruntime_is_release_commitment: default false.

Do not represent example dates from planning documents as committed dates. Use “Now / Next / Later,” quarters, or editable target windows unless an actual release commitment exists.

8.3 Example post type

Post type: gguf_example

Characteristics:

  • Public.
  • Available in REST.
  • Archive slug: /examples/.

Registered metadata:

  • _ggufruntime_repository_url
  • _ggufruntime_download_url
  • _ggufruntime_framework
  • _ggufruntime_minimum_dotnet
  • _ggufruntime_difficulty
  • _ggufruntime_verified_at_utc
  • _ggufruntime_build_status
  • _ggufruntime_license

Do not publish a repository or download link unless it exists and was verified.

8.4 Taxonomies

Register only useful, filterable taxonomies:

  • gguf_doc_section
  • gguf_roadmap_phase
  • gguf_platform
  • gguf_runtime_package
  • gguf_topic

Use controlled terms. Provide human-readable descriptions and deterministic ordering.

8.5 News and releases

Use standard WordPress posts for updates, release notes, and engineering articles. Use categories such as:

  • Project Update
  • Architecture
  • UI Engineering
  • Runtime Evidence
  • Release Notes
  • Security

8.6 Date storage

All custom dates and timestamps must be stored and returned in UTC using ISO 8601. When displaying dates, render an explicit date and optionally the reader’s local time only when useful. Never store ambiguous local timestamps in custom metadata.

9. Information Architecture

Create the following primary navigation:

  1. Roadmap
  2. Architecture
  3. Docs
  4. Examples
  5. Status
  6. Updates
  7. About

Place search, appearance/theme toggle, GitHub, NuGet, and runtime-foundation links in utility navigation, not as competing primary menu items.

Required routes

/
/roadmap/
/architecture/
/status/
/docs/
/docs/getting-started/
/docs/gguf-inspection/
/docs/session-lifecycle/
/docs/token-streaming/
/docs/runtime-boundaries/
/docs/platform-strategy/
/examples/
/updates/
/security/
/accessibility/
/about/
/contact/
/search/

Use clean permanent links. Avoid query strings for canonical content pages. Filter state may use documented query parameters and must be reflected in the URL.

10. Visual Design Direction

Design character

The site must feel:

  • Technical.
  • Deliberate.
  • Calm.
  • High-trust.
  • Dense enough for experts but not visually cramped.
  • Modern without looking like a template marketplace theme.
  • Distinct from generic SaaS and crypto aesthetics.

Use visual references drawn from:

  • Memory maps.
  • Tensor grids.
  • Runtime dependency graphs.
  • Terminal output.
  • Typed data records.
  • State machines.
  • Hardware telemetry.
  • Structured evidence manifests.

Do not use excessive neon, glassmorphism, giant blurred gradient blobs, or decorative effects that reduce readability.

Logo concept

Create an original wordmark and compact mark using bundled SVG:

  • A simple grid/tensor or mapped-block symbol.
  • Strong silhouette at 16, 24, 32, and 48 pixels.
  • No trademarked third-party icon.
  • Accessible text alternative.
  • Monochrome-first design that works in dark and light modes.

Color system

Create a dark-first palette with an equally complete light mode. The following values are direction, not an excuse to skip contrast testing:

--gguf-color-ink-1000: #050a0f;
--gguf-color-ink-950:  #08111a;
--gguf-color-ink-900:  #0d1823;
--gguf-color-ink-850:  #12202d;
--gguf-color-line-dark: #243647;
--gguf-color-text-dark: #edf6ff;
--gguf-color-muted-dark:#9fb2c5;
--gguf-color-cyan:      #39d3e6;
--gguf-color-green:     #72e3a6;
--gguf-color-amber:     #f2c766;
--gguf-color-red:       #ff7282;
--gguf-color-blue:      #79a7ff;

--gguf-color-paper:     #f6f9fc;
--gguf-color-surface:   #ffffff;
--gguf-color-ink-light: #14202b;
--gguf-color-muted-light:#526577;
--gguf-color-line-light:#d8e1e9;

Adjust values as needed to achieve WCAG 2.2 AA contrast in all states. Status must never rely on color alone.

Typography

Use a self-hosted open-license variable sans font and a self-hosted open-license monospace font, or use a carefully designed system stack when font licensing/assets are unavailable.

Preferred direction:

  • UI and prose: Inter Variable or an equivalent neutral technical sans.
  • Code and metadata: JetBrains Mono Variable or an equivalent readable monospace.

Requirements:

  • No remote font requests.
  • font-display: swap.
  • Subset fonts when legally and technically appropriate.
  • Limit the critical font payload.
  • Use fluid type with clamp().
  • Keep normal prose between roughly 65 and 78 characters per line.
  • Minimum 16px effective body text.
  • Avoid low-contrast small uppercase text.

Layout

Use a custom fluid grid, not Bootstrap conventions.

Suggested constraints:

--gguf-layout-shell:  90rem;
--gguf-layout-wide:   78rem;
--gguf-layout-prose:  48rem;
--gguf-layout-gutter: clamp(1rem, 3vw, 2rem);
  • Use CSS Grid for shell, docs, cards, package maps, and matrices.
  • Use container queries for reusable components where beneficial.
  • Use logical properties.
  • Use minmax(), auto-fit, and auto-fill rather than many breakpoint overrides.
  • Avoid fixed heights for text-containing components.

Shape and depth

  • Thin technical borders.
  • Small and medium radii, generally 8–16px.
  • Restrained shadows.
  • Clear surface hierarchy.
  • Subtle grid or noise texture only when it does not harm performance or readability.
  • No excessive rounded “pill” treatment. Reserve pills for short statuses and filters.

11. Design Tokens and CSS Architecture

Define the design system in theme.json and mirrored CSS custom properties.

Include curated tokens for:

  • Color.
  • Gradient, only if required.
  • Font families.
  • Fluid font sizes.
  • Spacing.
  • Content and wide widths.
  • Border radii.
  • Border colors.
  • Shadows.
  • Transition durations.
  • Focus rings.
  • Z-index layers.

Disable arbitrary editor controls that would undermine the design:

  • Disable custom colors unless there is a strong editorial need.
  • Disable arbitrary gradients.
  • Curate spacing and typography controls.
  • Use content-only locking for structural patterns where current WordPress supports it.

Organize CSS with cascade layers:

@layer reset, tokens, base, layout, blocks, components, utilities, overrides;

Use low-specificity selectors with :where() where helpful. Prefix custom classes with gguf-. Do not build a large utility framework. Add only a small set of genuinely reusable utilities.

Use one main production stylesheet plus narrowly scoped block styles where this reduces unused CSS. Build tooling may use PostCSS, minification, and autoprefixing, but the browser must receive plain CSS with no runtime dependency.

12. Global Components

Build a compact sticky header with:

  • Logo and site name.
  • Primary navigation.
  • Search trigger.
  • Appearance toggle.
  • Optional GitHub and NuGet utility links.
  • Responsive mobile menu.
  • Visible keyboard focus.
  • Current-page state.
  • No layout shift during load.

The mobile navigation must be fully keyboard and screen-reader operable. Prefer native disclosure patterns or a properly implemented vanilla-JavaScript menu. Escape closes an open overlay. Focus returns to the opener.

Include:

  • Concise project description.
  • Roadmap, docs, architecture, status, security, accessibility, and contact links.
  • Runtime-foundation links.
  • Responsible disclosure link.
  • Copyright.
  • “Last content review” or build information when available.
  • No generic social icons unless the accounts are real and maintained.

Search dialog

Create an accessible search interface with:

  • Native <dialog> when supported, with a tested fallback.
  • Search input labeled visibly.
  • Keyboard navigation through suggestions.
  • Escape to close.
  • Focus management.
  • aria-live result count.
  • Debounced vanilla fetch().
  • AbortController to cancel stale requests.
  • Graceful fallback to a normal GET search form.
  • No third-party search service by default.

Code command panel

  • Visible language or shell label.
  • Copy button.
  • Copy success message in a polite live region.
  • Horizontal overflow rather than broken wrapping for commands.
  • Optional wrap toggle for long code.
  • No heavy client-side syntax-highlighting dependency.

Callouts

Create core Group-block style variations:

  • Note.
  • Evidence.
  • Warning.
  • Security.
  • Planned.
  • Not claimed.

Each callout needs an icon or text label in addition to color.

Status badge

Support these states:

  • Available now.
  • Validated.
  • In progress.
  • Planned.
  • Proposed.
  • Blocked.
  • Deferred.
  • Not claimed.

Badges must include readable text and accessible labels.

Documentation chrome

  • Breadcrumbs.
  • Sticky section navigation on wide screens.
  • Collapsible docs navigation on small screens.
  • On-page table of contents.
  • “Last reviewed” metadata.
  • Source/canonical links.
  • Previous and next links.
  • Related documentation.
  • Print-friendly layout.

13. Home Page Specification

Build a custom front-page template with the following sequence.

13.1 Hero

  • Eyebrow, H1, supporting copy, primary and secondary CTAs.
  • Runtime-foundation command panel.
  • Original visual diagram showing host UI, LocalEndpoint, model pipeline, and execution evidence—not a decorative stock image.
  • Small status note stating that roadmap content is not a release commitment.

13.2 Boundary strip

Four compact statements:

  1. Verified local GGUF intake
  2. Managed CPU path available today
  3. Explicit backend probing and fallback evidence
  4. No model downloader or provider fallback

Each statement links to the relevant status or architecture explanation.

13.3 “A UI layer built on explicit boundaries”

Explain the division between:

  • Host application.
  • LocalEndpoint.
  • GGUF parsing.
  • Tokenization.
  • LLaMA session state.
  • CPU kernels.
  • Backend selection and diagnostics.

Use a responsive architecture diagram and plain-language summary.

13.4 Roadmap preview

Show the four major UI roadmap phases:

  1. Foundational ingestion and GGUF inspection.
  2. Execution workflow and deterministic telemetry.
  3. Hardware diagnostics and evidence-based acceleration paths.
  4. Cross-platform expansion and mobile constraints.

Each phase card shows status, purpose, primary packages, and key deliverables. Link to the full roadmap.

13.5 Developer surfaces

Create a grid for:

  • GGUF Inspector.
  • Session and generation controls.
  • Token stream and cancellation.
  • Runtime telemetry.
  • Backend diagnostics.
  • Cross-platform host integration.

Clearly label planned components as planned.

13.6 Platform strategy

Show Windows, Linux, macOS, Android, and iOS. Present Avalonia as the primary implementation direction when supported by the roadmap, while separating evaluated alternatives from committed work.

Do not claim platform support for a GgufRuntime application that has not been built and tested.

13.7 Status matrix

Present three columns:

  • Works today in the runtime foundation.
  • UI roadmap work.
  • Intentionally not claimed.

This is one of the most important trust-building sections.

13.8 Latest documentation and updates

Show recent verified docs and project updates. Do not show empty placeholder cards.

13.9 Final CTA

Invite users to:

  • Explore the roadmap.
  • Review architecture.
  • Read the runtime quick start.
  • Submit a correction or project idea if a real process exists.

14. Roadmap Page Specification

The roadmap is the central product page.

Editorial framing

Start with a prominent notice:

This roadmap describes proposed and active host/UI work. It is not a package capability claim, release schedule, or delivery commitment unless an item explicitly says otherwise.

Filter controls

Provide server-rendered filters enhanced with vanilla JavaScript:

  • Phase.
  • Status.
  • Platform.
  • Runtime package.
  • Topic.

Requirements:

  • Filters work without JavaScript through GET parameters.
  • Enhanced filtering updates results and URL state without a full reload when JavaScript is available.
  • Browser back and forward work.
  • Result counts are announced accessibly.
  • Filter state can be shared by URL.
  • A clear-all control is available.

Timeline layout

Use semantic ordered content and CSS pseudo-elements:

  • One-column timeline on small screens.
  • Alternating two-column timeline on wide screens only when it remains easy to scan.
  • No JavaScript layout calculation.
  • Optional reveal animation via IntersectionObserver using only opacity and transform.
  • Disable reveal motion under prefers-reduced-motion.
  • All content must be visible when JavaScript is disabled.

Roadmap item anatomy

Every item displays:

  • Phase.
  • Status.
  • Title.
  • Concise objective.
  • Current state.
  • Proposed deliverables.
  • Dependencies.
  • Target platforms.
  • Related runtime packages.
  • Acceptance criteria.
  • Evidence or source link.
  • Last reviewed UTC date.
  • Explicit release-commitment value, normally “No.”

Seed phases

Phase 1 — Foundational ingestion and binary inspection

Cover:

  • Trusted file selection.
  • SHA-256 and byte-count verification.
  • GGUF header and metadata inspection.
  • Tensor catalog views.
  • Quantization and storage metadata.
  • Tokenizer and chat-template visibility.
  • Load-risk and memory-estimate presentation.

Phase 2 — Execution workflow and deterministic telemetry

Cover:

  • LocalEndpoint integration.
  • Model and session lifecycle.
  • Bounded generation.
  • Cancellation.
  • Incremental token presentation when the actual API supports it.
  • Time-to-first-token and tokens-per-second measurement only with a defined method.
  • Memory and session-state diagnostics.
  • Error presentation that preserves technical detail.

Phase 3 — Hardware diagnostics and acceleration evidence

Cover:

  • CPU capability display.
  • Managed CPU baseline.
  • Backend registration and probe results.
  • Visible fallback state.
  • Required-backend fail-closed behavior.
  • Capability declarations versus execution proof.
  • Reproducible performance-evidence requirements.

Do not imply working CUDA, DirectML, Vulkan, ROCm, or Metal inference merely because registration packages exist.

Phase 4 — Cross-platform expansion and mobile constraints

Cover:

  • Desktop layout parity.
  • Native file-picker integration.
  • Scoped storage.
  • Touch interaction.
  • Thermal and battery awareness.
  • Mobile memory pressure.
  • Packaging and signing.
  • Device testing.
  • Accessibility parity.

Roadmap summary

Add a small data summary showing counts by status and phase. Derive counts from the database. Cache expensive aggregates and invalidate them when roadmap posts or terms change.

15. Architecture Page Specification

Create a high-density technical page with these sections:

  1. System boundary overview.
  2. Package dependency map.
  3. Host ownership boundary.
  4. Verified model-load path.
  5. Generation lifecycle.
  6. Session and resource ownership.
  7. Backend registration, probing, selection, fallback, and execution-proof distinction.
  8. UI integration boundary.
  9. Cross-platform host strategy.
  10. Current claims and non-claims.

Architecture visualization

Build the primary diagram with semantic HTML and CSS, not an inaccessible image-only chart.

Recommended flow:

Host application and UI
        ↓
UAIX.LmRuntime.LocalEndpoint
        ↓
Model pipeline: GGUF → Tokenization → Tensors/Kernels → LLaMA session → Sampling
        +
Backend control plane: registry → declaration → probe → selection → evidence

Show that the host owns:

  • Model acquisition and licensing.
  • File paths and trusted roots.
  • Hashes and byte counts.
  • Prompt construction.
  • UI.
  • Persistence.
  • Network features.
  • Commands and tools.
  • Cancellation.
  • Audit.
  • Deployment support terms.

Add source links to authoritative runtime pages. Do not hard-code a package count unless it is fetched from a maintained source and verified.

16. Status Page Specification

Create a status page with four sections:

Available now

Only list capabilities confirmed by current runtime documentation and current public project evidence.

UI roadmap

List proposed or active GgufRuntime UI work separately.

Evidence required

Explain that package publication does not prove every model, tokenizer, quantization, context length, operating system, processor, memory condition, or workload.

Not claimed

Include at minimum:

  • Universal GGUF support.
  • Benchmark leadership without reproducible evidence.
  • Hosted cloud service.
  • Automatic model download.
  • Provider API fallback.
  • GPU execution from package installation alone.
  • Production or safety certification.
  • Autonomous authority from model output or memory.

Use concise, unambiguous language.

17. Documentation Experience

Docs landing page

Organize content by task rather than by internal file structure:

  • Start here.
  • Understand the boundaries.
  • Inspect a GGUF artifact.
  • Load a verified model.
  • Manage sessions.
  • Generate and cancel.
  • Stream or observe output, only if supported.
  • Diagnose backends.
  • Build a desktop host.
  • Plan mobile storage and resource limits.
  • Review evidence and security.

Documentation page requirements

  • Single H1.
  • Summary paragraph.
  • Prerequisites.
  • Stable anchor links.
  • Table of contents.
  • Source and review metadata.
  • Complete code samples.
  • Copy controls.
  • Warnings near risky or easily misunderstood operations.
  • Related docs.
  • Previous/next navigation.
  • Print support.

Code sample rules

  • Verify every type, namespace, method, property, and overload against current public API documentation or source.
  • Never publish invented convenience APIs.
  • Do not copy speculative GenerateAsync, StreamAsync, or GPU examples unless the API actually exposes them.
  • Use CancellationToken where the real API supports cancellation.
  • Dispose models and sessions in the documented order.
  • Use comments and XML descriptions where code defines methods.
  • For C# sample model classes, include [Display(Name = "...")] attributes on properties and omit Id, ID, or Identifier suffixes from display labels.
  • Use version-free package installation commands.
  • State that users must obtain, license, trust, and verify model files themselves.

18. Examples Page

Build a filterable example catalog using gguf_example.

Filters:

  • Platform.
  • UI framework.
  • Runtime package.
  • Difficulty.
  • Build status.

Example cards show:

  • Title.
  • Purpose.
  • Framework.
  • Platform.
  • Runtime packages.
  • Minimum .NET target.
  • Build status.
  • Last verified UTC date.
  • Repository and license when real.

Seed only examples that exist. If examples are planned but not available, place them on the roadmap rather than creating dead catalog entries.

Implement privacy-preserving site search.

Baseline

  • Standard WordPress search results must work without JavaScript.
  • Include documentation, roadmap, examples, posts, and pages.
  • Exclude internal-only content.
  • Search-result cards show content type, title, excerpt, relevant taxonomy terms, and last reviewed date where applicable.

Enhanced suggestions

Create a read-only REST endpoint such as:

/wp-json/ggufruntime/v1/search

Requirements:

  • Public GET only.
  • Required permission_callback.
  • Sanitize query and filter values.
  • Enforce a minimum query length.
  • Limit results.
  • Return only required fields.
  • Do not return private posts, raw meta, author email, internal notes, or unrestricted HTML.
  • Cache safe repeated queries briefly.
  • Set appropriate cache headers where hosting permits.
  • Use vanilla fetch() and AbortController.
  • Use text nodes rather than unsafe innerHTML for returned content.

Do not require Algolia or another external search vendor for launch. Architect an optional adapter only if there is a documented future need.

20. Interactive Roadmap and UI Behavior

Write small, focused vanilla modules.

theme-preference.js

  • Respect prefers-color-scheme by default.
  • Support light, dark, and system preferences.
  • Store only the preference in localStorage.
  • Update color-scheme and control state.
  • Avoid a severe flash of the wrong theme.
  • Work under a strict Content Security Policy without unsafe inline event handlers.

copy-code.js

  • Use event delegation.
  • Use navigator.clipboard when available.
  • Provide a safe fallback.
  • Announce success or failure.
  • Never mutate code content.

search-dialog.js

  • Open, close, and manage focus correctly.
  • Debounce requests.
  • Abort stale requests.
  • Handle empty, loading, error, and no-result states.
  • Preserve normal form submission.

roadmap.js

  • Enhance filter forms.
  • Update URL parameters.
  • Update result counts.
  • Support back/forward navigation.
  • Apply optional reveal states.
  • Respect reduced motion.
  • Do not hide content before initialization.

Use only if core navigation behavior does not satisfy the design. Keep it small and accessible.

No module may create an unnecessary global. No module may use eval, new Function, inline event attributes, or untrusted HTML injection.

21. Block Editor Experience

The editor must closely resemble the frontend.

Core-block-first rule

Use core blocks and patterns whenever they can represent the content cleanly. Add custom blocks only for data-driven behavior that core blocks cannot provide.

Core block styles

Add style variations for:

  • Group callouts.
  • Technical cards.
  • Code command panels.
  • Compact metadata lists.
  • Status tables.
  • Feature grids.

Dynamic blocks in the companion plugin

Implement only these initially unless another is demonstrably required:

  1. ggufruntime/roadmap-query
  2. ggufruntime/status-matrix
  3. ggufruntime/documentation-toc
  4. ggufruntime/package-boundary

Use block.json. Prefer server-side rendering for query/data blocks. Load frontend assets only when the block is present. Editor code may use official WordPress block packages, but no React bundle should be required on the public frontend.

Patterns

Provide polished, locked or content-only patterns for:

  • Home hero.
  • Runtime boundary strip.
  • Architecture overview.
  • Roadmap preview.
  • Status matrix.
  • Docs introduction.
  • Code command.
  • Platform matrix.
  • CTA.

Editors should be able to update copy and links without rebuilding the theme, while structural design remains hard to break accidentally.

22. Admin Experience

Create a focused editorial experience rather than exposing raw meta keys.

Roadmap admin

  • Status selector.
  • Phase selector.
  • Platform and package terms.
  • Target window.
  • Dependencies.
  • Deliverables.
  • Acceptance criteria.
  • Evidence URL.
  • Source URL.
  • Last reviewed UTC timestamp.
  • Release-commitment checkbox with default false and explanatory help text.

Add admin columns for phase, status, target window, platforms, packages, and last reviewed date. Add filters and deterministic ordering.

Documentation admin

  • Section.
  • Summary.
  • Prerequisites.
  • Claim scope.
  • Source URL.
  • Canonical URL.
  • Last reviewed UTC timestamp.
  • Related docs.

Starter content

Create an idempotent WP-CLI command such as:

wp ggufruntime import-starter-content

The command must:

  • Create required pages, terms, and seed roadmap items.
  • Update existing matching content instead of duplicating it.
  • Support --dry-run.
  • Support --force for intentional updates.
  • Never delete unrelated content.
  • Print a clear summary.

Do not automatically delete “Hello world!” or “Sample Page” on theme activation. Provide a documented cleanup command or setup checklist so production content is never removed unexpectedly.

23. Accessibility Requirements

Meet WCAG 2.2 Level AA across templates and interactions.

Mandatory requirements:

  • Skip link.
  • Correct landmarks.
  • Exactly one primary <main> landmark.
  • Logical heading hierarchy.
  • Visible focus indicators using :focus-visible.
  • Keyboard-operable navigation, search, filters, dialogs, copy controls, disclosures, and theme switcher.
  • Correct form labels and error descriptions.
  • Sufficient text, border, icon, and focus contrast.
  • Touch targets sized appropriately.
  • No information conveyed by color alone.
  • Reduced-motion handling.
  • No forced animation.
  • Accessible name for every icon-only control.
  • Decorative SVGs hidden from assistive technology.
  • Data tables with correct headers and responsive overflow.
  • Code blocks readable by screen readers and keyboard users.
  • Live regions used sparingly and correctly.
  • Focus restored after dialogs close.
  • No positive tabindex.
  • Native semantics preferred over redundant ARIA.
  • Zoom to 200% without loss of content or function.
  • Reflow at 320 CSS pixels.
  • Light, dark, and high-contrast modes tested.

Run automated axe checks and manual keyboard/screen-reader checks. Automated tools do not replace manual testing.

24. Performance Requirements

The site must be extremely fast on ordinary hosting and mobile hardware.

Asset budgets

For a representative uncached public page, target:

  • Global first-party CSS: at or below 35 KB gzip.
  • Global first-party JavaScript: at or below 20 KB gzip.
  • Page-specific JavaScript: generally at or below 10 KB gzip per feature page.
  • No frontend jQuery or Bootstrap payload.
  • No render-blocking third-party scripts.
  • No unbounded font payload.

Treat these as budgets, not reasons to remove accessibility or required functionality. Document any justified exception.

Runtime behavior

  • Enqueue assets only where needed.
  • Do not load all block CSS globally when per-block loading is practical.
  • Include image dimensions.
  • Use WordPress responsive image APIs.
  • Prefer SVG for diagrams and icons, raster images only when appropriate.
  • Use WebP or AVIF derivatives where supported.
  • Lazy-load below-the-fold media.
  • Do not lazy-load the probable LCP image.
  • Use appropriate fetchpriority only after measurement.
  • Avoid layout shifts from fonts, images, banners, or code controls.
  • Cache expensive roadmap aggregates.
  • Avoid N+1 queries.
  • Prime term/meta caches for custom queries.
  • Do not autoload large options.
  • Avoid remote HTTP calls during normal page rendering.
  • Use object-cache-friendly query patterns.

Performance targets

On representative production-like pages, target:

  • Lighthouse Performance: 95 or higher.
  • Lighthouse Accessibility: 100 where practical, never below 95 without a documented reason.
  • Lighthouse Best Practices: 95 or higher.
  • Lighthouse SEO: 95 or higher.
  • LCP at or below 2.5 seconds under a defined mobile test profile.
  • CLS at or below 0.1.
  • INP at or below 200 milliseconds where measurable.

Record test environment and results. Never publish benchmark claims without retained methodology and evidence.

25. Security Requirements

  • Escape output at the point of output using the correct context.
  • Sanitize all inputs.
  • Validate values against allowlists.
  • Use nonces for state-changing admin actions.
  • Check capabilities before every privileged action.
  • Use permission_callback for every REST route.
  • Use $wpdb->prepare() only when custom SQL is unavoidable.
  • Prefer WordPress APIs over custom SQL.
  • Avoid exposing private meta in REST responses.
  • Never use unserialize() on untrusted input.
  • Never use eval, dynamic PHP includes based on user input, or remote code execution patterns.
  • Do not allow untrusted SVG uploads merely because the theme uses bundled SVGs.
  • Use trusted bundled SVG assets with sanitized markup.
  • Avoid inline event handlers.
  • Keep public pages compatible with a strict CSP.
  • Provide recommended server-layer security headers in deployment documentation rather than pretending a theme alone can secure HTTP headers.
  • Keep secrets, internal hashes, candidate manifests, private package ledgers, and deployment credentials out of public content and theme files.
  • Add a visible responsible-disclosure path and support /.well-known/security.txt at the deployment layer.
  • Do not add tracking pixels, fingerprinting, external fonts, or third-party analytics by default.
  • Never upload user GGUF models to the website. The site is documentation and roadmap infrastructure, not a model-processing service.

26. Privacy Requirements

Default to data minimization.

  • No analytics by default.
  • No ad network.
  • No social-media tracking widget.
  • No embedded third-party video on initial page load.
  • No remote font service.
  • No unnecessary cookies.
  • Appearance preference may use localStorage.
  • Search queries remain local to the WordPress site.
  • If analytics is later enabled, require a documented privacy review and use a privacy-preserving option.
  • Contact forms, if added, must have a clear retention policy, spam control that does not silently add invasive tracking, and server-side validation.

27. SEO and Structured Data

Build strong technical SEO without turning the theme into an SEO-plugin replacement.

Core requirements

  • Correct document titles.
  • One H1 per page.
  • Semantic heading hierarchy.
  • Meta descriptions from curated fields or excerpts.
  • Canonical URLs.
  • Open Graph and social metadata with graceful integration when a recognized SEO plugin is active.
  • WordPress core XML sitemaps.
  • Clean archives and pagination.
  • Descriptive link text.
  • Meaningful image alt text.
  • No keyword meta tag.
  • No hidden text.
  • No doorway or duplicate pages.

Structured data

The companion plugin may emit minimal JSON-LD when no dedicated SEO plugin owns it:

  • Organization or Person as accurately configured.
  • WebSite with search action when valid.
  • BreadcrumbList.
  • TechArticle for documentation.
  • SoftwareSourceCode for verified examples.
  • ItemList for roadmap archives.

Do not emit unsupported SoftwareApplication or rating data. Avoid duplicate schema when an SEO plugin is active.

Source attribution

Technical pages should include a visible source panel with:

  • Source name.
  • Source URL.
  • Last reviewed UTC date.
  • Claim scope.
  • Canonical source when content is derived from another site.

28. Content Style Guide

Tone

  • Precise.
  • Direct.
  • Evidence-oriented.
  • Developer-first.
  • No marketing hyperbole.
  • No vague superlatives.
  • No unsupported comparisons.
  • No anthropomorphic AI claims.

Preferred language

Use:

  • “available,” “validated,” “represented by the API,” “proposed,” “planned,” “not claimed,” “requires host validation,” and “evidence.”

Avoid unless demonstrated:

  • “blazing fast,” “production-ready,” “universal,” “seamless,” “zero overhead,” “instant,” “best,” “fully supported,” “native GPU inference,” and “works everywhere.”

Terminology

  • Say “GGUF format” without inventing or asserting an acronym expansion unless the authoritative source explicitly defines it.
  • Distinguish the UAIX.LmRuntime runtime foundation from the proposed GgufRuntime UI layer.
  • Distinguish package installation, declared compatibility, successful probing, selected backend, and executed inference evidence.
  • Distinguish desktop roadmap intent from tested mobile support.
  • Use “local” rather than “offline” when the host application may include unrelated network features.

29. Seed Content Plan

Create polished starter content based on the supplied documents, rewritten under the claims policy.

Pages

  • Home.
  • Roadmap.
  • Architecture.
  • Status.
  • Security.
  • Accessibility.
  • About.
  • Contact.

Initial documentation

  1. Getting Started.
  2. Runtime and Host Boundaries.
  3. Verified GGUF Intake.
  4. GGUF Metadata and Tensor Inspection.
  5. Model and Session Lifecycle.
  6. Bounded Generation and Cancellation.
  7. Token Output and UI Threading.
  8. Backend Registration, Probing, and Fallback.
  9. Desktop UI Strategy.
  10. Mobile Storage and Resource Constraints.
  11. Evidence and Benchmark Discipline.
  12. Model Licensing and Trust Checklist.

Initial roadmap items

Create granular items for all four phases. Each item must have status, phase, objective, dependencies, deliverables, acceptance criteria, source, and reviewed date.

Use “Proposed” or “Planned” by default unless implementation evidence is supplied.

Initial update post

Publish a launch post explaining:

  • The site’s purpose.
  • The difference between runtime foundation and UI roadmap.
  • Current claim boundaries.
  • How developers can submit corrections or contributions.

Do not fabricate a release announcement.

30. Responsive Behavior

Small screens

  • Single-column content.
  • Collapsible docs navigation.
  • Full-width roadmap cards.
  • Tables scroll horizontally with visible affordance.
  • Code blocks scroll without forcing page width.
  • Filters stack logically.
  • Header remains compact.
  • Touch targets remain usable.

Medium screens

  • Two-column card grids when content permits.
  • Docs sidebar may become an off-canvas panel.
  • Architecture diagrams simplify without hiding information.

Large screens

  • Docs layout uses sidebar, content, and optional on-page TOC.
  • Roadmap may alternate around a center line.
  • Architecture maps use a wide technical grid.
  • Avoid excessive empty space and oversized headings.

Use content-driven breakpoints, not device labels or Bootstrap breakpoints.

31. Testing and Quality Gates

Static analysis and linting

  • WordPress Coding Standards through PHPCS.
  • PHP compatibility checks for the declared PHP matrix.
  • PHPStan or an equivalent static analyzer configured realistically for WordPress.
  • ESLint using current WordPress-aligned rules.
  • Stylelint using WordPress-aligned CSS rules.
  • JSON schema validation for theme.json and block metadata.
  • Markdown linting for project docs.
  • Link checking for internal and external links.

Automated PHP tests

Test:

  • Post-type registration.
  • Taxonomy registration.
  • Meta schema, sanitization, authorization, and REST exposure.
  • Roadmap queries and ordering.
  • Status counts and cache invalidation.
  • REST search permissions, sanitization, limits, and private-content exclusion.
  • Starter-content importer idempotency.
  • Structured-data output and SEO-plugin coexistence.
  • Theme behavior when companion plugin is inactive.

End-to-end tests

Use Playwright or an equivalent current browser test runner.

Test:

  • Header and mobile navigation.
  • Keyboard navigation.
  • Search dialog and fallback search.
  • Roadmap filters with and without JavaScript.
  • URL state and browser history.
  • Copy buttons.
  • Theme preference.
  • Docs navigation and TOC.
  • 404 page.
  • Light, dark, and reduced-motion modes.
  • No console errors.
  • No jQuery or Bootstrap resources.

Accessibility tests

  • Axe automated scan on every primary template.
  • Manual keyboard pass.
  • Screen-reader spot checks.
  • 200% zoom.
  • 320px reflow.
  • Contrast validation.
  • Reduced-motion validation.
  • High-contrast mode validation.

Visual regression

Capture stable screenshots for:

  • Home.
  • Roadmap.
  • Architecture.
  • Docs article.
  • Search results.
  • Mobile navigation.
  • Dark and light mode.

Browser matrix

Test current and previous stable versions where practical:

  • Chromium-based browsers.
  • Firefox.
  • Safari/WebKit.
  • iOS Safari.
  • Android Chrome.

32. Development Environment and CI

Provide a reproducible local environment using wp-env, DDEV, Docker Compose, or another documented WordPress development setup.

Create CI workflows that:

  1. Install PHP and Node dependencies.
  2. Validate coding standards.
  3. Run PHP unit tests.
  4. Build editor and frontend assets.
  5. Validate theme and block metadata.
  6. Start a disposable WordPress test environment.
  7. Import starter content.
  8. Run end-to-end and accessibility tests.
  9. Audit asset sizes.
  10. Confirm no jQuery or Bootstrap references in project output.
  11. Build clean theme and plugin ZIP files.
  12. Upload build artifacts.

Do not include node_modules, test caches, source maps containing private paths, local environment files, secrets, or development-only dependencies in release ZIPs.

33. Deployment Requirements

Never develop directly against production without a staging workflow.

Provide:

  • Backup checklist.
  • Staging deployment procedure.
  • Theme and plugin installation order.
  • Starter-content import procedure.
  • Menu assignment procedure.
  • Front-page and posts-page configuration.
  • Permalink refresh procedure.
  • Cache purge procedure.
  • Production smoke-test checklist.
  • Rollback steps.
  • Instructions to remove default starter content only after review.
  • Server-layer HTTPS and security-header recommendations.
  • Recommended caching and image-processing configuration.

Do not hard-code environment-specific URLs. Use WordPress URL functions and configuration.

34. Deliverables

Deliver all of the following:

  1. Complete ggufruntime theme source.
  2. Complete ggufruntime-core plugin source.
  3. Production build assets.
  4. Installable theme ZIP.
  5. Installable plugin ZIP.
  6. Starter-content importer.
  7. Seed content data.
  8. Theme screenshot.
  9. Original SVG logo and icon set.
  10. Local development instructions.
  11. Deployment instructions.
  12. Content-editor guide.
  13. Architecture decision record explaining theme/plugin separation.
  14. Design-token reference.
  15. Accessibility statement and test results.
  16. Performance report with environment and asset sizes.
  17. Security checklist.
  18. Test suite and CI configuration.
  19. Changelog.
  20. Third-party license inventory.

Do not provide placeholders instead of these deliverables.

35. Definition of Done

The project is complete only when all conditions below are met.

Product

  • The default WordPress appearance is fully replaced.
  • The site clearly explains its purpose within the first viewport.
  • Runtime foundation, UI roadmap, and non-claims are visibly separated.
  • Home, roadmap, architecture, docs, examples, status, updates, and policy pages are complete.
  • No dead links or placeholder content remain.

Design

  • The visual identity is original and developer-focused.
  • Dark, light, and high-contrast experiences are coherent.
  • Mobile, tablet, laptop, and large-screen layouts are intentional.
  • The editor approximates frontend styles.
  • No generic page-builder visual patterns remain.

Engineering

  • No Bootstrap.
  • No jQuery in project source or public-page dependencies.
  • No frontend framework.
  • No remote font or script dependency.
  • Theme and durable functionality are correctly separated.
  • All dynamic output is escaped.
  • All input is sanitized and authorized.
  • REST routes are permissioned and limited.
  • Scripts are small, modular, and progressively enhanced.
  • Public content renders without JavaScript.

Accessibility

  • Primary templates pass automated checks.
  • Keyboard-only operation is complete.
  • Focus behavior is correct.
  • Contrast meets requirements.
  • Reduced motion works.
  • No critical WCAG 2.2 AA issue remains.

Performance

  • Asset budgets are met or exceptions are documented.
  • No unnecessary global assets are loaded.
  • Representative Lighthouse targets are met.
  • No major layout shift occurs.
  • Images and fonts are optimized.

Content integrity

  • Every capability claim is sourced.
  • Every roadmap item is clearly labeled.
  • Speculative APIs and benchmarks are absent.
  • Version-free installation policy is followed.
  • Dates are explicit and custom timestamps are UTC.
  • No package count or support matrix is published without verification.

Operations

  • CI passes.
  • Release ZIPs install cleanly.
  • Staging smoke test passes.
  • Backup and rollback procedures are documented.
  • No secrets or private project material are present in public artifacts.

36. Required Execution Behavior

  • Begin by auditing the current repository, WordPress installation assumptions, supplied source documents, and current authoritative runtime pages.
  • Record assumptions and conflicts before coding.
  • Produce a concise architecture plan and final file tree.
  • Then implement the complete theme and companion plugin.
  • Use complete, production-ready code rather than pseudocode.
  • Do not omit error handling, sanitization, escaping, documentation, or tests.
  • Do not substitute premium plugins or SaaS services for required functionality.
  • Do not weaken the no-Bootstrap/no-jQuery constraint.
  • Do not stop after generating the home page.
  • Do not fabricate content to make the site look complete.
  • When a factual value is unknown, create an editable field, label the state honestly, or omit the claim.
  • Make reasonable implementation decisions without repeatedly asking for aesthetic preferences.
  • Document every material assumption in the final handoff.

Final handoff format

Provide:

  1. Summary of what was built.
  2. Architecture and dependency map.
  3. File tree.
  4. Installation and setup commands.
  5. Content-import command.
  6. Test commands and results.
  7. Accessibility results.
  8. Performance results and asset sizes.
  9. Known limitations.
  10. Claim/source review notes.
  11. Links or paths to the theme ZIP and plugin ZIP.

The final result must be a deployable custom WordPress developer portal, not merely a design concept.