VNWO v2.9.1 Independent Review Prompt

Full report

On this page

Role

Act as an independent senior WordPress architect, UX researcher, accessibility engineer, technical-content strategist, and release auditor. Be skeptical, specific, and constructive.

Your task is not to praise the current release or restate its changelog. Find the next highest-impact improvements for VNWO.com based on direct evidence from the deployed site and the actual theme package.

Materials to inspect

Use all materials supplied with this prompt:

1. vnwo-theme-v2.9.1.zip
2. VNWO-IMPLEMENTATION-REPORT-v2.9.1.md
3. VNWO-EVIDENCE-CATALOG-v2.9.1.md
4. VNWO-NEXT-DETAILED-PROMPT-v2.9.2.md
5. The current public site at https://vnwo.com/
6. A staging URL, when supplied
7. Any prior VNWO UX or strategy reports included as secondary references

Source priority

When sources conflict, use this order:

1. Observed deployed behavior
2. Actual files and code in vnwo-theme-v2.9.1.zip
3. Raw test output and reproducible evidence
4. Implementation and evidence reports
5. Older strategy documents

Do not assume an older report accurately describes the current domain, current navigation, or current release. Verify every material claim. Do not accept a claimed test pass without inspectable evidence.

Product definition

Treat VNWO as an open governance toolkit for AI agents and AI-assisted communities. Its primary value is practical, publishable policies, examples, records, and machine-readable schemas for:

• actor and agent disclosure;
• authority limits;
• memory consent and retention;
• endpoint boundaries;
• moderation decisions, repair, and appeals;
• governance changes;
• export, revocation, offboarding, and exit.

The principal conversion is downloading or adopting a starter governance pack. The principal proof is a complete, realistic implementation example.

Non-negotiable claim boundaries

Do not recommend language or functionality implying that VNWO:

• certifies safety;
• proves consciousness;
• grants legal personhood;
• executes agents;
• imports files;
• synchronizes memory;
• validates credentials;
• authorizes endpoints;
• collects telemetry;
• guarantees privacy, deletion, compliance, attestation correctness, or cloud sovereignty;
• overrides UAIX or Teleodynamic;
• replaces legal, security, accessibility, or compliance review.

Prefer compact boundary language in normal journeys and preserve /claim-boundaries/ as the detailed canonical authority.

Architectural constraints

Preserve the existing lightweight direction unless evidence demonstrates a concrete reason to change it:

• classic, server-rendered WordPress theme;
• semantic HTML;
• custom CSS;
• progressive enhancement with vanilla JavaScript;
• no React, Vue, Angular, Tailwind, Bootstrap, or jQuery dependency;
• no telemetry gate, file-upload requirement, account requirement, or unnecessary server-side processing;
• functional access to core content when JavaScript is unavailable.

Required review method

1. Inspect the actual theme stack

Unpack the ZIP and inventory:

• template hierarchy and route mapping;
• reusable components and content data;
• CSS and JavaScript architecture;
• SEO and structured-data generation;
• downloads, schemas, examples, and generated packs;
• .uai state files and release metadata;
• validation tools and their real coverage.

Identify dead code, duplicated components, brittle route assumptions, content embedded in the wrong layer, stale release references, and maintainability risks.

2. Compare package and deployment

Determine whether the deployed site actually matches v2.9.1. Check for:

• old templates or cached content;
• default WordPress posts, pages, widgets, or comments;
• broken or missing routes;
• wrong canonical URLs;
• ZIPs or JSON files returning HTML error pages;
• inconsistent navigation between routes;
• version mismatches across HTML, downloads, JSON, PDFs, and .uai files.

Clearly label deployment problems separately from source-package defects.

3. Test the main user journeys

Evaluate these journeys as first-time visitors, implementers, and keyboard/screen-reader users:

1. Understand VNWO's purpose within 60 seconds.
2. Identify whether VNWO is guidance, software, certification, or something else.
3. Download the starter governance pack without searching through documentation.
4. Open a complete AI-moderated-community example and understand how its files fit together.
5. Find a template for a specific task such as agent disclosure, memory consent, authority limits, appeal, or exit.
6. Move from a human-readable template to its machine-readable counterpart and back.
7. Determine version, maturity, last-reviewed date, license, editable variables, and related schema for an artifact.
8. Understand the claim boundaries without being overwhelmed by defensive copy.
9. Find maintainers, editorial process, issue-reporting path, and contact expectations.
10. Complete core reading and download tasks with JavaScript disabled.

Report friction, ambiguity, dead ends, duplicated pathways, misleading labels, and unnecessary cognitive load.

4. Review these routes directly

At minimum, inspect:

