UAIX / AI Memory / Handoff

BarkBowl Improvement Audit for dogfood.creativeexpansion.net

Report summary

Status: Research archive item
Category: UAIX / AI Memory / Handoff
Length: 4,237 words
Reading time: 20 minutes
Report type: evaluation

Key topics

UAIX / AI Memory / Handoff
UAIX
AI Memory
Handoff
AI
UAI
Agent File Handoff
WordPress
.NET

Research provenance

Archive status: Research archive item
Canonical report: https://mikekappel.com/reports/uaix-ai-memory-handoff/barkbowl-improvement-audit-for-dogfood-creativeexpansion-net/
Content identity: sha256:1d1505bda2365d8a93ff8438d4c664fbd3712eb01a5110d43738424eb8d73b87

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

Source availability: 60 citation markers in the source export have no recoverable source links. Those markers are omitted from this reader; any supplied bibliography and ordinary links remain. Check the original sources before relying on the cited claims.

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

Executive summary

The public front door is materially better than a typical internal dogfood site. The homepage explains the premise quickly, keeps the first-screen navigation short, uses explicit claim boundaries, and points operators to a site-map fallback when the compact “More” menu or mobile drawer is unavailable. Privacy copy is unusually plain-language and bounded, and Runtime Verification presents itself as a read-only smoke report rather than a certification surface. Those patterns align well with Teleodynamic’s current emphasis on practical entry points, bounded claim language, inspectable modules, and “audit posture before confidence,” and they also align with MikeKappel’s current preference for a short human review path with deeper evidence kept available but secondary.

The main problem is not basic UX polish. It is cross-surface truth drift. In this audit, the homepage, Runtime Verification, Release Manifest, Root File Delivery, HTTP Header Verification, Crawl Governance, Agent Cache Coherence, Chrome Consistency, and UAIX Memory Status all present a current-looking 1.28.0 / 2026.06.11.030 story, with 91 route shells and 422 evidence assets on the runtime side. At the same time, /accessibility/ still says “Last verified package: 1.20.0,” /machine-readable-governance/ still reports 1.22.0, /public-diagnostics/ still reports 1.19.0 with only 57 routes and 297 evidence assets, /deployment-runbook/ still reports 1.14.0, and the live public contract endpoint /wp-json/barkbowl/v1/settings/public serves JSON that still says 1.11.0, 2026.06.11.013, 101 evidence assets, and only 23 route shells. That is the single highest-priority defect because it breaks the site’s own trust model.

The second major issue is that several operator pages still present historical incident text and inline JSON dumps as primary human UI. Machine-Readable Governance embeds stale historical findings about older llms.txt failures, Chrome Consistency still references older live-deployment problems, and several pages expose giant copyable JSON blocks directly in the reading flow. That is useful as evidence, but not as first-line human UX or assistive-tech UX. It also conflicts with the MikeKappel pattern of keeping structured files and research utilities secondary to the main human path.

The recommended sequence is straightforward. First, create one canonical release contract and make every operator page, REST contract, and machine-readable file read from it at render time. Second, expand cache exclusions and purge scope to all operator evidence routes and dynamic public contracts. Third, refresh the accessibility page, machine-readable governance page, deployment runbook, and UAIX memory page so they are current and so they expose clickable file/end-point checks instead of only JSON blobs. Fourth, patch the likely empty-toast residue and formalize favicon delivery through both theme <head> links and a root-file fallback. Fifth, keep operator pages secondary in the public funnel. Teleodynamic’s current guidance says machine readers should get a safe read order before they widen claims, and UAIX’s current wizard says launch-baseline memory packages should include memory-maintenance.uai, identity.uai, world-context.uai, totem.uai, taboo.uai, talisman.uai, and short-term-memory.uai; BarkBowl’s public memory status page does not currently expose that full baseline.

Scope, method, and assumptions

This audit used the live public site itself as the primary source, focusing on the homepage and the pages or files you explicitly named: privacy, accessibility, runtime-verification, chrome-consistency, agent-file-verification, machine-readable-governance, llms.txt, robots.txt, and sitemap.xml, along with adjacent operator pages that those routes pointed to or referenced, including Release Manifest, Public Diagnostics, Root File Delivery, HTTP Header Verification, Crawl Governance, Agent Cache Coherence, Deployment Runbook, and UAIX Memory Status. It also compared the site against current public guidance from Teleodynamic.com, MikeKappel.com, and the UAIX AI Memory Package Wizard.

