End-To-End Dogfood Test Plan Research For NeuroWikis And NeuralWikis

Full report

On this page

Confirmed live flow and boundary conditions

Public NeuroWikis and NeuralWikis pages already confirm the intended architecture behind this dogfood path. NeuroWikis is the human-facing lane and NeuralWikis is the agent-facing exchange lane; the public NeuroWikis “Agent Console” page includes a “Temporary testing access” workbench that is explicitly described as a limited UI/UX testing workbench for NeuroWikis.com, while the public NeuralWikis site advertises the agent inbox, current-message, receipts, usage, prompt, and shared-coordination surfaces that an agent would use on the other side.

The public workbench description is especially useful because it confirms several critical constraints of the live dogfood flow. It says the workbench accepts a 24-hour delegated testing token, accepts it from the URL fragment or a manual token field when fragment handling is unavailable, sends the token only as X-NeuroWikis-Testing-Token to testing routes, does not create a WordPress session, does not call wp_set_auth_cookie, and does not expose normal wp-admin capabilities such as plugins, settings, users, database admin, or file/theme editor access. It also states that testing messages are queued through the existing MySQL-backed outbox path as human_agent_message rows through nw_matm_outbox_events, and that findings should be returned through this UI rather than Codex chat.

The same public workbench description also gives the intended test path after token validation: validate the token, queue a project-level message and optionally a specific-agent message, copy a redacted receipt summary, and then treat worker reconciliation, dispatch review, memory promotion, and external authority receipts as authority-gated beyond the NeuroWikis queue receipt. The receipt surface is explicitly supposed to show only redacted outbox, hierarchy, hash, length, and lifecycle evidence, and not replay the message body, token, raw selector values, private payloads, or database row values.

On the NeuralWikis side, the public machine-readable and human-readable surfaces confirm that current-message handling is not supposed to be an afterthought. NeuralWikis publicly exposes routes for /api/matm/live-capability-matrix, /api/matm/redacted-example-receipts, /api/matm/shared-workspace-coordination, /api/matm/agent-setup/free-account, and agent inbox / current-message routes, and the current-message bootstrap prompt says unread current messages should be surfaced before private search, implementation, or integration work. It also says private search is older-history fallback, not the current-message lane.

The public prompt and coordination contracts further confirm the expected acknowledgement behavior. Current messages must resolve as either required_response or viewed_acknowledgement, optional-style wording is prohibited for agent-facing current-message instructions, and the shared-coordination contract says the system should support reading current messages, acknowledging them as read or archived, reading receipts, and preserving the original outbox row status while the acknowledgement is recorded through the notifications ledger.

What is still unverified

Several of the user’s target checks are not proven by public pages alone and still need live authenticated testing. The public workbench proves the intended delegated-token consumer flow, but it does not prove the actual wp-admin issuance UI, the exact admin screen path, the label and placement of the “Generate NeuroWikis.com testing prompt” control, or whether the control is discoverable through the WordPress admin menu versus only by a direct URL. WordPress itself expects menu and submenu visibility to be capability-gated and visible in the admin menu structure, so discoverability has to be tested in a real admin session rather than inferred from public route availability.

The exact UI copy for invalid, expired, and revoked token states also remains open. The public workbench page clearly says expiry and revocation behavior belong in the black-box checklist, but the crawlable page does not expose those exact strings; searches of the rendered page for Invalid, expired, and revoked do not surface the actual user-facing message copy. That means the state handling may exist live, but the precise text, severity, and accessibility semantics still need to be captured in-session.

The same is true for the active-token list requirement. Nothing public that I found proves the existence, grouping logic, sort order, or row schema of the admin “active tokens” listing. Because the public workbench only documents token consumption, not the admin token-management list, the requirement that the list must not collapse rows “grouped only by user” remains a pure live-admin verification item.

Copy-button behavior is only partially evidenced publicly. The page clearly includes Copy Prompt actions and a Copy redacted receipt summary action, but the public markup I found does not prove the exact success feedback text or whether it is announced using an accessible status pattern. That matters because clipboard writes are browser- and context-sensitive, and user-visible success/failure feedback is part of the remaining test scope.

Finally, sidebar/layout blockers are still unverified. Public text confirms that navigation clarity and prompt-copy behavior are part of the black-box checklist, but the crawlable content does not prove whether a real WordPress admin sidebar, collapsed menu state, zoom level, or narrow viewport can obscure fields or buttons. That has to be checked in a live browser, including keyboard focus order and control reachability.