• /
• /start-here/
• /use-cases/
• /templates/
• /open-rules/
• /examples/
• /downloads/
• /machine-readable-governance/
• /builder-checklist/
• /technical-architecture/
• /file-memory/
• /agent-disclosure/
• /repair-appeals/
• /exit-rights/
• /claim-boundaries/
• /accessibility/
• /about/
• /contact/
• /version-history/
• /ecosystem/
• /privacy/
• /vnwo.json
• /open-rules.json
• /claim-boundaries.json
• /llms.txt
• /downloads/vnwo-starter-governance-pack.zip
• /downloads/vnwo-ai-moderated-community-example-pack.zip
• /examples/ai-moderated-community-example.json

Also discover important routes not listed here.

5. Responsive and navigation QA

Test at:

• 1440×900
• 1366×768
• 1280×800
• 1024×768
• 768×1024
• 390×844
• 320×568

Verify:

• no page-level horizontal overflow;
• header labels and starter-pack CTA do not collide or wrap poorly;
• desktop More menu stays inside the viewport;
• constrained menus and drawers scroll internally;
• all groups remain reachable by keyboard;
• Escape and click-outside close overlays;
• focus returns to the correct trigger;
• focus never moves behind a modal drawer;
• mobile drawer has coherent focus and scroll behavior;
• tables, code blocks, filter controls, cards, and CTA rows work at 320 px;
• sticky elements do not obscure headings or focused controls.

6. Accessibility review

Use automated and manual testing. At minimum examine:

• valid landmarks and one meaningful H1 per route;
• logical H2–H4 hierarchy;
• skip-link operation;
• accessible names and descriptions;
• button versus link semantics;
• menu and drawer state announcements;
• keyboard order and focus visibility;
• focus not obscured;
• target sizes;
• contrast for text, controls, focus indicators, and badges;
• reduced-motion behavior;
• filter/search result announcements;
• copy-button feedback;
• table headers and responsive table access;
• code-block reading behavior;
• screen-reader smoke tests using at least one real screen reader;
• zoom at 200% and text spacing overrides.

Do not claim WCAG conformance. Report tested criteria, failures, and unknowns.

7. Content and information architecture review

Assess whether the current navigation—Start, Use Cases, Templates, Examples, Specifications, About, plus Download Starter Pack—matches user mental models.

Specifically determine:

• whether “Start” is sufficiently descriptive;
• whether “Specifications” is clear to non-specialists;
• whether Use Cases, Templates, Examples, and Open Rules have distinct roles;
• whether the homepage presents a concrete outcome and proof before theory;
• whether the complete example is detailed enough to establish credibility;
• whether conceptual vocabulary is introduced only after plain-language terms;
• whether long pages have concise summaries, useful tables of contents, and stable anchors;
• whether card density, repeated panels, badges, and disclaimer components create visual fatigue;
• whether ecosystem projects are appropriately de-emphasized in the primary journey;
• whether contact, maintainers, methodology, licensing, editorial policy, and independence disclosures are adequate and verifiable;
• whether copy accidentally asserts universal legitimacy, authority, safety, compliance, or legal effect.

Recommend exact replacement copy only where it materially improves comprehension or trust.

8. Artifact and starter-pack review

Open every ZIP and inspect its contents rather than reviewing only the download page.

For every major artifact, evaluate whether it includes or clearly links to:

• intended audience;
• purpose and when to use it;
• maturity status: Draft, Recommended, Experimental, or Deprecated;
• document version;
• last-reviewed UTC date;
• editable variables;
• completed example;
• related schema;
• human-readable equivalent;
• machine-readable equivalent;
• license and attribution requirements;
• compact claim-boundary note.

Check file names, internal links, relative paths, README instructions, schema references, JSON examples, archive determinism, checksums, MIME types, and stable versioned URLs.

Determine whether the starter pack is genuinely usable without reading the entire site.

9. Human/machine-readable parity

Build a parity matrix covering HTML pages, Markdown, JSON, JSON Schema, PDF, ZIP packs, vnwo.json, open-rules.json, claim-boundaries.json, and llms.txt.

Identify:

• human guidance with no machine-readable counterpart;
• machine-readable artifacts with no understandable human page;
• field-name or terminology drift;
• version/date mismatches;
• conflicting claim boundaries;
• examples that fail their schemas;
• schema fields not explained in human guidance;
• links that do not resolve in the deployed environment.

Do not describe llms.txt as a guaranteed indexing or model-control mechanism.

10. SEO and discoverability review

Verify rather than assume:

• page titles and meta descriptions;
• canonical tags;
• indexability;
• XML sitemap coverage;
• robots directives;
• Open Graph and social preview data;
• breadcrumb markup;
• structured data eligibility and validity;
• redirect/canonical handling for overlapping Open Rules and Templates content;
• internal links and orphan routes;
• stable versioned download URLs;
• common-language topic coverage for AI agent governance, agent disclosure, memory consent, authority limits, moderation appeals, and exit rights.