I did not have access to WordPress admin, database state, PHP source, server logs, CDN configuration, edge rules, or a direct command-line network path to the site. I also could not directly fetch some route shells and direct files through the browser tool even when the site’s own runtime verification said those route shells existed. For that reason, this report distinguishes between directly observed current output and expected output stated by the site’s own operator/audit pages. The previously uploaded architectural memo is now historical context rather than live truth, because it assumed the site was inaccessible, while the site is currently serving multiple HTML and JSON surfaces.

Two conclusions in this report are inferential rather than proven root-cause findings. First, the version mismatch pattern is most consistent with a mix of stale HTML/page cache, older seeded page content, and at least one stale public REST contract. Second, the operator-provided screenshot appears consistent with an empty toast/live-region container rendering as a visible pill. I am treating both as probable causes, not as source-proven facts.

Current-state UX and accessibility audit

The homepage is doing the right high-level work. It explains the satirical product model in plain language, keeps the primary first-screen navigation to five short items, surfaces two clear first actions, and states boundaries such as “no money,” “human review required,” and “no runtime control.” The site map explicitly says it exists as a no-JavaScript fallback for the compact “More” navigation and is meant to keep secondary routes out of the first-screen header. That is good information architecture and matches the current MikeKappel pattern of keeping the shortest human path first while leaving deeper proof available behind it.

Privacy is concise and strong. It says the site collects only the least information needed, does not sell real dog food, does not process payments, does not need billing or shipping information, and hashes session identifiers for telemetry. That page reads like operator-friendly plain language rather than compliance theater. Accessibility is also candid: it documents keyboard behavior, visible focus, reduced motion, screen-reader semantics, no-JS fallbacks, and known limitations. The problem is that the accessibility page is stale in the exact place where trust matters: it still claims “Last verified package: 1.20.0,” even while the runtime and release pages claim 1.28.0. That makes the accessibility statement look archival instead of operational.

The operator-facing information architecture is mixed. On the one hand, the site correctly provides a compact header plus a site-map fallback, and Runtime Verification clearly states that a passing smoke report is not certification, not credentials validation, and not private-network probing. On the other hand, the homepage puts a fairly technical Public Diagnostics block into the main narrative, and the footer on public-facing pages still exposes a heavy list of operator utilities. Compared with MikeKappel’s “resume and selected proof first; structured files and research stay secondary” pattern, BarkBowl is closer than it used to be, but it still gives operator surfaces more visual weight than it should on user-facing pages. My recommendation is to keep only a minimal “For operators” entry in the footer of public pages and move the full diagnostics directory behind the site map or a dedicated operator-only index section.

The most significant UX/accessibility issue is the use of very large inline JSON blobs as primary reading content on operator pages. Machine-Readable Governance, Root File Delivery, Chrome Consistency, and other audit pages expose long machine payloads directly in the reading flow. That improves transparency, but as a human interface it is noisy, difficult to skim, and likely unpleasant for screen readers and keyboard users. Teleodynamic’s current public model says theory should become inspectable without pretending to run a real system, and MikeKappel’s current site structure keeps machine-readable files available without leading the human funnel. BarkBowl should follow that pattern more strictly by rendering a short human summary first, then a checklist of clickable files/endpoints, then a collapsed <details> block or downloadable JSON artifact for the machine/readout layer.

The dedicated Chrome Consistency page deserves credit because it encodes exactly the kind of deployment drift the operator cares about, including stale markers and route-specific checks. But its own content also reveals the deeper problem: it warns about earlier stale chrome states, tells operators to purge caches, and lists a no-cache route set, yet several current public pages are still stale anyway. In other words, BarkBowl has already diagnosed the class of failure; it just has not eliminated it.

Governance, direct files, and REST parity

