quiver-cli 1.3.0 → 2.0.0

package/template/.agents/skills/integrations/langfuse/references/v4-project-migration.md

@@ -1,73 +0,0 @@
----
-name: langfuse-v4-project-migration
-description: Prepare an application and Langfuse project for v4 by upgrading ingestion and API usage, migrating legacy evaluators, and moving exports to the enriched observation schema.
-metadata:
-  required_access:
-    - CODEBASE
-    - LANGFUSE_PROJECT_INTERFACE
-    - LANGFUSE_PROJECT_SCRIPT
----
-
-# Langfuse v4 project migration
-
-## Sources of truth
-
-Fetch only the pages needed for the surfaces found:
-
-- [V4 overview](https://langfuse.com/docs/v4) and [compatibility](https://langfuse.com/docs/compatibility)
-- [SDK upgrade paths](https://langfuse.com/docs/observability/sdk/upgrade-path)
-- [Custom ingestion migration](https://langfuse.com/integrations/native/opentelemetry/migration-to-v4)
-- [Deprecated API migration](https://langfuse.com/faq/all/deprecated-api-migration)
-- [Evaluator migration](https://langfuse.com/faq/all/llm-as-a-judge-migration)
-- [Evaluation Rules](https://api.reference.langfuse.com/#tag/unstableevaluationrules) and [Evaluators](https://api.reference.langfuse.com/#tag/unstableevaluators) APIs
-- Export migrations: [Blob Storage](https://langfuse.com/docs/api-and-data-platform/features/export-to-blob-storage#upgrade-path), [Mixpanel](https://langfuse.com/integrations/analytics/mixpanel#migrate-export-source), and [PostHog](https://langfuse.com/integrations/analytics/posthog#migrate-export-source)
-
-Discover unstable schemas before use.
-
-## Choose the execution mode
-
-- Confirm the target host and project before project reads or writes. Never request secrets in chat or commit them.
-- Prefer an available project interface. Otherwise use the [CLI](https://langfuse.com/docs/api-and-data-platform/features/cli), starting with `api __schema` and action `--help`.
-- Without project access, enter **code-only mode**: complete verifiable repository work, do not infer evaluator or export state, and mark every project-dependent result blocked.
-- Without codebase access, inspect the project and return an exact code handoff; do not mark repository work ready.
-
-## Migrate the codebase
-
-- Inventory every Langfuse SDK, integration, OTEL exporter, initialization site, lockfile, raw request, generated client, script, notebook, and CI call.
-- Upgrade to the latest stable SDK major required by the current docs and apply every applicable breaking change. Record both declared and resolved versions; update an existing lockfile.
-- Put overall input/output on the root observation and propagate every trace attribute needed to filter or aggregate observations.
-- For raw `/api/public/ingestion`, use the current Langfuse SDK in Python or JS/TS. For other languages, use the language's native OpenTelemetry API and follow the custom-ingestion guide.
-- When replacing synchronous ingestion, assess buffering, retries, flushing, shutdown, and error propagation. Do not claim identical delivery semantics without verification.
-- For other deprecated APIs, migrate the path, parameters, pagination, filters, field groups, response parsing, and downstream consumer together using the deprecated-API guide.
-- Check self-hosted compatibility before replacing calls; report code targeting a v3 server as blocked on the server upgrade.
-
-## Migrate evaluators
-
-- Inventory all active evaluators and rules, inspect each referenced definition, and report inactive rules without reactivating them.
-- Check the Evaluators UI on the confirmed target host for active **Legacy** rows ([open in Langfuse Cloud](https://cloud.langfuse.com/project/~/evals)); public interfaces may not expose every legacy target.
-- For each inspected active legacy rule, record its filters, sampling, mappings, representative payloads, one observation or experiment successor, required code changes, and cutover test.
-- Label this a **project-verified contract** only when the rule and representative observations were inspected. Label code-only suggestions **candidate targets**, never project state.
-- Consolidate all required evaluator variables and filter attributes onto the one target observation. Observation evaluators cannot read siblings or children.
-- Create or update the successor disabled, validate it on newly ingested data, obtain approval before enabling it, compare scores and logs, then disable rather than delete the legacy rule.
-
-### Deprecated trace input/output escape hatch
-
-- Default to removing deprecated trace input/output and migrating the evaluator to root-observation input/output.
-- Never add or retain `set_current_trace_io()`, `span.set_trace_io()`, `setActiveTraceIO()`, `span.setTraceIO()`, or equivalent compatibility merely because a legacy rule exists or project access is unavailable.
-- Offer compatibility only when automatic migration is currently impossible or the user explicitly insists on preserving the legacy evaluator unchanged after being warned that trace input/output is deprecated.
-- Even then, require explicit confirmation before changing code, mark the evaluator migration `manual action` or `blocked`, and document the condition for removing the escape hatch. Do not present it as the recommended migration.
-
-## Migrate exports
-
-- Inventory Blob Storage, Mixpanel, PostHog, and other sources in **Project Settings > Integrations**.
-- Follow each documented dual-source transition. Enabling dual output is additive; enriched-only stops legacy output and requires explicit downstream-owner confirmation.
-- Validate warehouse schemas, paths, joins, dashboards, transformations, alerts, and historical-data handling. Keep every consumer on one shape during dual mode.
-- Change only the source; preserve credentials, schedules, prefixes, formats, field groups, and secrets. Report the area `manual action` until downstream consumers are confirmed.
-
-## Validate and report
-
-- Test applicable hierarchy, root input/output, propagated attributes, public/release/environment behavior, API pagination and parsing, delivery semantics, and absence of deprecated calls.
-- Before production cutover, send representative traces from the migrated instrumentation to a non-production Langfuse project and inspect the resulting observations there. Mocked tests do not verify backend ingestion or project behavior.
-- Re-read rules and integrations after writes. Preserve disabled legacy rules for rollback; never claim completion without checking the Evaluators UI on the target host for legacy rows.
-- The readiness report must contain exactly these seven rows, each marked `ready`, `changed`, `manual action`, or `blocked`: project access; SDK/instrumentation; trace evaluators; dataset evaluators; direct APIs; exports; verification/rollback.
-- In evaluator rows, separate contracts verified against project data from targets suggested only by code inspection. For every row not marked `ready`, include the blocker, next action, and a direct UI link when applicable.

package/template/.agents/skills/integrations/posthog/SKILL.md

@@ -1,102 +0,0 @@
----
-name: posthog
-description: Add and use PostHog in Next.js (App Router) applications. Use when needing to (1) integrate PostHog analytics, (2) set up LLM analytics for AI SDK / Anthropic generations, (3) add error tracking, or (4) implement feature flags. Covers SDK setup, user identification, event capture, exception tracking, source maps, and server/client flag evaluation. Curated for a Next.js + Vercel AI SDK stack.
-license: MIT. Curated from PostHog's official skills (github.com/PostHog/skills).
-allowed-tools:
-  - WebFetch(domain:posthog.com)
-  - Bash(curl *posthog.com/*)
-  - Read(references/**)
----
-
-# PostHog
-
-This skill helps you add and use PostHog effectively in Next.js App Router applications across four workflows: product analytics integration, LLM analytics, error tracking, and feature flags.
-
-It is curated for a Next.js + Vercel AI SDK stack. For providers, frameworks, or surfaces not covered here, fetch the current docs (see "Documentation" below) before implementing.
-
-## Core principles
-
-Follow these for ALL PostHog work:
-
-1. **Documentation first**: NEVER implement from memory. PostHog SDKs change frequently. Read the matching reference file below, and fetch current docs when something is unclear or unlisted.
-2. **Environment variables**: Always read PostHog keys and host URLs from environment variables. Never hardcode them. The host is `https://us.i.posthog.com` (US) or `https://eu.i.posthog.com` (EU).
-3. **Minimal changes**: Add PostHog code alongside existing logic. Don't replace or restructure existing code.
-4. **No PII in event properties**: Never put emails, names, phone numbers, addresses, IPs, or user-generated content in `capture()` properties. PII belongs in `identify()` person properties. Safe event properties are metadata (e.g. `message_length`, `form_type`, boolean flags).
-
-## Use-case specific references
-
-Pick the workflow, then read the listed references before implementing.
-
-### 1. Integration (product analytics)
-
-Add PostHog analytics to a Next.js App Router app. Start here for any new setup.
-
-- `references/integration-nextjs.md` — Next.js integration docs (init, pageviews, capture)
-- `references/integration-example.md` — full example project showing the target pattern
-- `references/identify-users.md` — identifying users on login/signup
-- Setup workflow (in order): `references/integration-step-1-begin.md` → `references/integration-step-2-edit.md` → `references/integration-step-3-revise.md` → `references/integration-step-4-conclude.md`
-
-Key guidelines:
-- For Next.js 15.3+, initialize PostHog in `instrumentation-client.ts` for the simplest setup.
-- Identify users during login and signup. If both frontend and backend exist, pass the client session and distinct ID via `X-POSTHOG-DISTINCT-ID` and `X-POSTHOG-SESSION-ID` headers to keep correlation.
-- Add capture in event handlers where the user action occurs, NOT in `useEffect` reacting to state.
-
-### 2. LLM analytics (Vercel AI SDK / Anthropic)
-
-Instrument LLM generations to capture tokens, model, latency, and cost. Matches an AI SDK stack.
-
-- `references/llm-analytics-basics.md` — concepts and what gets captured
-- `references/llm-analytics-vercel-ai.md` — Vercel AI SDK setup via OpenTelemetry + `@posthog/ai` (primary path)
-- `references/llm-analytics-anthropic.md` — Anthropic SDK instrumentation
-- `references/llm-analytics-manual-capture.md` — generic fallback for any provider via manual `$ai_generation` events
-- `references/llm-analytics-traces.md` — grouping generations into traces
-- `references/llm-analytics-costs.md` — cost calculation
-
-Key guidelines:
-- The Vercel AI SDK path uses `@posthog/ai/otel` `PostHogTraceExporter` + OpenTelemetry; pass `experimental_telemetry` (with `posthog_distinct_id` metadata) on AI SDK calls. The SDKs do NOT proxy your LLM calls; they only send analytics in the background.
-- Only instrument provider(s) actually present in the codebase. One provider at a time.
-- Link generations to identified users via distinct IDs where possible.
-
-### 3. Error tracking
-
-Capture exceptions with resolved stack traces.
-
-- `references/error-tracking-nextjs.md` — Next.js error tracking install
-- `references/error-tracking-monitoring.md` — monitor and search issues
-- `references/error-tracking-source-maps.md` — upload source maps so traces resolve to original source
-- `references/error-tracking-alerts.md` — error tracking alerts
-- `references/error-tracking-assigning-issues.md` — assign issues to teammates
-- `references/error-tracking-fingerprints.md` — custom fingerprints for grouping
-
-Key guidelines:
-- Enable exception autocapture in SDK init before adding manual captures.
-- Upload source maps, otherwise stack traces point at minified bundles.
-- Use `captureException()` at error boundaries and catch blocks for errors that don't reach the global handler.
-
-### 4. Feature flags
-
-Evaluate boolean and multivariate flags, server- and client-side.
-
-- `references/feature-flags-best-practices.md` — flag best practices
-- `references/feature-flags-react.md` — React hooks (`useFeatureFlagEnabled`, `useFeatureFlagPayload`)
-
-Key guidelines:
-- Default to boolean flag checks unless multivariate is explicitly requested.
-- Prefer server-side evaluation to avoid UI flicker: in Server Components / Route Handlers use the `posthog-node` SDK (`getFeatureFlag` / `getAllFlags`, then `await posthog.shutdown()`), and pass values to client components as props.
-- The React hooks work WITHOUT `PostHogProvider` if `posthog-js` is already initialized (e.g. via `instrumentation-client.ts`). Don't add a provider just for flags.
-- Client-side hooks may return `undefined` while flags load — handle the loading state.
-- If a PostHog MCP server is connected, use its flag-management tools to create/list/update flags directly instead of asking the user to do it in the dashboard.
-
-## Documentation
-
-When a reference doesn't cover the case, fetch current PostHog docs. Prefer your native web fetch/search tools over `curl`.
-
-- Browse `https://posthog.com/docs` or fetch a page as markdown by appending `.md` to its path:
-  ```bash
-  curl -s "https://posthog.com/docs/libraries/next-js.md"
-  ```
-- The full doc index lives at `https://posthog.com/llms.txt`.
-
-## Attribution
-
-Curated from PostHog's official skills collection (`github.com/PostHog/skills`, MIT). Reference files are sourced from the `integration`, `llm-analytics`, `error-tracking`, and `feature-flags` skills, trimmed to the Next.js + AI SDK stack.

package/template/.agents/skills/integrations/posthog/references/error-tracking-alerts.md

@@ -1,63 +0,0 @@
-# Send error tracking alerts - Docs
-
-To stay on top of issues, you can set up alerts. These enable you to post to Slack, Discord, Teams, or an HTTP Webhook when an issue is created or reopened.
-
-## Issue created or reopened
-
-To alert when an issue is created or reopened, go to [error tracking's configuration page](https://app.posthog.com/error_tracking?activeTab=configuration#selectedSetting=error-tracking-alerting) and click **Alerting**. This shows you a list of existing alerts. Clicking **New notification** brings you to a page to create a new one.
-
-![Error tracking alerting](https://res.cloudinary.com/dmukukwp6/image/upload/error_alerts_create_light_1a05deef21.png)![Error tracking alerting](https://res.cloudinary.com/dmukukwp6/image/upload/error_alerts_create_dark_7585087b18.png)
-
-Choosing an option brings you to a page to configure the alert. This may require setting up the Slack integration or pasting in a webhook URL. Once done, you can test the alert by clicking **Test function** and then finalize by clicking **Create & enable**.
-
-This will then send alerts to your chosen destination when an issue is created or reopened like this:
-
-## Issue properties and assignments
-
-You can filter an alert based on the properties of an issue. This is useful for notifying a specific team when they have been auto assigned an issue using [auto assignment rules](/docs/error-tracking/managing-issues.md#auto-assignment-rules).
-
-![Error tracking alert assignee filtering](https://res.cloudinary.com/dmukukwp6/image/upload/assignee_filter_light_e575af6512.png)![Error tracking alert assignee filtering](https://res.cloudinary.com/dmukukwp6/image/upload/assignee_filter_dark_9a8907af03.png)
-
-## Spike alerts
-
-PostHog can also alert you when an existing issue suddenly spikes in volume - for example, after a bad deploy. This works differently from issue-created alerts. Instead of triggering when a new issue is first seen, spike alerts fire when an issue's error rate significantly exceeds its historical baseline.
-
-See the [spike detection guide](/docs/error-tracking/spikes.md) to learn how it works and how to configure it.
-
-## Other alerting options
-
-Since error tracking works by capturing `$exception` events, PostHog features that trigger by events can play a role in alerts too.
-
-### Real time destinations
-
-The first way is using [real time destinations](/docs/cdp/destinations.md). This enables you to send events (like `$exception`) to other tools as soon as they are ingested.
-
-To create a real time destination, go to the [data pipelines tab](https://app.posthog.com/data-management/destinations) in PostHog, click **\+ New**, and then select **Destination**. Choose your destination and press **\+ Create**.
-
-On the destination creation screen, make sure to add an event matcher for the `$exception` event, filter for the properties you want, and set the trigger options.
-
-![Real time destination](https://res.cloudinary.com/dmukukwp6/image/upload/http_error_alert_light_9898376c56.png)![Real time destination](https://res.cloudinary.com/dmukukwp6/image/upload/http_error_alert_dark_7705f0e575.png)
-
-Check out our [real time destinations docs](/docs/cdp/destinations.md) for more information.
-
-### Trend alerts
-
-You can also visualize your `$exception` events using [trends](/docs/product-analytics/trends/overview.md). Once you create a trend insight, click the **Alerts** button at the top of the insight and then **New alert**.
-
-Here you can set alerts for event volume value, increase, or decrease.
-
-![Insight alert](https://res.cloudinary.com/dmukukwp6/image/upload/Clean_Shot_2025_04_08_at_14_26_43_2x_4ef6402556.png)![Insight alert](https://res.cloudinary.com/dmukukwp6/image/upload/Clean_Shot_2025_04_08_at_14_25_35_2x_f36353143b.png)
-
-This sends an email notification to the user you choose. Check out our [alerts docs](/docs/alerts.md) for more information.
-
-**Can't find your alert?**
-
-If you'd like a destination to be added that we don't yet support, [let us know in-app](https://app.posthog.com/project/2#panel=support%3Afeedback%3Aerror_tracking%3A%3Afalse).
-
-### Community questions
-
-Ask a question
-
-### Was this page useful?
-
-HelpfulCould be better

package/template/.agents/skills/integrations/posthog/references/error-tracking-assigning-issues.md

@@ -1,77 +0,0 @@
-# Assign issues to teammates - Docs
-
-Error tracking enables you to assign issues to specific PostHog [roles](https://app.posthog.com/settings/organization-roles) or teammates. This helps your team find relevant issues through **filtering**. You can also set up team-specific **alerting** to notify them when assigned issues are created or reopened.
-
-## Assign issues
-
-You can manually assign issues as you triage them in the UI. This can be done both in the issue list and issue detail pages.
-
-![Error tracking assignment UI](https://res.cloudinary.com/dmukukwp6/image/upload/assignment_ui_light_109b2bf454.png)![Error tracking assignment UI](https://res.cloudinary.com/dmukukwp6/image/upload/assignment_ui_dark_4682b2ac80.png)
-
-1.  In your error tracking [issue list](https://app.posthog.com/error_tracking), click the **unassigned** selector under each issue to assign it to a role or user.
-
-2.  On the detail page of each issue, click the **Assignee** selector to assign it to a role or user.
-
-Want to assign issues to a **team** rather than an individual teammate? You can create a role in [your project settings](https://app.posthog.com/settings/organization-roles).
-
-![Error tracking role assignees](https://res.cloudinary.com/dmukukwp6/image/upload/roles_light_6c7ea17be9.png)![Error tracking role assignees](https://res.cloudinary.com/dmukukwp6/image/upload/roles_dark_f721b94577.png)
-
-## Automatic issue assignment
-
-You can set up automatic issue assignment through a set of rules. This can be configured in the [error tracking settings](https://app.posthog.com/error_tracking?activeTab=configuration#selectedSetting=error-tracking-auto-assignment) using **auto assignment rules**.
-
-![Error tracking auto assignment rules](https://res.cloudinary.com/dmukukwp6/image/upload/assignment_rules_light_1cf9a2437a.png)![Error tracking auto assignment rules](https://res.cloudinary.com/dmukukwp6/image/upload/assignment_rules_dark_11e0830b0c.png)
-
-Assignment conditions are evaluated against the properties of the exception event that created the issue. Because assignment rules are evaluated during ingestion, the stack trace (if present) will be unminified, which enables filtering on exception properties such as function name and source file.
-
-Issues can be automatically assigned to a **role** or **user** by configuring a set of filters. These filters can be configured to match **any** or **all** of the criteria.
-
-You can configure automatic assignment to filter on any [event property](/docs/data/events.md) in PostHog. When there are multiple values for a property, the filters return true if it matches **any** of the values. For example, if you have multiple `exception_functions` values, the filters returns true if it matches **any** of the functions.
-
-Here are some common properties you can filter on:
-
-| Property | Event property | Description |
-| --- | --- | --- |
-| Exception type | $exception_types | The type of exception(s) that occurred |
-| Exception message | $exception_values | The message(s) detected on the error |
-| Exception function | $exception_functions | The function(s) where the exception occurred |
-| Exception source | $exception_sources | The source file(s) where the exception occurred |
-| Exception was handled | $exception_handled | Whether the exception was handled by the application |
-| Device type | $device_type | The type of device that the error occurred on |
-| Browser | $browser | The browser that the error occurred in |
-| Current URL | $current_url | The URL that the error occurred on |
-| Feature flag | $feature_flag | The feature flag that the error occurred on |
-
-You can also set custom properties on the error tracking event to filter on. For example, setting a custom `params_received` property to provide more context or debug information.
-
-### Order of issue assignment rules
-
-Issue assignment filters are evaluated in the order they are configured. They can also be reordered once created. The first filter that matches is used to assign the issue. This means you should configure the most specific filters first, and then the more general filters later.
-
-### Disabled assignment rules
-
-Assignment rules can become disabled if an error occurs during ingestion. When a rule is disabled, a banner displays the original error message. To re-enable the rule, edit it to fix the problem and save your changes. If the issue persists, reach out to support.
-
-### Alerting based on assignment
-
-A common use case for automatic issue assignment is to alert assignees of new issues. Once the issues are automatically assigned, you can set up alerts to notify the assignee. See the [alerts](/docs/error-tracking/alerts.md) guide for more information.
-
-## Create external issues
-
-You can also create issues in external tracking systems like GitHub Issues, Linear, GitLab, or Jira.
-
-First, set up an [integration](/docs/error-tracking/integrations.md) with your tracking system. Then, from an issue's details page, under **External references**, click **Create issue**.
-
-![Error tracking create issue in external tracking system](https://res.cloudinary.com/dmukukwp6/image/upload/create_issue_error_light_b89cd91da1.png)![Error tracking create issue in external tracking system](https://res.cloudinary.com/dmukukwp6/image/upload/create_issue_error_dark_7d158087f8.png)
-
-The new issue will have a partial stack trace and a link to the issue in PostHog.
-
-> If you use another issue tracking system and would like to request it, [let us know in-app](https://app.posthog.com#panel=support%3Afeedback%3Aerror_tracking%3Alow%3Atrue).
-
-### Community questions
-
-Ask a question
-
-### Was this page useful?
-
-HelpfulCould be better

package/template/.agents/skills/integrations/posthog/references/error-tracking-fingerprints.md

@@ -1,57 +0,0 @@
-# Fingerprints - Docs
-
-Every captured exception is assigned a fingerprint. This fingerprint is used to group similar exceptions into issues. This page covers how fingerprints are generated, how they're used, and how you can override them when capturing exceptions.
-
-## Fingerprint and issue grouping
-
-Every exception has a fingerprint, whether generated or defined by the user. Each fingerprint links to exactly one issue. Exceptions that share the same fingerprint define an issue.
-
-Multiple different fingerprints can point to the same issue (a many-to-one relationship) if you [merge issues](/docs/error-tracking/managing-issues.md#merging-issues).
-
-## How are fingerprints generated?
-
-Fingerprints are built iteratively using components of the exception event. The flowchart below shows how fingerprints are generated.
-
-flowchart LR A\[Add exception type to fingerprint\] --> B{Stack trace<br/>available?} B -->|No| C\[Add error message to fingerprint\] C --> D\[Final fingerprint\] B -->|Yes| E{In-app frames<br/>exist?} E -->|No| F\[Add first frame to fingerprint\] E -->|Yes| G\[Add in-app frame to fingerprint<br/>Priority: resolved > unresolved\] F --> D G --> D
-
-The flowchart in text
-
-Fingerprints are generated by considering the following in combination:
-
-1.  The exception type
-2.  If there's no resolved stack trace, add the error message to the fingerprint
-3.  If there are stack traces but no in-app frames (frames from your code, not a dependency), use the first frame of the stack trace
-4.  If there are stack traces, in-app frames, and source maps available, use the resolved in-app stack frames
-5.  If there are stack traces, in-app frames, and source maps *not* available, use the first in-app stack frame
-
-In some languages, like Python, one error can trigger another, creating a chain of linked exceptions. PostHog records the entire chain in the event and generates a single fingerprint for it.
-
-### Ensuring accurate fingerprints
-
-[Resolved stack traces](/docs/error-tracking/stack-traces.md) are critical for accurate fingerprinting. Without accurate stack traces, PostHog cannot group exceptions consistently. If you have not uploaded source maps, follow the [source map guide](/docs/error-tracking/upload-source-maps.md) to do so.
-
-This also means that if the exception **type** or **message** changes from one version to the next, the fingerprint will change.
-
-## When are generated fingerprints used?
-
-Fingerprints are used to group similar exceptions into issues automatically. Automatic issue grouping is only done when:
-
--   No [issue grouping rules](/docs/error-tracking/grouping-issues.md) are applied
--   No [issue merging](/docs/error-tracking/managing-issues.md#merging-issues) has been configured
--   No [custom fingerprint](#customizing-fingerprints) is set during capture
-
-You can find details about how issue grouping works in the [issues and exceptions](/docs/error-tracking/issues-and-exceptions.md) guide.
-
-## Customizing fingerprints
-
-Fingerprints can be manually set during exception capture. This is a very useful way to group exceptions that are not related to each other. You can find examples of how to do this in the [custom issue grouping](/docs/error-tracking/grouping-issues.md#option-2-client-side-fingerprint) section.
-
-You can also learn more about grouping issues using rules in the [grouping issues](/docs/error-tracking/grouping-issues.md) guide.
-
-### Community questions
-
-Ask a question
-
-### Was this page useful?
-
-HelpfulCould be better

package/template/.agents/skills/integrations/posthog/references/error-tracking-monitoring.md

@@ -1,140 +0,0 @@
-# Monitor and search issues - Docs
-
-This guide covers how to find the most relevant, urgent, and impactful issues in your error tracking using the [issues page](https://app.posthog.com/error_tracking).
-
-## Monitoring issues
-
-When you're monitoring issues in your project, there are generally two common workflows:
-
--   You're exploring issues to identify impactful and problematic areas. You should use sorting features.
--   You're looking for issues assigned to you to resolve them. You should filter by the `Assigned to` property.
-
-### Sorting issues
-
-Issues can be sorted by the following properties:
-
-| Property | Description |
-| --- | --- |
-| Last seen | The issue that has the most recent exception |
-| First seen | The issue that has the oldest exception |
-| Occurrences | The number of exceptions in the issue |
-| Users | The number of unique users affected by the issue |
-| Sessions | The number of unique sessions affected by the issue |
-
-Sorting by **last seen** and **occurrences** are great ways to get a general sense of issues in your project. Sorting by **users** and **sessions** is great to find the most impactful issues if you're using other [filters](#finding-specific-issues) to narrow down your results.
-
-### Monitoring issues assigned to you
-
-You can filter issues by the **Assigned to** property to find issues assigned to you. This is especially useful if you configure [automatic issue assignment](/docs/error-tracking/assigning-issues.md) and configure [alerts](/docs/error-tracking/alerts.md) to notify you when new issues are created.
-
-## Finding specific issues
-
-You can use the search bar at the top of the [issue page](https://app.posthog.com/error_tracking) to filter issues based on the properties of the exceptions in that issue.
-
-Search results are matched based on [properties of exception events](/docs/error-tracking/issues-and-exceptions.md) grouped into the issues. For example, if you search for "TypeError", we show you all issues where *any* exception grouped into the issue has a type of "TypeError".
-
-**Unrelated results**
-
-You may see seemingly unrelated issues in your search results because your search term matches an exception in the issue group. For example, you may see an issues named `RefreshError` when searching "schema", because a `get_schema` method appears on the exception stack traces.
-
-### Filtering modes
-
-The search bar provides two modes of filtering:
-
-#### 1\. Exact property filtering
-
-This operates like property filters elsewhere in PostHog, enabling you to add terms like `where 'http_referer' is set` or `where 'library' equals 'web'`. You add a property filter by clicking the property name shown here:
-
-![Adding a property to the property filter](https://res.cloudinary.com/dmukukwp6/image/upload/filtering_issues_light_2b2dd25208.png)![Adding a property to the property filter](https://res.cloudinary.com/dmukukwp6/image/upload/filtering_issues_dark_17d1e67da6.png)
-
-Added property filters look like this:
-
-![Search bar with property filter](https://res.cloudinary.com/dmukukwp6/image/upload/added_property_filter_1e823a16e9.png)![Search bar with property filter](https://res.cloudinary.com/dmukukwp6/image/upload/property_filter_added_dark_2d4c065baa.png)
-
-The results of both of these filter types (property filters and freeform search) are combined with `AND` logic, such that only exceptions that match all filters are included in the search results.
-
-#### 2\. Freeform text search
-
-This does text matching for a subset of the error tracking specific properties of the exception event. It splits the text you give it into tokens. The search matches an exception if *each* of the tokens in your search term appear in one of the following:
-
--   The exception type
--   The exception message
--   The function names in the exception stack trace (if known)
--   The file paths in the exception stack trace (if known)
-
-For example, imagine you have an exception that looks like this:
-
-PostHog AI
-
-```
-TypeError: Cannot read property 'name' of undefined
-    at Object.<anonymous> (/path/to/myfile.js:123:45)
-    at Module._compile (module.js:653:30)
-    at Object.Module._extensions..js (module.js:664:10)
-    at Module.load (module.js:566:32)
-    at tryModuleLoad (module.js:506:12)
-    at Function.Module._load (module.js:498:3)
-    at Function.Module.runMain (module.js:694:10)
-    at startup (bootstrap_node.js:204:16)
-    at bootstrap_node.js:625:3
-```
-
-If you search for the term `TypeError myfile.js`, the exception matches this search, as it contains `TypeError` (as the exception type) and `myfile.js` (as a file path in the stack trace).
-
-If you search for `TypeError myfile.js abc`, the exception would not match, as the token `abc` does not appear anywhere in freeform search properties.
-
-If you want to search for longer exact strings, e.g. a particular exception message, you can group tokens into a single term using quotes, e.g. `"Cannot read property 'name' of undefined" myfile.js` would match, and `"Cannot read property of myfile.js"` would not.
-
-Note, perhaps unintuitively, `Cannot read property of myfile.js` would match, because the tokens are ungrouped, and all of them appear *somewhere* in the exception search properties.
-
-### Searching chained exceptions
-
-Exception events can have more than one exception in them, due to language features like exception chaining. For freeform search, we put the types, messages, functions and file paths of all exceptions into one list, and match if the token appears in any of them.
-
-For example, if you had a chained exception with the messages `MyCustomError: Failed to load user` and `Cannot read property 'age' of undefined`, searching for `cannot read property` would match the exception, because it matches *one* of the exception messages (`property` appears in the "root" one).
-
-## Issue details
-
-When you click on an issue, you'll see the details page of the issue.
-
-This page shows you the following:
-
--   The stack trace, properties, and sessions related to the **currently selected exception**.
--   Name, description, status, assignee, and external tracking links for the issue.
--   A filterable list of all exceptions in the issue. **Selecting an exception** will show you the stack trace, properties, and sessions related to that exception at the top of the page.
-
-![An issue, with an unfiltered exception list](https://res.cloudinary.com/dmukukwp6/image/upload/issue_exception_no_filter_light_405a3332d7.png)![An issue, with an unfiltered exception list](https://res.cloudinary.com/dmukukwp6/image/upload/issue_exception_no_filter_dark_dfce08c4b0.png)
-
-### Filtering exception occurrences within an issue
-
-Once you've found and opened the issue you want to investigate, you can use the same search interface to filter the exception list for a particular instance of the issue. This is particularly useful in cases where some exceptions in the issue have information others don't and you want to use that information for debugging.
-
-For example, you can add a property filter on `http_referer` that shows all exceptions where the `http_referer` is set:
-
-![An issue, with a filtered exception list](https://res.cloudinary.com/dmukukwp6/image/upload/issue_exception_with_filter_light_0fc6e1cb2d.png)![An issue, with a filtered exception list](https://res.cloudinary.com/dmukukwp6/image/upload/issue_exception_with_filter_dark_bf74dca1d9.png)
-
-**Alerts**
-
-If you have a set of filters that you use often, you can create alerts for them. This way you can be notified when new issues match your filters. Learn more about [alerts](/docs/error-tracking/alerts.md).
-
-## Improving search performance
-
-We try to return results to you within a second, but sometimes if you're querying over large amounts of data, it may take longer. The following can improve the search performance:
-
--   **Limit the time range you're searching over:** 7 days is usually enough to get a sense for the trends of an issue over time.
-
--   **Use freeform search rather than property filters:** Our freeform searches are generally faster than property filters, as the total amount of data processed is smaller.
-
-If you find your queries timing out or taking more than 30 seconds, please [let us know in-app](https://app.posthog.com/#panel=support%3Afeedback%3Aerror_tracking%3Alow%3Atrue)! We're always looking for benchmarks to improve against.
-
-## Suppressing issues
-
-If you find issues that are not useful to you, you can suppress them by changing the status to **Suppressed**. We recommend that you also implement [client-side suppression](/docs/error-tracking/capture.md#suppressing-exceptions) to not capture these exceptions in the first place, for cost and performance reasons.
-
-### Community questions
-
-Ask a question
-
-### Was this page useful?
-
-HelpfulCould be better