BarkBowl Improvement Plan for dogfood.creativeexpansion.net

Full report

On this page

Executive summary

The live site already has the right product framing and a stronger-than-average public boundary posture. The homepage explains BarkBowl quickly, keeps the primary navigation short, states the “no money / human review / no runtime control” boundary clearly, and points users to a site-map fallback when the compact “More” navigation is unavailable. Privacy copy is plain-language and specific, and the Accessibility page at least documents keyboard, focus, motion, and contrast intent. Those choices align well with Teleodynamic’s current emphasis on practical entry routes, bounded claims, inspectable modules, and “evidence before confidence,” and they also align with MikeKappel.com’s current preference for a short human review path with deeper structured evidence left available but secondary.

The largest problem is not basic branding, layout, or copy tone. It is cross-surface truth drift. The homepage, Runtime Verification, Release Manifest, Root File Delivery, HTTP Header Verification, Crawl Governance, Agent Cache Coherence, UAIX Memory Status, Source Freshness Monitor, and UAIX Protected Anchor Status all present a current-looking 1.28.0 / 2026.06.11.030 story, with Runtime Verification reporting PASS, 422 evidence assets, and 91 required route shells. At the same time, Public Diagnostics still renders 1.19.0 with 297 evidence assets and 57 routes, Accessibility still says “Last verified package: 1.20.0,” Machine-Readable Governance still renders 1.22.0, Deployment Runbook still renders 1.14.0, and the live public settings contract at /wp-json/barkbowl/v1/settings/public still serves 1.11.0, 2026.06.11.013, 101 evidence assets, 23 route shells, and only 60 glossary terms. That is the first problem to solve because it breaks the site’s own deployment-trust model.

The second major issue is that several operator pages still put historical incident text and large inline JSON payloads directly in the main human reading flow. That is transparent, but it is not readable enough for public operator UX or assistive-tech UX, and it conflicts with MikeKappel.com’s current pattern of keeping machine-readable files and deeper technical evidence behind a cleaner human-first review path.

The shortest high-impact sequence is: create one canonical release contract and make every page, REST endpoint, and direct file render from it; hard-fail Runtime Verification if the live public contract disagrees; expand no-store/no-cache coverage for operator HTML and deployment JSON; move historical incident notes into clearly labeled history blocks; clean up operator-page presentation; then fix the probable empty-toast residue, formalize favicon delivery, and refresh UAIX memory status so it reflects current UAIX baseline files and handoff rules. Teleodynamic’s current public guidance says machine readers should follow a safe route before widening claims, and the UAIX Memory Package Wizard says launch-baseline packages should include memory-maintenance.uai, identity.uai, world-context.uai, and protected anchors such as totem.uai, taboo.uai, and talisman.uai; BarkBowl’s current public memory page only partially reflects that baseline.

What the live site is doing well and where it drifts

The front door is already good. The homepage explains BarkBowl as “time-commerce dogfooding” disguised as premium kibble, gives two immediate actions, and keeps the primary navigation compact. The site map explicitly says it exists as a no-JavaScript fallback to keep too many routes out of the first-screen header. Privacy is unusually direct about what is collected, why it is collected, and the fact that there is no payment or real dog-food commerce. Accessibility states the intended keyboard, focus, reduced-motion, and contrast behaviors, which is the right kind of plain operational statement even though it needs freshness repair.

Where the site drifts is in the public proof chain. The homepage shows 1.28.0, 2026.06.11.030, 422 evidence assets, and 91 routes. Runtime Verification also shows 1.28.0, 2026.06.11.030, PASS, 72 canonical glossary terms, 422 evidence assets, and 91 required route shells. Release Manifest agrees. But Public Diagnostics still shows 1.19.0, 2026.06.11.021, 297 evidence assets, and 57 routes; Accessibility still says the last verified package is 1.20.0; Machine-Readable Governance still shows 1.22.0; Deployment Runbook still shows 1.14.0; and /wp-json/barkbowl/v1/settings/public still serves 1.11.0, 2026.06.11.013, 101 evidence assets, 23 route shells, and 60 glossary terms. That is not a cosmetic mismatch. It means the site is publishing multiple incompatible “truths” about the same deployment.