Safe evidence collection rules

The safest way to run this dogfood plan is to separate secret-bearing artifacts from shareable evidence artifacts. The delegated token itself must never be preserved in evidence. The public workbench already says not to put the raw token in a URL, report, chat, memory, or finding, and it says the raw token is intended to stay out of page markup, reports, logs, memory, and public copy. Pair that with the fact that URI fragments are processed client-side and are not sent to the server, while query strings are a known disclosure channel for tokens and other sensitive values, and the safest evidence rule is straightforward: allow the token to travel only through the fragment/manual field/header path required for the test, never through query parameters, saved screenshots, transcripts, or exported artifacts.

Use only benign synthetic test content in the message body and final report. The message can safely contain a test phrase such as DOGFOOD current-message visibility check <UTC timestamp> because the workbench receipt will not replay the body anyway, and the NeuralWikis side can safely show benign text if the current-message body becomes visible. This gives you something concrete to verify without creating a new secret. The sensitive thing in this flow is the delegated token, not the synthetic test message. The workbench’s own contract supports this approach because it promises redacted receipts and says only outbox id, hierarchy, hash, length, and lifecycle evidence should be recorded.

Do not export raw HAR files for token-bearing requests unless you manually redact them first. Chrome DevTools now lets you export HAR “sanitized” by default, but that sanitization only excludes Cookie, Set-Cookie, and Authorization headers. The delegated token is documented as a custom header, X-NeuroWikis-Testing-Token, so a HAR export can still preserve it unless you remove that request or redact the header manually. For this test plan, the safest default is: capture the request row, URL path, status code, and timestamp in screenshots or notes, but do not save a HAR for the token-validation request or any request carrying the delegated token header.

For copy-button evidence, rely on visible feedback instead of the copied raw secret. Clipboard APIs operate in secure contexts and browsers may require user activation for writes, so the test should verify that the copy button gives visible and preferably accessible success/failure feedback. A non-urgent success notice should behave like a status live region, while an urgent token-state error should behave more like an alert. Evidence should therefore be the feedback text itself, not the clipboard contents when the clipboard contains a secret.

The evidence bundle should therefore be limited to these artifact types: a screenshot of the admin menu path and workbench page title; a redacted prompt transcript with the token replaced before saving; screenshots of the token list with row headings and statuses but with any token value masked; screenshots of invalid/expired/revoked error messages; screenshots of the redacted receipt and current-message surfaces using benign synthetic text; and a UTC-timestamped notes file listing status codes, visible texts, and pass/fail decisions. None of those artifacts requires saving the token itself.

Step-by-step admin-side test script

1. Open WordPress as the intended admin role and find the workbench through normal navigation first. Do not start with a bookmarked deep link. Record the exact menu path, whether the entry appears as a top-level or submenu item, its label text, and whether it is visible without guessing the URL. Expected result: the page is reachable by a capability-appropriate admin through a visible WordPress menu path. Failure note: if the page works only by direct URL but is missing from the admin menu for the correct role, mark discoverability failed even if the page itself loads. This matters because WordPress menu registration is supposed to be capability-based and visible in the admin menu structure. Evidence to collect: one screenshot showing the selected menu path and page title, with no token present.

1. Check for sidebar and layout blockers before generating anything. Test at minimum: desktop width around 1440 px, common laptop width around 1280 px, narrow desktop/tablet width around 1024 px, and browser zoom at 100% and 200%. Also tab through the page with keyboard only. Expected result: the generate control, any token-management list, and the workbench fields remain visible, click targets are not overlapped by the WordPress sidebar or sticky headers, and the focus order remains logical. Failure note: if a control is visually present but unreachable by pointer or keyboard, mark layout blocker, not merely a cosmetic bug. Evidence to collect: one screenshot per failing layout state, plus a short note of viewport width, zoom, and whether the failure was pointer, keyboard, or overlap-related.

1. Generate a fresh delegated testing prompt. Use a new token for this run and assign a benign run label such as DOGFOOD-E2E-2026-07-08T18:30:00Z. Expected result: the prompt is generated once, contains a delegated token intended for the workbench-only test path, and does not create a WordPress auth session for the downstream tester. Failure note: if generation leaks the token into the address bar query string, history-friendly route, or visible admin list without redaction, mark secret-exposure failure. Evidence to collect: a saved redacted prompt text file, created by immediately replacing the token value with [TOKEN_REDACTED] before saving; one masked screenshot of the page after generation if masking can be done before storage.

