Ask mode is for research and answers only. Bright won’t create issues, documents, or plans while you’re here.

​
Example: error-tracking research

You run a small API in production, and you hear about failures from users before you see them in logs. Before writing any code, you want an engineering answer: does a dedicated error-tracking service earn its keep, and which one fits a small project? Start a new session, switch to Ask, and paste:

​
Watch the loop start

Expand the thought/work section. Bright clarifies objectives, then typically:
  1. Assigns an Explorer to inspect your repo and stack (framework, error handling today)
  2. Assigns a Researcher to compare error-tracking services on setup effort and free tiers
  3. Runs those tracks in parallel

​
What the research recommends

For this example, Bright lands on a simple call:
  • A dedicated service beats logs alone for production failures: grouped errors with stack traces and source context, release tagging, and alerts when a new error class appears
  • Sentry fits a small project: free tier + paid tiers (see sentry.io/pricing) and a maintained Node.js SDK
  • Skip self-hosting for now. It is operationally heavier than the problem justifies at this size
Bright also flags tradeoffs — for example, what you give up by not self-hosting, and when plain structured logging is still the right answer.

​
Suggested wiring path

1

Create the Sentry project

Create your org and project in the Sentry dashboard, and note the DSN.
2

Add env vars

Store SENTRY_DSN server-side only.
3

Install the SDK

Add the Sentry Node SDK and wire the error handler middleware.
4

Verify with a test error

Trigger one handled test error and confirm it shows up with a stack trace.
Keep the DSN server-side. Scrub secrets from anything you attach to an error event, and alert on new error classes, not every occurrence.

​
Next

Turn the recommendation into a reviewable plan in Plan mode.