The machine-readable and governance model is conceptually strong. Machine-Readable Governance correctly says it is a read-only orientation and direct-file delivery layer and explicitly disclaims certification, DNS mutation, credential validation, model training, private-network probing, draft approval, incident closure, and exact glyph translation. Crawl Governance similarly says crawlability is not safety certification and does not authorize private probing. Those boundaries are well aligned with Teleodynamic’s role map, which keeps Teleodynamic.com as the philosophical fulcrum, UAIX.org as the schema/memory lane, and CreativeExpansion.net as the bounded creative lane rather than a runtime controller.

The presentation layer on operator pages still needs work. Several pages put a large machine payload directly into the main reading flow as “Copyable JSON evidence,” and the public footer still carries a thick list of operator routes. MikeKappel.com’s current homepage and Evidence Map use a better pattern: short human-first review order, curated deeper proof, and machine-readable files after the human route rather than instead of it. BarkBowl should keep the transparency but switch to the same hierarchy.

This assessment also cross-checked the uploaded BarkBowl Improvement Audit, which independently centered cross-surface truth drift as the dominant trust problem, and treated the separate architectural memo as historical context only because its earlier “site inaccessible” assumption no longer matches the live public site.

The table below compiles the major current surface mismatches from the live public site.

Prioritized improvement plan

Because the exact source tree is not public in this audit, the file paths below are logical WordPress targets, not source-confirmed filenames. In practice, these changes will likely land in the BarkBowl plugin REST/settings layer, shared helper functions, seed/migration logic, theme page templates, theme header/footer, and front-end assets. The priorities below are ordered by impact first, then risk reduction, then effort. The ordering is driven directly by the live mismatch pattern shown above.

The most important implementation change is the single source of truth for package, seed, counts, and timestamps. This is the simplest path to eliminate the current fork between homepage/runtime/release pages and the stale public JSON/page surfaces.

<?php
/**
 * Example only. Exact filenames and option keys are unspecified.
 */
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(),
        'publicDiagnosticsVersion'  => '1.28.0',
        'generatedAtUtc'            => gmdate('c'),
    ];
}

The second essential change is a hard parity gate inside Runtime Verification. Right now the smoke report says the public diagnostics schema is 1.28.0 while the public settings contract still serves 1.11.0. The most plausible explanation is that Runtime Verification is checking an internal expectation rather than the live public JSON contract. That should become a real live comparison.

<?php
/**
 * Example only. Force Runtime Verification to compare live public output.
 */
function barkbowl_verify_public_settings_parity(): array {
    $expected = barkbowl_release_contract();

    $public = barkbowl_build_public_settings_payload(); // same exact builder used by the live endpoint

    $checks = [
        'packageVersion'           => $public['packageVersion'] === $expected['packageVersion'],
        'themeVersion'             => $public['themeVersion'] === $expected['themeVersion'],
        'seededVersion'            => $public['seededVersion'] === $expected['seededVersion'],
        'evidenceAssetCount'       => (int) $public['evidenceAssetCount'] === (int) $expected['evidenceAssetCount'],
        'routeShellCount'          => (int) $public['routeShellCount'] === (int) $expected['routeShellCount'],
        'glossaryCount'            => (int) $public['glossaryCount'] === (int) $expected['glossaryCount'],
        'publicDiagnosticsVersion' => $public['publicDiagnosticsSchemaVersion'] === $expected['publicDiagnosticsVersion'],
    ];

    return [
        'status' => in_array(false, $checks, true) ? 'FAIL' : 'PASS',
        'checks' => $checks,
    ];
}

The current BarkBowl operator pages already describe the needed cache and purge discipline: install the ZIPs, run the seeder twice, save permalinks, clear every cache layer, and then verify pages and direct files with a private window and curl -I. What is missing is stricter automatic cache behavior on the most critical truth surfaces.

<?php
/**
 * Example only. Apply no-store to operator truth pages and deployment JSON.
 */