The strongest architectural part of the site is its boundary language. Machine-Readable Governance says it is a read-only orientation and direct-file delivery layer and explicitly says it does not certify the site, mutate DNS, validate credentials, train models, probe private networks, approve drafts, close incidents, or claim exact glyph translation. Crawl Governance makes similar statements. Those are directly aligned with Teleodynamic’s current lane map, where Teleodynamic is the philosophical fulcrum and claim-governance anchor, CreativeExpansion is allowed to generate draft options but blocked from proof, certification, runtime control, private-network probing, model training, exact glyph translation, and protected-anchor mutation, and machine readers are supposed to follow a safe route before widening claims.

The governance problem is not tone. It is parity. Release Manifest says the install target is 1.28.0, seed target 2026.06.11.030, and 422 evidence assets, and Runtime Verification says the smoke report passes with 91 route shells, 72 canonical glossary terms, and 422 evidence assets. But Public Diagnostics still renders 1.19.0, Machine-Readable Governance still renders 1.22.0, Deployment Runbook still renders 1.14.0, Accessibility still announces 1.20.0, and the public JSON contract at /wp-json/barkbowl/v1/settings/public still serves a 1.11.0 contract with only 23 route shells and 101 evidence assets. That means the site’s “primary public package, seed, count, and status contract” is not the same truth that the current HTML runtime pages are showing.

That mismatch is especially severe because the homepage and the Public Diagnostics page both describe /wp-json/barkbowl/v1/settings/public as the main public contract, while Runtime Verification says the current Public Diagnostics schema version is 1.28.0. Yet the live JSON contract still says publicDiagnosticsSchemaVersion: 1.11.0. The practical meaning is that BarkBowl’s own evidence chain is currently forked: one branch is reading a newer release contract, while another public branch is still serving an older one. Inference, not proof: this looks like at least one stale endpoint callback, old plugin directory, stale object/page cache, or older seeded/static surface still in circulation.

The direct-file governance design is good in principle. Root File Delivery and HTTP Header Verification specify expected delivery for llms.txt, /.well-known/llms.txt, llms.json, /.well-known/ai-agent.json, /.well-known/agent-readiness.json, agent-start.json, ai-summary.json, safe-read-order.json, robots.txt, sitemap.xml, and barkbowl-sitemap.xml, including expected content types and sample curl -I commands. The site’s own operator surfaces expect text/plain; charset=UTF-8 for llms.txt and robots.txt, and application/json; charset=UTF-8 for the JSON assets, and application/xml; charset=UTF-8 for the sitemap files. That is the right direction. What is missing in the current human UI is a direct, clickable verification checklist that a non-developer operator can use without parsing a JSON blob.

UAIX alignment is present but incomplete in the public evidence. UAIX’s current wizard says the human UI and visitor AI digest should come from the same canonical payload, that Agent File Handoff adds active Content and Improvement buckets plus proof-of-use ledgers and intake completion gates, and that every launch-baseline memory package should include memory-maintenance.uai, identity.uai, world-context.uai, totem.uai, taboo.uai, talisman.uai, and short-term-memory.uai. BarkBowl’s UAIX Memory Status page is current-looking at 1.28.0, but the activeMemoryFiles list it exposes publicly omits that launch-baseline set, and one of its embedded check summaries still says short-term memory was rewritten to “current v1.26 facts only,” which is stale wording inside a 1.28.0 page. That should be cleaned up, because public memory status is itself part of the governance story.

Current-versus-recommended diagnostics field parity