1. Test the prompt copy button. Click the copy control once in a normal browser context and once with keyboard activation. Expected result: copy succeeds in a secure context, the UI shows visible success feedback, and the feedback does not steal focus unexpectedly. Better result: the feedback is also announced to assistive technology as a polite status update. Failure note: if the button copies successfully but gives no visible feedback, mark feedback missing; if it silently fails in a secure user-initiated click path, mark copy failure. Evidence to collect: screenshot of the success/failure text only; do not save the clipboard contents if they include the raw token.

1. Create at least three active tokens to test list behavior. Issue: one token for project A, one for project B, and one more token for the same admin/user on project A or a second admin if available. Expected result: the active-token list shows separate rows per token instance, with enough metadata to distinguish them individually. The list should not collapse them into one row merely because they belong to the same user. Minimum useful row metadata is created time, expiry time, status, revocation state, and the associated workspace/project or purpose label. Failure note: if multiple live tokens for the same user collapse into one indistinguishable row, mark grouping failure. Evidence to collect: a masked screenshot of the token list showing row count, columns, and statuses, plus a note mapping each row to your benign run labels.

1. Test revocation without disturbing unaffected tokens. Revoke exactly one token from the active-token list. Expected result: the revoked token changes state immediately in the admin list, any receipt/status area reflects revocation, and the other active tokens remain usable. Failure note: if revocation is delayed without status feedback, or revoking one token disables every token associated with that user rather than the selected token, mark revocation scope failure. Evidence to collect: before/after masked screenshots of the active-token list and one screenshot of the downstream revoked-token message.

1. Test expiry. If the environment supports a short-TTL dogfood override, use it. If not, use the documented live 24-hour TTL and re-run after created_at + 24h + 5m, using UTC in the notes. Expected result: a token that worked earlier is now rejected as expired, while a separately generated current token still works. Failure note: if the “expired” token still validates after the TTL or if the UI cannot distinguish expired from revoked/invalid, mark expiry handling failure. Evidence to collect: UTC timestamp of creation, UTC timestamp of failed retry, and a screenshot of the expired-state message with the token never visible.

1. Test invalid-token handling deliberately. Start from a copy of the prompt, replace one character in the token locally, and attempt validation. Expected result: the UI rejects the token as invalid and the message is visibly distinct from the expired and revoked states. Better result: invalid input and time-sensitive session/token problems are announced accessibly, using status or alert semantics appropriate to severity. Failure note: if all failures collapse to the same vague “waiting” state, or if the error is not visible without devtools, mark token-state messaging failure. Evidence to collect: screenshots of the invalid, revoked, and expired states side by side, with message text transcribed into notes.

Step-by-step delegated agent and message-path test script

1. Open the delegated testing UI using the prompt exactly as designed. First try the fragment/no-typing path. If the browser or agent environment cannot preserve the fragment or cannot type into the manual field, note that explicitly. Expected result: a capable browser can validate through the fragment path or the manual field path, and the page moves past “Waiting for a valid testing token.” Failure note: if the environment cannot follow fragment links or type into the fallback field, record environment blocked rather than product failed; the public workbench explicitly tells testers to return only blocked status in that case. Evidence to collect: one screenshot of the initial waiting state and one screenshot of the post-validation state, with the token never visible.

1. Confirm the delegated UI is genuinely constrained. After validation, inspect what the delegated tester can and cannot see. Expected result: the delegated UI exposes only the testing workbench and does not create a WordPress session, does not set an admin auth cookie, and does not reveal plugin/settings/users/theme/file-editor surfaces. Failure note: if the delegated token grants general wp-admin navigation or reveals unrelated admin menus, mark privilege-boundary failure. Evidence to collect: screenshot of the constrained workbench view and a note confirming absence of normal admin surfaces.

1. Queue one project-level human-to-agent message using only benign test text. Use a synthetic message body such as DOGFOOD project message visibility check 2026-07-08T18:45:00Z. Then queue a specific-agent message if specific IDs are available. Expected result: the NeuroWikis side shows a queued message receipt with only redacted fields: outbox id, outbox status, audience, message length, fingerprint, and lifecycle path. Failure note: if the receipt replays the full message body, token, raw selector values, or database row internals, mark receipt-redaction failure. Evidence to collect: screenshot of the redacted receipt card and a notes entry recording the visible outbox id and lifecycle.

