feat(api): update API spec from langfuse/langfuse 961a46f

[langfuse-bot]

Greptile Summary

Updates generated evaluation-rule filter documentation to describe the boolean filter type and the isRootObservation observation column across all filter variants.

Confidence Score: 5/5

The PR appears safe to merge because it only updates generated model documentation and introduces no executable behavior changes.

The additions are confined to repeated class docstrings and consistently document the new boolean filter and observation column across every filter variant.

_{Reviews (1): Last reviewed commit: "feat(api): update API spec from langfuse..." | Re-trigger Greptile}

Context used:

• Knowledge Base — API Client (langfuse/api/)

[github-actions]

@claude review

[claude]

LGTM — mechanical, auto-generated docstring update only.

What was reviewed: Confirmed the diff is entirely additive docstring text (Fern-generated) documenting the new boolean filter type and isRootObservation column across the EvaluationRuleFilter_* classes. No changes to field types, validators, the discriminated union, or any runtime logic — the existing EvaluationRuleFilter_Boolean model already had type/column/operator/value: bool, unaffected by this diff.

Extended reasoning...

Overview

The PR is an auto-generated API spec sync (Fern) touching a single file, evaluation_rule_filter.py. Every hunk in the diff is a docstring addition documenting a new boolean filter operator (=, <>) and a new isRootObservation observation column, repeated consistently across all EvaluationRuleFilter_* model classes. There is no change to any Pydantic field, type annotation, validator, or the discriminated union definition at the bottom of the file.

Security risks

None. No parsing, validation, or execution logic changed — only human-readable docstrings.

Level of scrutiny

Minimal scrutiny is appropriate: this is a generated file (noted at the top: "This file was auto-generated by Fern from our API Definition"), the change is purely additive documentation, and it mirrors the exact same pattern already used for the other filter types (string, number, datetime, etc.) in this file. There is no ambiguity or design decision for a human to weigh in on.

Other factors

No prior reviews exist on this PR. The change is self-contained, has no test impact (docstrings aren't tested), and follows the established pattern precisely, so I'm confident this doesn't need human review.