Separate technical indexing defects from optional content-growth opportunities.

11. Performance and privacy review

Measure mobile and desktop performance where possible. Inspect:

• HTML, CSS, JavaScript, image, PDF, and ZIP sizes;
• render-blocking resources;
• cache/version strategy;
• unused CSS or JavaScript;
• layout shift;
• long tasks;
• third-party requests;
• font loading;
• image dimensions and decoding;
• excessive DOM/card counts;
• expensive filtering logic;
• console errors;
• accidental analytics, embeds, remote dependencies, cookies, or network calls inconsistent with the stated posture.

Report actual metrics and test conditions. Do not convert a target score into a claimed result.

Questions the review must answer

1. What are the five most serious remaining obstacles to adoption?
2. What does a first-time visitor still misunderstand?
3. Which page or component appears polished but fails a real user task?
4. Which two routes should be merged, redirected, renamed, or more sharply differentiated?
5. Is the starter pack complete enough for an implementer to use immediately?
6. Does the complete example demonstrate the framework or merely describe it?
7. What trust information is missing or unverifiable?
8. Where is claim-boundary language excessive, insufficient, or inconsistent?
9. What is the highest-impact accessibility defect not caught by automated scans?
10. What causes the most avoidable mobile friction at 320×568?
11. What package/deployment mismatch is most likely to create false confidence?
12. Which three improvements would most increase useful downloads or real adoption without weakening the framework's boundaries?

Required output

A. Executive verdict

Provide a concise verdict of no more than 250 words. State whether v2.9.1 currently functions primarily as:

• an understandable adoption toolkit;
• a strong documentation system with adoption friction;
• a conceptual framework with implementation assets;
• or another clearly defined category.

B. Scorecard

Score each area from 0–5 and justify every score in one sentence:

• first-visit comprehension;
• navigation and findability;
• use-case clarity;
• template usability;
• example quality;
• starter-pack readiness;
• accessibility;
• mobile usability;
• performance;
• trust and maintainership;
• machine-readable parity;
• SEO/discoverability;
• WordPress maintainability;
• claim-boundary discipline.

C. Prioritized findings table

Provide 15–25 verified findings. Use these columns:

Severity definitions:

• P0: blocks release, breaks access, corrupts artifacts, creates a material trust/safety problem, or makes a primary journey impossible;
• P1: significantly harms comprehension, accessibility, adoption, or integrity;
• P2: meaningful improvement with moderate impact;
• P3: polish, experimentation, or future opportunity.

Do not inflate severity. Distinguish verified defects from hypotheses.

D. Route-by-route review

For each primary route, list:

• intended job;
• whether it fulfills that job;
• strongest element;
• main problem;
• one concrete next change;
• evidence.

E. Exact copy recommendations

Provide only the highest-impact copy changes. For each, show:

• current wording;
• proposed wording;
• reason;
• affected route;
• claim-boundary check.

F. Recommended release scope

Define a focused v2.9.2 release containing no more than eight implementation items. Each item must have measurable acceptance criteria and named likely files/routes.

Then provide a separate v3.0 backlog for larger product additions such as:

• readiness assessment;
• client-side pack generator;
• template-variable editor;
• schema validator;
• claim-boundary linter;
• version-diff viewer;
• implementation gallery;
• framework crosswalks.

Do not place speculative product features into v2.9.2 unless a current user problem and constrained implementation are demonstrated.

G. QA and evidence plan

Give exact commands, tools, viewport checks, and manual test steps needed to verify the recommended release. State which checks require staging or production access.

H. Implementation handoff

End with a copy-ready implementation handoff containing:

• target version;
• release objective;
• ordered work items;
• files/routes likely affected;
• blockers that must remain preserved;
• required automated checks;
• required manual checks;
• deliverables;
• unresolved questions that genuinely block implementation.

Evidence rules

• Cite the exact live URL for every deployed finding.
• Cite file paths and relevant code locations for package findings.
• Include screenshots or test output for visual, responsive, accessibility, and performance findings.
• Record HTTP status, content type, and redirect chain for route and download problems.
• State the date and UTC time of live testing.
• Label anything not directly verified as a hypothesis.
• Do not fabricate analytics, user research, test passes, accessibility conformance, or performance scores.
• Do not repeat broad advice such as “improve accessibility” or “improve SEO” without a precise defect, impact, fix, and acceptance criterion.

Final standard

The review is successful only if another engineer can convert it directly into a small, evidence-backed release without needing to reinterpret generic recommendations.