Field	Current observed state	Why it is a problem	Recommended state
`packageVersion`	Homepage, Runtime Verification, Release Manifest, Root File Delivery, HTTP Header Verification, Crawl Governance, Agent Cache Coherence, Chrome Consistency, and UAIX Memory Status all read as `1.28.0`.	Good on some surfaces, but not authoritative if other public contracts disagree.	One canonical release contract should emit the same package version to every HTML page, REST endpoint, and direct file.
`packageVersion` on stale surfaces	`/accessibility/` still references `1.20.0`; `/machine-readable-governance/` says `1.22.0`; `/public-diagnostics/` says `1.19.0`; `/deployment-runbook/` says `1.14.0`; `/wp-json/barkbowl/v1/settings/public` serves `1.11.0`.	Operators cannot know which surface is true. That defeats BarkBowl’s own audit posture.	All stale pages and the public JSON contract should converge on the same current version during render, not through manual text updates.
`seededVersion`	Current HTML surfaces converge on `2026.06.11.030`.	Good, but only if it matches all public contracts.	Single source of truth plus seeded-at timestamps rendered from live settings.
`seededVersion` on stale surfaces	Settings JSON serves `2026.06.11.013`; Public Diagnostics serves `.021`; Machine-Readable Governance `.024`; Deployment Runbook `.016`.	This suggests mixed generations of page content and/or endpoint implementations.	Force all operator surfaces to read seed data live from the same provider.
`evidenceAssetCount`	Runtime Verification and Release Manifest show 422 evidence assets.	Good, but contradicted elsewhere.	Same count everywhere; if a page intentionally snapshots history, label it as historical and collapse it.
`evidenceAssetCount` on stale surfaces	Public Diagnostics says 297; settings/public says 101.	Operators could wrongly conclude release evidence is missing or deployment failed.	Dynamic count from one evidence service or contract helper.
`routeShellCount`	Runtime Verification says 91 required route shells and PASS.	Good if and only if public endpoints agree.	Runtime and public contract should agree automatically.
`routeShellCount` on stale surfaces	Homepage says 91, but `settings/public` still says 23, and Public Diagnostics still says 57.	This is the clearest signal that public contracts are split.	`settings/public` should be treated as a must-pass parity gate before release is claimed complete.
`publicDiagnosticsSchemaVersion`	Runtime Verification says actual `1.28.0`.	Good if it is checking the live public endpoint body.	Make the runtime verifier fetch and compare the actual public endpoint output, not an internal expected value.
`publicDiagnosticsSchemaVersion` on live endpoint	`settings/public` still serves `publicDiagnosticsSchemaVersion: 1.11.0`.	The smoke report is currently too easy to pass while live public JSON remains stale.	Add a hard parity assertion between runtime verification and `settings/public`.
UAIX memory baseline exposure	UAIX Memory Status is current-looking, but public `activeMemoryFiles` omit `memory-maintenance.uai`, `identity.uai`, `world-context.uai`, `totem.uai`, `taboo.uai`, and `talisman.uai`, which UAIX currently treats as launch-baseline files.	Public memory governance looks incomplete relative to current UAIX guidance.	Expose the full baseline file set and anchor-protection status on the public memory status page.

Endpoint and file matrix