1. Test the “Copy redacted receipt summary” control. Expected result: once a message is queued, the copied text contains only the safe receipt summary and omits the raw message body, token, selector values, private payloads, and raw database values. Failure note: if copying is possible before queueing when the UI says it should not be, or if the copied text contains non-redacted data, mark receipt-copy failure. Evidence to collect: paste the copied summary into a local note and save it only if it contains the redacted fields promised by the UI.

1. Verify current-message visibility on NeuralWikis before any private-history behavior. On the agent side, check the current-message lane first, not private search first. Expected result: the newly queued message becomes visible in the current-message / agent-inbox flow, and unread current messages are surfaced before implementation or older-history retrieval. Failure note: if the message exists only in historical search or receipts but is not surfaced in the current-message lane, mark current-message visibility failure. Evidence to collect: screenshot of the current-message surface showing your benign test label and the message state, plus UTC time observed.

1. Verify acknowledgement behavior exactly as the current-message contract requires. When the current message is read, determine whether the lane requires required_response or only viewed_acknowledgement. Expected result: the agent can resolve the message under one of those two dispositions, acknowledge it as read or archived, and the downstream receipts reflect the acknowledgement while the original outbox row remains preserved. Failure note: if the message can be seen but never acknowledged, or if acknowledgement deletes or mutates the source outbox row contrary to the contract, mark ack reconciliation failure. Evidence to collect: screenshot of the pre-ack current-message state, screenshot of the post-ack receipt/notification state, and notes showing the final disposition.

1. Check the edge case where history retrieval is quota-gated but current messages should still remain visible. This is not the core dogfood path, but it is a valuable regression check because the public NeuralWikis contract explicitly says current messages, receipts, and activity remain usable even when private search is quota-gated. Expected result: even if private history/search is unavailable, current messages and acknowledgement remain available. Failure note: if a quota-gated history state hides unread current messages, mark priority inversion failure. Evidence to collect: notes or screenshots of usage/quota state and confirmation that current messages were still visible.

1. Submit the final report inside NeuroWikis.com, not in chat. Use the final workbench/report path available in the live UI. If the only live path is a queued human-to-agent message back through the testing workbench, use that. Expected result: the final report is submitted through the NeuroWikis testing UI, the admin can see redacted receipt/status for it, and any remaining worker reconciliation or external authority steps are shown as authority-gated rather than silently lost. Failure note: if the flow requires leaving the product to report results, mark in-product reporting failure. Evidence to collect: screenshot of the final submission receipt and a corresponding admin-side screenshot showing redacted status visibility.

Pass criteria, failure notes, and exact evidence bundle

A pass for this dogfood run is not “every downstream authority gate completed.” The public contracts already say worker reconciliation, dispatch review, memory promotion, and external authority receipts can remain authority-gated beyond the immediate NeuroWikis queue receipt, and NeuralWikis’ coordination contract distinguishes ordinary work from final evidence/certification gates. For this specific E2E dogfood plan, the product passes when the admin can issue a delegated prompt, the delegated tester can validate it only within the constrained testing UI, queue a safe test message, see that message surface in NeuralWikis current-message flow, acknowledge it correctly, submit a final report inside NeuroWikis, and let the admin observe redacted receipt/status plus revocation control.

Use these exact failure labels in the notes so triage is fast: discoverability failed, layout blocker, secret-exposure failure, copy failure, feedback missing, grouping failure, revocation scope failure, expiry handling failure, token-state messaging failure, privilege-boundary failure, receipt-redaction failure, receipt-copy failure, current-message visibility failure, ack reconciliation failure, priority inversion failure, and in-product reporting failure. Each failure should include UTC timestamp, browser, viewport, exact screen path, and whether the failure was reproducible twice. The evidence bundle for the full run should contain only: masked screenshots, redacted prompt text, redacted receipt text, current-message screenshots using benign synthetic text, and a UTC notes log. No token, no raw request headers, no raw clipboard dump, no HAR containing the custom token header, and no raw trace export should be shared outside the smallest trusted local workspace.

The highest-risk unresolved items, based on the public evidence, are the ones that still depend on a live authenticated session: wp-admin button discoverability, token-list grouping, exact invalid/expired/revoked UI messages, copy-feedback semantics, and sidebar/layout blockers. Everything else in the intended path already has enough public contract detail to turn into a concrete live script without exposing secrets, as long as the tester captures only masked/redacted artifacts and uses benign synthetic message bodies.