CauseScope 1.0 beta: help validate real React + Vite evidence paths

[stackloomdev]

CauseScope is preparing for stable 1.0, and the external beta validation path is now open.

Start here

• Read the beta testing guide
• Fork the no-install live lab
• Or install the current beta with pnpm add -D causescope@beta in a React + Vite application

The feedback that helps most

Please test real evidence boundaries rather than only the demo happy path:

• ordinary text and static markup should resolve to exact TypeScript source without a fabricated dynamic cause;
• selections across routes, nested components, and multiple files should not reuse stale ownership or state;
• real inputs, clicks, setters, reducers, Props, requests, and explicit React Query/Zustand adapters should show only evidence that actually exists;
• direct reselection, keyboard navigation, close/focus return, and trace export should remain usable and redacted.

An explicit unavailable result is correct when reliable evidence does not exist. A plausible guess is not.

Share safely

For setup questions or an observation that is not yet reduced, start a General discussion. For a reproducible defect, use the bug report form with a small public TypeScript fixture.

Before posting, replace private paths, URLs, organization names, identifiers, state, payloads, and request data with invented equivalents. Review screenshots, logs, source maps, browser chrome, and trace exports manually. Never post credentials, cookies, tokens, customer data, private source code, or an unredacted trace. Suspected vulnerabilities belong in private vulnerability reporting.

CauseScope remains local-first and development-only: no account, telemetry, production monitoring, hosted backend, or trace-upload service. Beta APIs may still change intentionally before stable 1.0, with every package-surface change kept reviewable by the public API snapshot.

[farfromexact]

The emphasis on unavailable instead of guessed evidence is exactly the right trust boundary for a debugging tool. For the beta, I would turn that principle into a small evaluation matrix so reports are comparable across real projects.

For each fixture, record:

• selected source range and the resolved file and line
• the evidence type, such as prop, state setter, request, reducer, or adapter
• whether the result is exact, partial, or unavailable
• why a candidate was rejected
• whether a second selection, route change, keyboard action, or closed panel reuses stale state
• whether exported traces are redacted and still explain the same result

A few adversarial fixtures would be especially valuable: duplicate component names in different files, aliased imports, a re-exported hook, nested providers, a request that has no source mapping, and a dynamic value whose cause genuinely cannot be proven. Measure false-positive rate separately from coverage; a lower coverage result is preferable if it never invents a cause.

Keeping the public API snapshot and a local-first no-upload model is a good release boundary. A short machine-readable evidence record in test output would let beta users report one deterministic failure without uploading their whole application.