Surface	Current observed state	Expected content type	Cache risk	Recommended state
`/`	Homepage currently renders `1.28.0`, seed `2026.06.11.030`, 422 evidence assets, 91 routes.	`text/html; charset=UTF-8`	Normal public page cache is acceptable, but the embedded diagnostics snapshot should remain consistent with operator surfaces.	Keep homepage cached normally, but source the embedded diagnostics card from the same release contract as operator pages.
`/runtime-verification/`	Current and passing at `1.28.0`; 91 route shells; 72 canonical glossary terms; 422 evidence assets.	`text/html; charset=UTF-8`	High if cached aggressively, because operators rely on it for deployment truth.	`Cache-Control: no-store, max-age=0` for the HTML route.
`/release-manifest/`	Current at `1.28.0`; lists first-response checks and install order.	`text/html; charset=UTF-8`	Medium-high.	`Cache-Control: no-store, max-age=0`; also provide downloadable JSON as a separate file.
`/public-diagnostics/`	Stale at `1.19.0`, seed `.021`, 297 evidence assets, 57 routes.	`text/html; charset=UTF-8`	Very high. This page is explicitly meant to compare deployment truth.	Move to live contract rendering and exclude from page/object/CDN cache.
`/accessibility/`	Current chrome, but still says “Last verified package: 1.20.0.”	`text/html; charset=UTF-8`	High, because stale accessibility statements erode trust quickly.	Render package/version/test dates dynamically; keep manual test notes current.
`/machine-readable-governance/`	Stale at `1.22.0`; still embeds old `liveFinding` text about earlier `llms.txt` failures.	`text/html; charset=UTF-8`	Very high, because it governs machine readers.	Render from current contract; separate “historical incidents” from current state; render clickable file list.
`/deployment-runbook/`	Stale at `1.14.0`; still instructs operators using older package and seed targets.	`text/html; charset=UTF-8`	Very high.	Render package/seed/install order live from the release manifest provider.
`/wp-json/barkbowl/v1/settings/public`	Live JSON still serves `1.11.0`, seed `.013`, 101 evidence assets, 23 route shells.	`application/json; charset=UTF-8`	Critical. This is a primary public contract but is materially stale.	`Cache-Control: no-store, max-age=0`; move to the same contract helper that feeds Runtime Verification and Release Manifest.
`/llms.txt` and `/.well-known/llms.txt`	Not directly retrieved in this audit, but the site’s own header and root-file pages expect 200 plain text delivery.	`text/plain; charset=UTF-8`	High if stale in CDN/webroot because machine readers will trust it first.	`Cache-Control: public, max-age=300, must-revalidate` plus explicit post-release purge; add `X-Content-Type-Options: nosniff`.
`/llms.json`, `/.well-known/ai-agent.json`, `/.well-known/agent-readiness.json`, `/agent-start.json`, `/ai-summary.json`, `/safe-read-order.json`	Not directly retrieved in this audit, but the site expects JSON delivery and operator `curl -I` verification.	`application/json; charset=UTF-8`	High if stale or served from old webroot kit.	Same cache policy as above; ensure package/seed parity with current release contract.
`/robots.txt`	Not directly retrieved here; the site expects 200 plain text and treats it as crawl orientation only.	`text/plain; charset=UTF-8`	Medium.	`Cache-Control: public, max-age=300, must-revalidate`; ensure it does not imply tool execution or safety approval.
`/sitemap.xml` and `/barkbowl-sitemap.xml`	Not directly retrieved here; the site expects XML delivery.	`application/xml; charset=UTF-8`	Medium.	`Cache-Control: public, max-age=300, must-revalidate`; keep sitemap inclusion language clearly non-certifying.
`/favicon.ico`	No public audit route or site-map entry surfaced favicon delivery in this crawl.	`image/x-icon`	Medium-high because browsers and CDNs can retain stale icons for a long time.	Add a root `favicon.ico`, PNG companions, and explicit `<link rel="icon">` tags; purge favicon caches after deploy.

Recommended release-contract implementation

The site’s version drift is large enough that I would not treat it as a copy-editing problem. I would treat it as a contract-source problem. The cleanest fix is one canonical provider that every operator page, public JSON contract, and machine-readable file uses.

<?php
/**
 * Logical patch sketch, not source-confirmed file path.
 * Create one provider and use it everywhere.
 */
function barkbowl_release_contract(): array {
    return [
        'packageVersion'      => defined('BARKBOWL_TIME_CART_VERSION') ? BARKBOWL_TIME_CART_VERSION : 'unknown',
        'themeVersion'        => wp_get_theme()->get('Version'),
        'seededVersion'       => (string) get_option('barkbowl_seeded_version', ''),
        'lastSeededVersion'   => (string) get_option('barkbowl_last_seeded_version', ''),
        'lastSeededAtUtc'     => (string) get_option('barkbowl_last_seeded_at_utc', ''),
        'evidenceAssetCount'  => (int) barkbowl_count_evidence_assets(),
        'routeShellCount'     => (int) barkbowl_count_required_route_shells(),
        'glossaryCount'       => (int) barkbowl_count_canonical_glossary_terms(),
        'generatedAtUtc'      => gmdate('c'),
    ];
}

function barkbowl_public_contract_response(): array {
    return [
        'ok'   => true,
        'data' => barkbowl_release_contract(),
        'meta' => [
            'generatedAtUtc' => gmdate('c'),
        ],
    ];
}

Every one of these surfaces should consume the same provider at render time: /public-diagnostics/, /machine-readable-governance/, /deployment-runbook/, /release-manifest/, /runtime-verification/, /wp-json/barkbowl/v1/settings/public, and every machine-readable direct file.

UI defects, favicon delivery, and human-facing operator pages

The operator-provided screenshot shows a small green oval or pill sitting at the lower center of the viewport with no visible message, which is highly consistent with an empty toast or live-region container that is still taking visual styles even when it has no content.

[Figure omitted from source export: Operator screenshot showing likely empty toast or live-region residue near the bottom center of the viewport]

Because I did not have DOM or source access, I am treating that as a likely diagnosis rather than a proven one. Still, the fix pattern is standard and low-risk: create the live region hidden, refuse to render empty messages, and collapse the container when it has no text.

