/wbDebug — Live Demo ()
What /wbDebug would actually produce on wb-labs today (2026-05-04). The candidate symptoms below are real — drawn from the parked tech debt and known issues currently in the workspace.
1. Live target
| Field | Live value |
|---|---|
| Workspace state | Many uncommitted docs files in frontEnd/wbc-ui/core2/packages/wb-flow/templates/; no recent code edits in core2/ |
| Known live symptoms (from memory) | (1) WBDataViewer apiResponse_ stale on route change; (2) wbc-ui2-cdn dist-folder mismatch; (3) cache-loader unused but still referenced in core2 packages |
| Recent test runs | None this session — /wbDebug would have no fresh test output to draw on |
| Memory available | All 12 leaf memory files; especially project_wbdataviewer_apiResponse.md, project_pkg_dist_mismatch.md, wbc-ui2-tech-debt.md |
/wbDebug is the most memory-dependent command in this group. It reads code, but the interpretation of what's broken often lives in memory. The dist-folder mismatch is "a bug" if you don't know about the parked decision; it's "expected current state" once you read the memory note.
2. What each input form would resolve to today
| Input | Live resolution |
|---|---|
"WBDataViewer apiResponse_ stale" | Maps to core2/packages/wb-dataviewer/src/WBDataViewer.vue + memory note. Diagnosis is concrete. |
"Cannot resolve dist/index.js" | Maps to the dist-folder mismatch. Memory says "do not fix in isolation." |
"WBC.js is hard to extend" | Honest "no concrete symptom; this is a design opinion." Suggests /wbExplain or /wbReview instead. |
| Pasted vue/vite stack trace pointing at any core2 package | Parses, follows to source, cross-checks memory. |
"all my tests fail" | Refuse. /wbDebug is single-failure-at-a-time. Suggest /wbTest to enumerate first. |
3. Per-input behavior, applied live
/wbDebug has no flags. The "behavior matrix" here is by input shape:
| Input shape | Live behavior |
|---|---|
| Symptom string + memory match | Diagnosis cites memory; recommends consistent action. |
| Symptom string + no memory match | Diagnosis cites source code only; flags absence of memory record as something the user should consider adding after the fix. |
| Stack trace + matching memory | Diagnosis names the parked nature and suggests the workaround, not the patch. |
| Stack trace + no memory | Standard frame-walk diagnosis. |
| Test name (no current failure run) | Reads the test source and the code under test; produces a prospective diagnosis ("this test would fail under conditions X, Y"). |
4. Pipelines
/wbDebug Live Execution Simulator
The apiResponse_ stale-cache, diagnosed live
/wbDebug "WBDataViewer apiResponse_ stale on route change"> /wbDebug "WBDataViewer apiResponse_ stale on route change"[DIAGNOSE] Symptom: data viewer shows previous project's response
after navigation.
[CONTEXT] Reading project_wbdataviewer_apiResponse.md (memory)...
Pattern documented: apiResponse_ caches fetched data so
subsequent project changes don't refire the network.
[CONTEXT] Reading core2/packages/wb-dataviewer/src/WBDataViewer.vue...
[CONTEXT] Reading core2/packages/wb-dataviewer/src/App.vue (consumer)...
## Theory
The watcher on `props.project` reads `apiResponse_.value` first and
returns early if it's truthy. That's a presence check, not a
freshness check. The cache is filled on first fetch and never
invalidated when the project changes.
## Evidence chain
1. WBDataViewer.vue:34 — `const apiResponse_ = ref(null)` (instance-scoped).
2. WBDataViewer.vue:51 — watcher early-returns on
`if (apiResponse_.value) return apiResponse_.value`.
3. There is no key comparison. The watcher never asks "is this
cached response *for the current project*?"
4. Memory note describes the cache as "fetched-once-per-component"
— which is technically what the code does, but the assumed
semantics ("project changes blow the cache implicitly via
route remount") only holds if the route remounts the component.
In production, the App.vue parent does not remount on every
project change.
## Why production fails but the memory note seems coherent
The memory note assumes route remount blows the cache. But in App.vue,
the WBDataViewer is mounted once and receives `project` as a prop. The
prop changes in place; no remount; cache survives. The note is
coherent under one mental model and wrong under the actual mounting
shape.
## Recommended next step (do not fix here — propose a plan row)
Title: WBDataViewer.apiResponse_ — invalidate on project key change
Files: core2/packages/wb-dataviewer/src/WBDataViewer.vue:34, :51
Fix shape: change cache from `ref<T|null>` to
`ref<{key:string, value:T} | null>`. Watcher checks
`cached?.key === newProject` before returning.
Verify: navigate between two projects in the demo app; second
project's response renders without manual refresh.
Memory follow-up: update project_wbdataviewer_apiResponse.md to
record the key-match invariant.
[NO MUTATION] Diagnosis only.
⚠️ Note: This is the most useful single-bug example in the workspace. The memory describes the *pattern*; `/wbDebug` describes what's *wrong* with the current implementation:
💠 Pipeline The apiResponse_ stale-cache, diagnosed live
This is the most useful single-bug example in the workspace. The memory describes the pattern; /wbDebug describes what's wrong with the current implementation:
💠 Pipeline The dist-folder mismatch, diagnosed honestly
User pastes a build error pointing at core2/packages/wbc-ui2-cdn/dist/index.js:
💠 Pipeline The "test would fail under X" prospective diagnosis
User wants to understand what conditions break a test, before they run it:
5. What would refuse today
| Trigger | Live response |
|---|---|
/wbDebug with no symptom | Halt. Provide a stack trace, error string, test name, or symptom description. |
/wbDebug "fix the apiResponse_ thing" | Polite refuse — /wbDebug diagnoses; /wbWork fixes. Suggest plan + work flow. |
/wbDebug "the build is broken" | Halt. Too vague. Ask for a specific error line or behavior description. |
/wbDebug on a stack trace pointing entirely at vue's internals (no user code frames) | Diagnose the call site if discoverable; flag that the upstream may be the cause but is out of scope. |
/wbDebug "all tests fail" | Refuse. Run /wbTest to enumerate; come back with one failure name. |
/wbDebug https://github.com/.../issues/42 | Refuse. No external fetch. Paste the issue body into the argument. |
The pattern: /wbDebug is a single-failure, evidence-citing, no-mutation diagnostic. It reads memory before proposing fixes, refuses to patch when memory says "parked," and is honest when the situation is too vague to diagnose. The output is always a handoff document — never an applied change.