function barkbowl_send_operator_cache_headers(): void {
    if (is_admin()) {
        return;
    }

    $request_uri = $_SERVER['REQUEST_URI'] ?? '';
    $no_store_paths = [
        '/runtime-verification/',
        '/public-diagnostics/',
        '/release-manifest/',
        '/deployment-runbook/',
        '/machine-readable-governance/',
        '/root-file-delivery/',
        '/http-header-verification/',
        '/crawl-governance/',
        '/agent-cache-coherence/',
        '/chrome-consistency/',
        '/accessibility/',
        '/uai-memory-status/',
        '/source-freshness-monitor/',
        '/live-deployment-gap/',
        '/uai-protected-anchor-status/',
        '/wp-json/barkbowl/v1/settings/public',
        '/wp-json/barkbowl/v1/runtime/verification',
        '/wp-json/barkbowl/v1/release/manifest',
    ];

    foreach ($no_store_paths as $path) {
        if (str_starts_with($request_uri, $path)) {
            header('Cache-Control: no-store, max-age=0', true);
            header('Pragma: no-cache', true);
            header('X-Content-Type-Options: nosniff', true);
            return;
        }
    }
}
add_action('send_headers', 'barkbowl_send_operator_cache_headers', 20);

The operator-supplied screenshot below is the clearest current UI defect. Based on shape, placement, and the prior pattern already described in BarkBowl’s own release history, the most likely cause is an empty toast or aria-live region rendering with pill styling while empty. That is a low-effort / low-risk fix and should be bundled with the favicon work. The diagnosis is probable, not source-proven.

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

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

// Example only
function showToast(message, timeout = 4000) {
  const region = document.querySelector('.bb-toast-region');
  const text = (message || '').trim();
  if (!region || !text) return;

  region.hidden = false;
  region.textContent = text;

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

<?php
/* Example favicon head output */
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);

Finally, the operator pages should adopt a human-first summary / machine-second artifact layout, which is closer to the current MikeKappel evidence model and much friendlier to keyboard and screen-reader use. MikeKappel’s Evidence Map explicitly keeps code-like resources behind a readable human path and tells AI evaluators to review the human pages first. BarkBowl should do the same with its operator screens.

<section aria-labelledby="bb-verify-files">
  <h2 id="bb-verify-files">Verify direct files</h2>
  <p>Confirm the files below return the current package and seed after deploy and purge.</p>

  <ul class="bb-checklist">
    <li><a href="/llms.txt">/llms.txt</a></li>
    <li><a href="/llms.json">/llms.json</a></li>
    <li><a href="/.well-known/ai-agent.json">/.well-known/ai-agent.json</a></li>
    <li><a href="/agent-start.json">/agent-start.json</a></li>
    <li><a href="/safe-read-order.json">/safe-read-order.json</a></li>
  </ul>

  <details>
    <summary>Open machine payload</summary>
    <pre tabindex="0">…JSON here…</pre>
  </details>
</section>

Secondary improvements across telemetry, security, and testing

The next group of changes is slightly less urgent than the version/cache/parity work, but still worth doing immediately after the public truth surfaces are unified. BarkBowl already records telemetry with UTC timestamps, route context, feature-flag state, and hashed session identifiers, while Teleodynamic currently positions ErrorNotifier.com as the ecosystem’s telemetry and incident lane. That combination strongly supports adding better server-side correlation, error logging, and operator-facing verification that actual server errors were reviewed after deployment.

A small structured logger wrapper is one practical way to make deployment evidence much more credible without turning BarkBowl into a private telemetry platform. The live site already uses UTC consistently on many diagnostics pages, and BarkBowl’s own deployment instructions repeatedly tell the operator to inspect evidence before claiming success.

<?php
/**
 * Example only. Avoid logging secrets or raw private data.
 */