/* Sample patch */
.bb-toast-region[hidden],
.bb-toast-region:empty {
  display: none !important;
}

.bb-toast-region {
  position: fixed;
  inset-inline: auto;
  inset-block-end: 1rem;
}

.bb-toast[aria-hidden="true"] {
  opacity: 0;
  pointer-events: none;
}

// Sample patch
const toastRegion = document.querySelector('.bb-toast-region');

export function showToast(message, timeout = 4000) {
  const text = (message || '').trim();
  if (!toastRegion || !text) return;

  toastRegion.hidden = false;
  toastRegion.textContent = text;

  clearTimeout(toastRegion._hideTimer);
  toastRegion._hideTimer = window.setTimeout(() => {
    toastRegion.textContent = '';
    toastRegion.hidden = true;
  }, timeout);
}

Favicon delivery is under-governed in the current public audit story. In this crawl, no public route or human-facing audit page surfaced favicon delivery, and the current governance pages focus on llms, JSON manifests, robots, and sitemaps, not root icon delivery. Because browser and CDN favicon caching is notoriously sticky, BarkBowl should formalize favicon delivery as part of the same root-file governance model: a physical /favicon.ico in the webroot kit, icon tags in the theme head, and a fallback if the server routes root icon requests through WordPress. The exact UI need is straightforward, even though the current public site does not expose it as a governed surface.

<?php
// Sample theme patch
function barkbowl_output_favicons(): void {
    $theme_uri = get_stylesheet_directory_uri();
    echo '<link rel="icon" href="' . esc_url(home_url('/favicon.ico')) . '" sizes="any">';
    echo '<link rel="icon" type="image/png" sizes="32x32" href="' . esc_url($theme_uri . '/assets/images/favicon-32.png') . '">';
    echo '<link rel="apple-touch-icon" href="' . esc_url($theme_uri . '/assets/images/favicon-192.png') . '">';
}
add_action('wp_head', 'barkbowl_output_favicons', 1);
add_action('admin_head', 'barkbowl_output_favicons', 1);

A second human-facing improvement is to stop making machine payloads behave like primary page copy. Current BarkBowl operator pages often present Copyable JSON evidence { ... } as the first thing after the heading. The better pattern is a short operator summary, then a checklist of clickable files and endpoints, then a collapsed machine artifact. That is much closer to Teleodynamic’s “safer path for machine readers” and MikeKappel’s “structured files support tools without leading the human funnel.”

<section aria-labelledby="bb-operator-checks">
  <h2 id="bb-operator-checks">Verify direct files</h2>
  <ul class="bb-checklist">
    <li><a href="/llms.txt">/llms.txt</a> — plain text orientation file</li>
    <li><a href="/.well-known/ai-agent.json">/.well-known/ai-agent.json</a> — JSON agent manifest</li>
    <li><a href="/robots.txt">/robots.txt</a> — crawl orientation</li>
    <li><a href="/sitemap.xml">/sitemap.xml</a> — public route index</li>
  </ul>

  <details>
    <summary>Copy JSON evidence</summary>
    <pre tabindex="0">…generated JSON…</pre>
  </details>
</section>

Prioritized fixes and deployment playbook

Priority diagram

graph TD
    A[Operator installs plugin and theme] --> B[Run seeder twice]
    B --> C[Save permalinks]
    C --> D[Purge page, object, CDN, and browser caches]
    D --> E[Verify release manifest and runtime verification]
    E --> F[Verify settings/public and direct files]
    F --> G[Check homepage, accessibility, public diagnostics, machine-readable governance]
    G --> H[Keyboard-only and visual checks]
    H --> I[Review server logs and record UAIX evidence]
    I --> J[Claim deployment complete only after parity]

Entity relationship diagram

