Setting up Signals

Signals is part of Pathrule Studio and is enabled per workspace. Setup is proposal-first: Studio first discovers the few points that carry useful runtime context, then a person chooses what is allowed into the codebase.

Turn it on

1. Open the workspace you want to monitor in Pathrule Studio.
2. Enable Signals for that workspace and start the /signals setup.
3. Studio asks your coding agent for a focused, read-only scan. The agent reads the project structure, entry points, existing error boundaries and important business milestones. It does not modify files, run the app or run tests during this pass.
4. Review the proposal. A typical project produces one initialization point and roughly 3 to 12 error or event points. Each proposal names its file, workspace node, structural flow, rationale and confidence.
5. Approve the points you want. Studio creates a workspace ingest connection, vendors its dependency-free single-file SDK and asks the coding agent to wire only the approved points under your normal permission policy.

There is no package-registry install and no analytics account to configure. The code change is narrow and inspectable: one initialization call plus the points you approved. On Solo, one workspace can run Signals at a time; see Plans, quotas and retention for the details.

What can be proposed

Signals has two runtime point types:

• Error: a failure worth surfacing, such as an unhandled rejection, an error boundary or a failed critical operation.
• Event: an important structural milestone, such as checkout completed, a job finished or feedback submitted.

Each point may carry a structural flow such as checkout or auth, plus the workspace-relative node path that owns it. Setup does not propose users, sessions, funnels, request bodies, secrets, tokens or personal data.

What the SDK guarantees

The vendored SDK is designed to stay out of the host product's failure path. It bounds and coalesces queued work, redacts unsafe values, retries with backoff and swallows transport failure. Signals never throws a transport or quota failure into the application it observes.

What you see

Each incident shows up in the Signals view with:

• Status. Active, observing a newer release, quiet, runtime verified, or recurred.
• What happened. The message, environment, release, count, and when it was first and last seen.
• Why here. The resolved node path and the flow it belongs to.
• Context supplied. The exact rules and memories that were attached, with their versions.
• Runtime outcome. The production evidence gathered after a fix, once observation has started.

From incident to task

When an incident crosses a worthiness threshold, Signals hands it to the same Tasks flow you already use, with a Context Brief in the card prompt. Everything after you start the card is unchanged. See How the loop works for the full path from a production event to a verified fix.

Availability

Signals runs in Pathrule Studio.

What to read next

• Signals overview for the product story.
• How the loop works for detection, context, and verification.