function barkbowl_log_event(string $level, string $message, array $context = []): void {
    $payload = [
        'utc'             => gmdate('c'),
        'level'           => $level,
        'message'         => $message,
        'packageVersion'  => defined('BARKBOWL_TIME_CART_VERSION') ? BARKBOWL_TIME_CART_VERSION : 'unknown',
        'requestId'       => $context['requestId'] ?? wp_generate_uuid4(),
        'route'           => $context['route'] ?? ($_SERVER['REQUEST_URI'] ?? ''),
        'seededVersion'   => get_option('barkbowl_seeded_version', ''),
        'context'         => array_diff_key($context, array_flip(['secret', 'token', 'password'])),
    ];

    error_log(wp_json_encode($payload, JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE));
}

For headers and CORS, the simplest policy is: no-store for operator truth pages and deployment-sensitive JSON, short-TTL for direct public files, nosniff everywhere, and no wildcard CORS by default. BarkBowl’s own HTTP Header Verification page already frames content-type checks as live operator evidence rather than certification, which is exactly the right mindset.

# Example only. Vendor/server details are unspecified.
location ~* ^/(runtime-verification|public-diagnostics|release-manifest|deployment-runbook|machine-readable-governance|root-file-delivery|http-header-verification|crawl-governance|agent-cache-coherence|chrome-consistency|accessibility|uai-memory-status|source-freshness-monitor|live-deployment-gap|uai-protected-anchor-status)/?$ {
    add_header Cache-Control "no-store, max-age=0" always;
    add_header X-Content-Type-Options "nosniff" always;
}

location = /llms.txt {
    add_header Cache-Control "public, max-age=300, must-revalidate" always;
    add_header X-Content-Type-Options "nosniff" always;
}

location = /llms.json {
    add_header Cache-Control "public, max-age=300, must-revalidate" always;
    add_header X-Content-Type-Options "nosniff" always;
}

# Only add ACAO if a real browser cross-origin requirement exists.
# add_header Access-Control-Allow-Origin "https://dogfood.creativeexpansion.net" always;

Deployment checklist and verification commands

The sequence below follows BarkBowl’s own Release Manifest, Root File Delivery, HTTP Header Verification, Agent Cache Coherence, and Crawl Governance pages, while correcting for the current stale-surface problem. The single most important verification rule is this: do not claim deployment complete until homepage, Runtime Verification, Public Diagnostics, Machine-Readable Governance, Deployment Runbook, Accessibility, and /wp-json/barkbowl/v1/settings/public all agree.

Use these exact pages in the human verification pass:

/
 /runtime-verification/
 /release-manifest/
 /public-diagnostics/
 /deployment-runbook/
 /accessibility/
 /machine-readable-governance/
 /root-file-delivery/
 /http-header-verification/
 /crawl-governance/
 /agent-cache-coherence/
 /chrome-consistency/
 /uai-memory-status/
 /source-freshness-monitor/
 /live-deployment-gap/
 /uai-protected-anchor-status/

Use these public JSON and contract endpoints in the machine verification pass:

curl -sS https://dogfood.creativeexpansion.net/wp-json/barkbowl/v1/ping
curl -sS https://dogfood.creativeexpansion.net/wp-json/barkbowl/v1/diagnostics/lite
curl -sS https://dogfood.creativeexpansion.net/wp-json/barkbowl/v1/release/manifest
curl -sS https://dogfood.creativeexpansion.net/wp-json/barkbowl/v1/deployment/parity-lite
curl -sS https://dogfood.creativeexpansion.net/wp-json/barkbowl/v1/surface-agreement/public
curl -sS https://dogfood.creativeexpansion.net/wp-json/barkbowl/v1/settings/public | jq '.data | {
  packageVersion,
  themeVersion,
  seededVersion,
  lastSeededVersion,
  glossaryCount,
  evidenceAssetCount,
  routeShellCount,
  publicDiagnosticsSchemaVersion
}'
curl -sS https://dogfood.creativeexpansion.net/wp-json/barkbowl/v1/runtime/verification
curl -sS https://dogfood.creativeexpansion.net/wp-json/barkbowl/v1/diagnostics/snapshot
curl -sS https://dogfood.creativeexpansion.net/wp-json/barkbowl/v1/deployment/runbook