graph LR
    TD[Teleodynamic guidance] --> BC[Boundary language]
    MK[MikeKappel guidance] --> HF[Human-first review path]
    UX[UAIX wizard guidance] --> MM[Memory and handoff baseline]

    BC --> BB[BarkBowl]
    HF --> BB
    MM --> BB

    BB --> H1[Homepage and legal pages]
    BB --> H2[Operator HTML pages]
    BB --> R1[Public REST contracts]
    BB --> F1[Direct files]

    H2 --> PD[Public Diagnostics]
    H2 --> MRG[Machine-Readable Governance]
    H2 --> RV[Runtime Verification]
    H2 --> DR[Deployment Runbook]

    R1 --> SP[settings/public]
    F1 --> LLMS[llms.txt and JSON files]
    F1 --> CRAWL[robots and sitemaps]

    BB --> SRC[One canonical release contract]
    SRC --> H2
    SRC --> R1
    SRC --> F1

Prioritized fixes

Fix	Priority	Effort	Risk	Rollback note
Unify all public operator pages, REST contracts, and direct files behind one release-contract provider	Highest	High	Medium	Revert to previous render callbacks and restore previous templates if a release-blocking regression appears.
Repair `/wp-json/barkbowl/v1/settings/public` so it matches current release state and add a hard parity assertion in Runtime Verification	Highest	Medium	Medium	Restore prior endpoint callback after capturing a known-good JSON snapshot for comparison.
Expand no-cache/no-store handling to all operator/evidence routes and purge them on every deployment	Highest	Medium	Medium	Restore prior cache exclusion list if edge performance becomes a problem; operator pages are low-traffic and freshness should win.
Refresh stale operator pages (`/public-diagnostics/`, `/machine-readable-governance/`, `/deployment-runbook/`, `/accessibility/`) to render live contract values	Highest	Medium	Low	Restore previous page revisions or shortcode output if needed.
Split “current state” from “historical finding” on operator pages so old incidents do not read like current truth	High	Low	Low	Historical notes can remain in collapsed “release history” blocks.
Convert inline JSON blobs into summary cards + clickable file lists + collapsed JSON/downloads	High	Low–Medium	Low	Revert to previous page templates if an assistive-tech regression is found.
Update UAIX Memory Status to expose current launch-baseline files and remove stale “v1.26 facts only” wording	High	Low	Low	Restore previous status template if a formatting issue appears.
Patch likely empty-toast residue	Medium	Low	Low	Remove the CSS/JS override if it breaks alerts; fallback is current behavior.
Formalize favicon delivery with root `favicon.ico`, head tags, and webroot-kit fallback	Medium	Low	Low	Remove head tags and restore prior root file if branding or cache behavior regresses.
Demote operator utilities in the public footer and keep a short “For operators” path instead	Medium	Low	Low	Restore previous footer link set if operators report discoverability issues.

Deployment checklist

Step	Command or action	What to verify
Deploy code	Upload/update plugin ZIP, then theme ZIP, then activate as needed. Use the install order described by Release Manifest and Deployment Runbook.	WordPress admin shows the intended versions for both plugin and theme.
Seed data	Run the BarkBowl seeder twice.	Seed runs idempotently and stores the current seeded version.
Rewrite refresh	Save Settings → Permalinks. The site’s own Root File Delivery and Agent Cache Coherence pages explicitly call this out.	Pretty permalinks and root-file rewrites both work.
Cache purge	Purge page cache, object cache, CDN cache, and browser cache. The site’s own pages repeatedly identify stale cache as a failure mode.	Re-open operator pages in a private window.
Webroot kit fallback	If `llms.txt`, `robots.txt`, `sitemap.xml`, or other root files still miss or stay stale, deploy the webroot governance kit exactly as Root File Delivery recommends.	Root files resolve with the expected content type and current contract values.
Verify current release pages	```bash\ncurl -sS https://dogfood.creativeexpansion.net/wp-json/barkbowl/v1/settings/public	jq '.data
Verify direct files	```bash\ncurl -sSI https://dogfood.creativeexpansion.net/llms.txt\ncurl -sSI https://dogfood.creativeexpansion.net/.well-known/llms.txt\ncurl -sSI https://dogfood.creativeexpansion.net/llms.json\ncurl -sSI https://dogfood.creativeexpansion.net/.well-known/ai-agent.json\ncurl -sSI https://dogfood.creativeexpansion.net/robots.txt\ncurl -sSI https://dogfood.creativeexpansion.net/sitemap.xml\ncurl -sSI https://dogfood.creativeexpansion.net/barkbowl-sitemap.xml\n```	Confirm expected content type, current package/seed where applicable, and sane cache headers.
Verify operator pages	```bash\ncurl -sSI https://dogfood.creativeexpansion.net/public-diagnostics/\ncurl -sSI https://dogfood.creativeexpansion.net/runtime-verification/\ncurl -sSI https://dogfood.creativeexpansion.net/machine-readable-governance/\ncurl -sSI https://dogfood.creativeexpansion.net/deployment-runbook/\n```	All pages should agree on current package and seed; current audit shows they do not.
Verify favicon	```bash\ncurl -sSI https://dogfood.creativeexpansion.net/favicon.ico\n```	Expect an icon content type, then hard-refresh browser tabs to confirm visible icon update.
Visual checks	Open `/`, `/privacy/`, `/accessibility/`, `/runtime-verification/`, `/chrome-consistency/`, `/machine-readable-governance/`, `/public-diagnostics/`.	Confirm no empty toast residue, no raw or duplicated menus, no stale version strings, favicon present, and consistent header/footer.
Keyboard-only checks	Tab through skip links, primary nav, “More” fallback path, Time Bowl CTA, and operator pages. The accessibility statement already says these should work without a mouse.	Confirm visible focus, logical order, and that huge JSON blocks are not the first thing every operator page drops into focus order.
Logs and evidence	Review PHP error logs, web server logs, and CDN cache logs after deploy, then record remaining warnings in UAIX memory/handoff evidence. UAIX’s current wizard emphasizes proof-of-use ledgers, active intake buckets, and deployment evidence.	No REST errors, no rewrite misses, no stale edge objects, and documented closure in `.uai` evidence.

Exact HTTP header expectations

For the next release, I recommend these header policies as the simplest deployable standard:

# Dynamic operator HTML pages
Content-Type: text/html; charset=UTF-8
Cache-Control: no-store, max-age=0
X-Content-Type-Options: nosniff

# Dynamic public deployment JSON
Content-Type: application/json; charset=UTF-8
Cache-Control: no-store, max-age=0
X-Content-Type-Options: nosniff

# Public direct governance/crawl files
# llms.txt, robots.txt
Content-Type: text/plain; charset=UTF-8
Cache-Control: public, max-age=300, must-revalidate
X-Content-Type-Options: nosniff

# Public direct JSON governance files
Content-Type: application/json; charset=UTF-8
Cache-Control: public, max-age=300, must-revalidate
X-Content-Type-Options: nosniff

# Sitemap files
Content-Type: application/xml; charset=UTF-8
Cache-Control: public, max-age=300, must-revalidate
X-Content-Type-Options: nosniff

# Favicon
Content-Type: image/x-icon
Cache-Control: public, max-age=86400

The operational reason for this split is simple: human/operator truth surfaces should bias toward freshness, while root files can keep a short TTL if you always purge them after release.

Recommended edit targets

Because I did not have source access, these are logical edit targets, not source-confirmed filenames. They are still the right places to look first.

The first edit target is the code path that renders /wp-json/barkbowl/v1/settings/public. That endpoint is currently the most dangerous stale contract on the site. Pair it with the page-template or shortcode code that renders /public-diagnostics/, /machine-readable-governance/, /deployment-runbook/, and /accessibility/, then move them all to the same contract helper. That one refactor removes most of the current trust breakage.

The second edit target is theme or routing code that determines cache policy for operator pages. Chrome Consistency already lists a no-cache set, but the currently stale pages show that the exclusion list is insufficient or not effective. Expand it to all operator evidence routes and to the public JSON contract route.

The third edit target is the UI component that renders toast or live-region feedback. The operator screenshot is strong enough to justify a small CSS/JS patch even before a larger UI pass. The fourth is theme head output and/or webroot kit packaging for favicon delivery. The fifth is the public memory-status generator, which should surface the full UAIX launch-baseline file set and remove stale wording. The sixth is the operator page-template layer, replacing inline JSON-first presentation with human-first summaries and a collapsed/downloadable machine layer.

The old uploaded architectural analysis should be retained only as historical context. Its infrastructure and lane-governance themes are still relevant, but its assumption that the site was fundamentally inaccessible is outdated; the live priority now is release parity, cache discipline, and public evidence coherence, not basic reachability.