Use these direct-file checks because BarkBowl’s own Root File Delivery and HTTP Header Verification surfaces say these are the critical machine-readable and crawl files to inspect after deploy and purge.

for u in \
  /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 \
  /barkbowl-machine-readable-governance.json \
  /barkbowl-agent-file-verification.json \
  /barkbowl-root-file-delivery.json \
  /.well-known/barkbowl-root-file-delivery.json \
  /robots.txt \
  /sitemap.xml \
  /barkbowl-sitemap.xml \
  /favicon.ico
do
  echo "### $u"
  curl -sSI "https://dogfood.creativeexpansion.net$u" | sed -n '1,20p'
  echo
done

Use this explicit CDN/page-cache purge list. The current site already demonstrates why broad pattern purges are not enough; exact URL purges are warranted for release-truth surfaces.

/
 /runtime-verification/
 /release-manifest/
 /public-diagnostics/
 /deployment-runbook/
 /accessibility/
 /machine-readable-governance/
 /root-file-delivery/
 /http-header-verification/
 /crawl-governance/
 /agent-cache-coherence/
 /chrome-consistency/
 /uai-memory-status/
 /source-freshness-monitor/
 /live-deployment-gap/
 /uai-protected-anchor-status/
 /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
 /barkbowl-sitemap.xml
 /favicon.ico
 /wp-json/barkbowl/v1/settings/public
 /wp-json/barkbowl/v1/runtime/verification
 /wp-json/barkbowl/v1/release/manifest
 /wp-json/barkbowl/v1/deployment/parity-lite
 /wp-json/barkbowl/v1/surface-agreement/public

The header expectations below follow BarkBowl’s current public operator guidance and the recommended hardening changes in this report. The server platform and CDN vendor are unspecified, so treat these as policy targets rather than source-proven current headers. The content-type expectations themselves are explicitly documented on BarkBowl’s Root File Delivery and HTTP Header Verification pages.

If WP-CLI is available, treat it as optional because availability is unspecified. A safe, non-invented baseline is:

wp plugin list | grep barkbowl
wp theme list | grep barkbowl
wp cache flush

Custom seeder commands, option keys, or plugin/theme slugs should only be scripted once their exact names are verified in your runtime.

Roadmap and sequencing

The fastest route to a trustworthy site is to separate quick wins that remove false signals immediately from medium and longer work that improves maintainability, observability, and testing depth. The comparison below assumes one operator plus one engineer can work in parallel. Budget and staffing are otherwise unspecified.

gantt
    title BarkBowl improvement sequence
    dateFormat  YYYY-MM-DD
    axisFormat  %b %d

    section Immediate stabilization
    Canonical release contract and shared render source     :active, a1, 2026-06-16, 2d
    settings/public repair and runtime parity hard-fail     :a2, after a1, 1d
    No-store headers and CDN purge rules                    :a3, after a1, 1d
    Refresh stale operator pages                            :a4, after a1, 2d

    section UI and accessibility cleanup
    Empty toast and ARIA live-region cleanup                :b1, after a2, 1d
    Favicon delivery and verification                       :b2, after a2, 1d
    Human-first operator page layout                        :b3, after a4, 2d
    Footer and navigation weight reduction                  :b4, after b3, 1d

    section Governance and memory hygiene
    UAIX memory status alignment                            :c1, after a4, 1d
    Historical-versus-current incident separation           :c2, after a4, 1d
    Machine-readable route and root-file verification pass  :c3, after a3, 1d

    section Observability and validation
    Structured logging and post-deploy error review         :d1, 2026-06-23, 2d
    Keyboard and assistive-tech smoke matrix                :d2, after b3, 2d
    Core Web Vitals and page-weight pass                    :d3, after b3, 2d
    DNS/RDAP/TLS operator checklist publication             :d4, after d1, 1d

If you complete only the first four work items, BarkBowl will stop telling multiple incompatible stories about the same release, which is the single highest-value improvement. After that, the UI and governance cleanup becomes much easier because every page, direct file, and verification route will already be reading from the same truth source.