npm - @grepr/cli - Versions diffs - 1.13.0-2632478 → 1.14.3-5fb972a - Mend

@grepr/cli 1.13.0-2632478 → 1.14.3-5fb972a

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (2133) hide show

package/build/dist/docs-index/bf1b0bcb-b5aa-4fa2-b06f-f1b63915623c.txt DELETED Viewed

@@ -1,104 +0,0 @@
-Learn about administrative functions in the Grepr platform, including user interfaces providing full management of users, teams, and roles.
-# Grepr administration
-The Grepr platform includes administrative functions to:
-* Manage users, teams, and roles. You can add users, organize users into teams, assign roles, and control access to resources across the organization. These functions are accessible through the user-friendly Grepr UI and the REST API.
-* Create and manage service accounts for programmatic access to the Grepr API. Service accounts are identities that can be used to authenticate to Grepr resources without relying on user credentials.
-* Monitor, audit, and troubleshoot your Grepr environment with system logs. You can use system logs to track user activity, resource usage, and system performance.
-The platform also supports infrastructure as code (IaC) workflows for pipeline deployment and management using Terraform, and securely forwarding observability data to Grepr over private AWS networking with AWS PrivateLink.
-## Manage users
-You can use the **Users** pane in the Grepr user management UI to manage users in your organization. You can view users, view and edit their roles, remove users, and invite new users.
-In the **Users** pane, you can also manage the roles assigned to each user.
-See [Manage users in the Grepr platform](/admin/manage-users).
-## Manage teams
-The **Teams** pane in the Grepr user management UI lets you create and manage teams in your organization and assign users as team members or team leaders. You can also use teams to manage access to jobs, integrations, templates, and datasets.
-See [Manage teams in the Grepr platform](/admin/manage-teams).
-## Manage SSO claim mappings
-The **SSO Claim Mappings** pane in the Grepr user management UI lets you create and manage SSO claim mappings for your organization. With SSO claim mappings, you can automatically assign organization roles and team memberships to users when they sign in through your identity provider (IdP).
-See [Manage SSO claim mappings in the Grepr platform](/admin/manage-claim-mappings).
-## Manage service accounts
-The **Service Accounts** pane in the Grepr developer settings UI lets you create service accounts for programmatic access to the Grepr API, assign roles to them, and manage their credentials.
-See [Manage Grepr service accounts](/admin/service-accounts).
-## Manage Grepr resources with Terraform
-The Grepr Terraform provider enables infrastructure as code management of Grepr integrations, datasets, and pipelines. With the Terraform provider, you can:
-* Define pipelines as code in your version control system.
-* Automate pipeline deployment as part of your CI/CD workflows.
-* Manage multiple environments, such as development, staging, and production, with consistent configurations.
-* Track changes to pipeline configurations over time.
-See [Manage Grepr resources with Terraform](/admin/terraform-provider).
-## Monitor system activity in your Grepr environment
-The **System Logs** page in the Grepr UI lets you monitor and audit activity in your Grepr environment. You can view the activity information captured for Grepr resources, including jobs, integrations, datasets, and your organization. You can also audit user activity in your Grepr environment.
-See [View and search system activity in Grepr](/admin/activity-logs).
-## Connect to Grepr with AWS PrivateLink
-You can use Grepr's AWS PrivateLink endpoint service to send observability data to Grepr over private AWS networking instead of the public internet. With the PrivateLink endpoint service, your data stays on the AWS private network and never traverses the public internet, reduces the networking resources required to send data to Grepr from your AWS environment, and can reduce data transfer costs compared to routing ingest traffic over the public internet. See [Securely forward observability data to Grepr with AWS PrivateLink](/admin/private-link).
-## Frequently Asked Questions
-### What is the difference between organization-level roles and team roles in Grepr?
-Organization-level roles like Admin, Member, and Reader control global access to Grepr features. Team roles (Leader/Member) are scoped to specific teams and allow for more granular access control. A user can be a team Leader without being an organization-level Admin.
-### How do I invite users to my Grepr organization?
-In the Users pane of the user management UI, click 'Invite new users' and enter email addresses. You can optionally assign roles and team assignments to invited users before sending the invitation. Users receive an email invitation they must respond to join the organization.
-### Can I manage users and teams through the REST API?
-Yes, Grepr provides REST APIs for complete user and team management. You can use the Users API and Roles API endpoints documented in the OpenAPI specification to programmatically manage users, roles, and team memberships.
-### What permissions do I need to access the user management UI?
-You must have the view:users permission to access the user management UI. This permission is automatically granted to organization Admins and team Leaders.
-### How do custom roles work in Grepr?
-Custom roles allow you to define specific permissions for different resources (jobs, integrations, datasets, etc.). You can select which resources a custom role has access to and what permissions it grants (view, edit, create, delete, or all).
-### Can a user be assigned to multiple teams?
-Yes, a user can be assigned to multiple teams with different roles in each team. For example, a user can be a Leader in one team and a Member in another team simultaneously.
-### What happens when I remove a user from my organization?
-When you remove a user, they are deleted from your organization and all their access is revoked immediately. They lose access to all organization-level resources and all team-scoped resources.
-### How do I ensure proper access control when assigning users to teams?
-Follow the principle of least privilege by granting users only the access they need. Use team membership to scope access to specific resources, and use custom roles for fine-grained permission control when the built-in Admin, Member, and Reader roles don't meet your requirements.
-### What is the difference between editing a user and editing a custom role?
-Editing a user allows you to update their name, email, and assign or change their organization-level roles and team memberships. Editing a custom role changes the permissions it grants, which affects all users assigned to that role.
-### Can team Leaders manage team membership without being organization Admins?
-Yes, team Leaders have the ability to manage team membership, including adding and removing members, without needing organization-level Admin privileges. This allows for delegation of team management responsibilities.
-### How do I manage Grepr deployments and pipelines using IaS or Infrastructure as Code?
-Grepr has an open-source Terraform provider that you can use to manage pipelines via git workflows and using infrastructure-as-code.

package/build/dist/docs-index/c040e9b7-b6f8-4ce9-9b2a-c0c9c5f6ffcf.json DELETED Viewed

	@@ -1 +0,0 @@
1	- {"docType":"api"}

package/build/dist/docs-index/c040e9b7-b6f8-4ce9-9b2a-c0c9c5f6ffcf.txt DELETED Viewed

@@ -1,47 +0,0 @@
-# Update an Asynchronous Streaming Job
-**PUT** `/v1/jobs/{id}`
-**Operation ID**: `updateJob`
-**Summary**: Update an Asynchronous Streaming Job
-Updates an asynchronous streaming job. This is an asynchronous operation which returns an identifier (field: id) for the job to be created, in the response. The id can be used to query the status of the job using the GET jobs endpoint. If a change in the job graph is detected, a new version of the job will be created and sent back in the response object. Job update lifecycle is represented by the state field in the GET response. Following states can be expected in the response:
- - PENDING:        Job is in the process of being updated.
- - RUNNING:        Job is running.
- - STOPPED:        Job is stopped.
- - FAILED:         Job update failed.
- - INFRA_UPDATE:   Job is undergoing an infra change.
-## Tags
-- Jobs
-## Parameters
-- **id** (required) - path
-  - Id of the job to update
-  - Type: string
-- **rollbackEnabled** (optional) - query
-  - If set to true, the rollback path will be enabled if this job update fails.
-  - Type: boolean
-## Request Body
-**Content-Type**: `application/json`
-**Schema**: `UpdateJob`
-## Responses
-### 202
-Job updated successfully
-### 401
-Unauthorized
-### 404
-Job not found.
-### 409
-Job update failed due a conflicting update request.

package/build/dist/docs-index/c0b6e7bc-3f5c-48b1-a457-e8181a070c7c.json DELETED Viewed

	@@ -1 +0,0 @@
1	- {"docType":"doc"}

package/build/dist/docs-index/c0b6e7bc-3f5c-48b1-a457-e8181a070c7c.txt DELETED Viewed

@@ -1,182 +0,0 @@
-Capture sessions from coding agents such as Claude Code, Codex, and OpenCode, then explore transcripts, execution spans, token usage, cost, and errors.
-# Capture and explore agent sessions
-An *agent session* is one complete run of a coding agent: the prompts you sent, the model calls the agent made, the tools it ran, the results those tools returned, and the tokens and cost it consumed. An *agent sessions pipeline* ingests the telemetry your agent already produces, reconstructs each session from it, and stores the result in a Grepr data lake so you can read the transcript, measure what the agent spent, and find the runs that failed.
-Coding agents report this activity as OpenTelemetry data, split across two signals. They describe what happened in the conversation as OTLP log events, and they describe how the run executed as OTLP spans. Neither signal is a session on its own, and neither is readable as a conversation without reassembly. An agent sessions pipeline reads both from the same integration and joins them into a session you can explore.
-> Agent sessions are enabled for each organization individually. To turn on agent sessions for your organization, contact <support@grepr.ai>.
-## What Grepr captures from an agent session \[#captured-data]
-From a supported agent harness, a session records:
-* The prompts you sent and the text the agent replied with.
-* Every tool call, with its arguments and the result the tool returned.
-* Token counts for each model call, broken down into input, output, cache reads, and cache writes.
-* The cost the harness reported for the run, when the harness reports one.
-* The model and provider that served each call.
-* Every error the agent encountered, joined back to the tool call that produced it.
-* The identity that ran the session and the duration of each step.
-How completely a session is captured depends on the harness and on how you configure it. A harness reports content only when you turn content logging on, and some harnesses do not report every field. Grepr labels these gaps rather than hiding them: a session names the content its harness never sent, and marks content the harness shortened as a truncated capture.
-## Anatomy of an agent session \[#session-model]
-Grepr presents every harness the same way, so a transcript reads alike whichever agent produced it.
-An *emitter* is the harness that produced a session, such as `claude-code`. It appears in the **Emitter** column of the sessions list, and it is how you tell one harness's sessions from another's when several report to the same dataset.
-A session is a sequence of *turns*, where each turn is one prompt and everything the agent did in response. A turn contains *events*, and the kinds that make up a transcript are:
-| Event kind | What it records |
-| --- | --- |
-| `user_message` | A prompt you sent to the agent. |
-| `model_call` | One request to a model, with its token counts and cost. |
-| `assistant_message` | Text the agent replied with. |
-| `tool_call` | A tool the agent invoked, with its arguments. |
-| `tool_result` | What a tool returned, and whether it failed. |
-A session records other kinds too, such as tool decisions and lifecycle events. Every event Grepr stored for a session, whatever its kind, is listed under **Raw events** in the session.
-Alongside the events, a session carries *execution spans*, which are the timing records for its model calls and tool executions. Events tell you what the agent did; spans tell you how long each step took and how the steps overlapped.
-## Supported agent harnesses \[#harnesses]
-Grepr recognizes the following harnesses and reports each one as the listed emitter. Grepr identifies a harness by the service name in its telemetry, so do not override `OTEL_SERVICE_NAME`. A session whose service name has been changed is not recognized, and its data reaches the data lake without being assembled into a session.
-| Harness | Emitter | Service name | Setup |
-| --- | --- | --- | --- |
-| Claude Code | `claude-code` | `claude-code` | [Configure Claude Code](/integrations/open-telemetry?tab=claude-code#configure-forwarding-to-grepr) |
-| Codex | `codex` | `codex_exec` or `codex_cli_rs` | [Configure Codex](/integrations/open-telemetry?tab=codex#configure-forwarding-to-grepr) |
-| OpenCode | `opencode` | `opencode` | [Configure OpenCode](/integrations/open-telemetry?tab=opencode#configure-forwarding-to-grepr) |
-Any harness that exports OTLP logs and traces can send data to an agent sessions pipeline, and that data is stored in your data lake. Grepr assembles sessions only for the harnesses listed here, so telemetry from another harness is searchable but does not appear in the Agent Sessions page.
-## Create an agent sessions pipeline \[#create-pipeline]
-An agent sessions pipeline reads a harness's two signals from a single OpenTelemetry integration. You attach the integration once, and the pipeline reads agent events from its OTLP logs endpoint and execution spans from its OTLP traces endpoint.
-### Step 1: Create an OpenTelemetry integration
-Create an OpenTelemetry integration to receive your agent's telemetry. Agent sessions require no special integration settings, so follow the instructions for [creating an OpenTelemetry integration](/integrations/open-telemetry#step1-create-integration). Copy the Grepr token when the **Grepr Token** dialog appears, because you need it to build the ingestion URL in Step 6.
-To keep one agent's sessions separate from another's, create one integration for each agent you want to report separately.
-### Step 2: Create the pipeline
-To create the pipeline, on the **Pipelines** page, click **Create pipeline**, select **Agent Sessions Pipeline** as the pipeline type, enter a name, and click **Create**.
-### Step 3: Add sources
-A source is one OpenTelemetry integration carrying one agent's events and execution spans. To add a source, on the pipeline details page, click **Sources** in the left pane, then click **Add source**. In the **Add Source** dialog:
-* In the **OTLP Integration** menu, select the integration you created in Step 1.
-* In the **Source Name** field, enter a name using lowercase letters, numbers, and underscores. Grepr suggests a name based on the integration you selected.
-Click **Add** to save the source. Grepr derives both signals from this one source, so you do not add a separate source for logs and traces.
-You cannot change the integration on an existing source. To point a source at a different integration, delete the source and add a new one.
-### Step 4: Store sessions in the data lake
-To choose where Grepr stores your sessions, click **Data Lake** in the left pane, then click **Add**. In the **Configure Data Lake** dialog, select a dataset from the **Dataset** menu and click **Add**. To move the pipeline to a different dataset later, click **Edit**. Grepr stores the events and execution spans for every session in this dataset, which is what makes sessions searchable in the Agent Sessions page. To learn more about how Grepr stores your data, see [_](/grepr-platform/data-lake).
-### Step 5: Optionally forward sessions
-To send sessions to another platform, click **Sinks** in the left pane and add an OpenTelemetry integration. Grepr forwards a session's events to the integration's OTLP logs endpoint and its execution spans to the traces endpoint, so the destination must accept both. A pipeline that only stores sessions in the data lake needs no sinks.
-### Step 6: Configure your agent to send telemetry
-Configure your agent to export OTLP to the ingestion URL for the integration you added as a source. For the settings each supported harness requires, select the tab for your agent in the [configuration examples for sending data to Grepr](/integrations/open-telemetry#configure-forwarding-to-grepr).
-How many signals a harness needs depends on the harness. Claude Code and Codex report part of a session on their log events and part on their spans, so configuring either for a single signal produces an incomplete session. OpenCode reports a whole session on its spans, so it needs traces alone.
-## Explore agent sessions \[#explorer]
-To read the sessions your pipeline captured, in the **Agent Sessions** menu, select the dataset you configured in Step 4. Set a time range and run a search to list the sessions active in that range.
-The sessions list reports one row per session, with the time it started, the earliest prompt in the range, the emitter, the identity that ran it, the model, the number of tool calls, the duration, and the number of errors. Because the widest column is the earliest prompt, you can scan the list for the session you want by what it was asked to do. To narrow the list, enter a query in the search field. A session matches when any of its content matches, and the **Matched content** column shows which part matched.
-### Filter the sessions list \[#filter-sessions]
-The search field takes the same Datadog-like syntax as Log Explorer, so a bare word searches the content of a session. To learn more about the syntax, see [_](/queries/datadog).
-Grepr also tags every event it stores for a session, and you can filter on those tags:
-| Tag | What it holds |
-| --- | --- |
-| `agent_emitter` | The harness that produced the session, such as `claude-code`. |
-| `agent_session_id` | The session's identifier, which is the value shown in the session header. |
-| `agent_event_kind` | The kind of event, such as `tool_call`. |
-| `agent_turn_id` | The turn the event belongs to. |
-For example:
-```text
-agent_emitter:claude-code
-agent_emitter:codex agent_event_kind:tool_call
-agent_session_id:8c1d4a02-5e7b-4f19-9a30-b6e2c4d80f55
-```
-The kinds a session records go beyond the five that make up a transcript, and which kind carries a given fact depends on the harness. A tool result Grepr captured only as metadata is stored as `tool_result_metadata` rather than `tool_result`, which is what a Claude Code session captured without spans records. To see the kinds a session actually stored, open it and read **Raw events**.
-Grepr searches a session's events rather than the session as a whole, so a session matches when any one of its events matches. Filtering on a kind therefore selects the sessions that recorded that kind of event, and each matching session still opens on its full transcript. Combining terms narrows the list, because Grepr applies them together.
-Select a session to open it. A session opens on the following views:
-* The **Transcript** view reads the session as a conversation, one card per turn, with each model call, tool call, and tool result nested under the turn that produced it. Use **Collapse all** to scan a long session by turn, and expand a turn to read its content.
-* The **Timing waterfall** view charts the session's execution spans, so you can see how long each model call and tool execution took and which steps overlapped. This view appears only when the session has execution spans.
-Above the transcript, a summary bar reports the session's shape and what it consumed: turns, tool calls, errors, duration, token counts, and cost. Every error in the session is listed above the transcript as well, each one joined back to its tool call, so you do not have to search a long transcript to find what failed. **Raw events** lists every event Grepr stored for the session, which is where you confirm what a harness actually sent when a transcript looks incomplete.
-The timing waterfall charts the same session as a span tree, so a step that dominated the run is visible without reading the transcript.
-## Analyze many sessions at once \[#analytics]
-Reading one session tells you what one run did. To find the patterns across many runs, run an analysis over a set of sessions. An analysis reads the sessions your search selected, groups them by what you asked the agent to do, labels each group, and reports what each group consumed.
-Grepr groups sessions by meaning rather than by matching text, so two sessions that asked for the same thing in different words land in the same group. A session that fits no group is counted as *miscellaneous* rather than forced into one it does not belong to.
-### Start an analysis \[#start-analysis]
-To start an analysis, on the **Agent Sessions** page, run the search that selects the sessions you want, then click **Analyze**. In the **Analyze agent sessions** dialog:
-* In the **Session cap** field, set the maximum number of sessions to analyze. The default is `10000` and the maximum is `100000`.
-* In the **Maximum named groups** field, set how many groups the analysis labels. The default is `20` and the maximum is `100`.
-* In the **Model integration** menu, select the OpenAI or Gemini integration that Grepr uses to group and label the sessions.
-An analysis covers a time range of at most 31 days, and it analyzes the sessions from the search you last submitted. Because an analysis calls the model integration you select, it consumes tokens on that integration.
-Grepr runs the analysis in the background. To read the reports it produces, click **Analytics**.
-### Read a report \[#read-report]
-The **Analytics** view lists one row per report, with the report identifier, when it was created, the query and time range it covers, its status, and how many sessions it analyzed and groups it found. Expand a row to see how the analysis ran: the session cap and group limit it used, how many sessions matched and were analyzed, how many groups were named against how many sessions were left as miscellaneous, the embedding and labeling models, and any warnings.
-To open the visualizations for a report, in the row's actions menu, click **Visualize**.
-A dashboard opens on a row of totals for the sessions it analyzed: how many sessions and intent groups it found, input and output tokens with reasoning and cache reads broken out, tool calls and how many of them failed, the cost the harnesses reported, and the total session duration with the number of model calls behind it. Below the totals, two charts rank the intents by number of sessions and the tools by number of calls, so you can see what your agents are most often asked to do and which tools carry that work. Each intent carries the description the labeling model wrote for it. Use the **Top results** menu to change how many rows each chart shows.
-### Compare intents against tools and models \[#report-breakdowns]
-The **Intent and tool overlap** table reports how many sessions in each intent used each tool, shading each cell by magnitude, which is where a tool that only one kind of work depends on becomes visible.
-The **Token usage** tables break the same reported usage down by model, by emitter, by intent, and by agent role, so you can attribute spend to the work that caused it rather than to the harness as a whole. An asterisk marks a total whose reported cost is only partial, because not every harness reports cost.
-The dashboard charts summaries that Grepr computes when the analysis runs, not the sessions themselves. To work with the sessions individually, in the row's actions menu, click **Download report** and analyze the CSV.
-## Troubleshoot agent session capture \[#troubleshooting]
-An agent that is exporting telemetry successfully can still produce no sessions, because the data reaching Grepr is the wrong shape rather than absent. Check the following before investigating the pipeline.
-**Sessions appear but have no timing waterfall.** The harness is exporting log events but not spans. Claude Code exports spans only when you set `CLAUDE_CODE_ENHANCED_TELEMETRY_BETA=1` alongside a traces exporter. Codex uses a separate `otel.trace_exporter` setting for spans, and configuring only `otel.exporter` sends log events alone. In both cases the agent reports no error, because each harness is doing exactly what you configured.
-**A transcript shows metadata but no prompts, responses, or tool results.** Content logging is off. Claude Code and Codex redact content by default, so you must turn it on explicitly. For the settings each one uses, see the tab for your agent in the [configuration examples for sending data to Grepr](/integrations/open-telemetry#configure-forwarding-to-grepr). OpenCode's plugin reports content without a separate setting, so an OpenCode session missing content points at the plugin instead.
-**Data arrives in the data lake but no sessions appear.** Grepr received telemetry it does not recognize as agent activity. The most common causes are an overridden `OTEL_SERVICE_NAME`, which stops Grepr identifying the harness, and, for OpenCode, a missing OpenTelemetry plugin. Without the plugin, OpenCode's built-in instrumentation reports internal runtime operations such as `sql.execute` instead of agent activity, and that data is stored without being assembled into a session.
-**A session names content its harness never sent.** This is expected for some harnesses and is not a configuration error. Codex reports no assistant text at all, so its sessions show the note that the emitter does not report assistant responses. Claude Code reports tool output only on a span event, so a session captured without spans records the size of each tool result rather than its content.

package/build/dist/docs-index/c12948da-72c3-42cd-b98e-8961dcf75ffc.json DELETED Viewed

	@@ -1 +0,0 @@
1	- {"docType":"api"}

package/build/dist/docs-index/c12948da-72c3-42cd-b98e-8961dcf75ffc.txt DELETED Viewed

@@ -1,20 +0,0 @@
-# List all GitHub MCP integrations
-**GET** `/v1/integrations/github-mcp`
-**Operation ID**: `list_10`
-**Summary**: List all GitHub MCP integrations
-Get all GitHub MCP server integrations for your organization. This will contain masked tokens if present.
-## Tags
-- GitHub MCP Integration
-## Responses
-### 200
-Integrations retrieved successfully
-- **Content-Type**: `application/json` / `ItemsCollectionReadGithubMcp`
-### 401
-Unauthorized

package/build/dist/docs-index/c12a096a-1cf2-4e52-8ea6-3da0f31144fd.json DELETED Viewed

	@@ -1 +0,0 @@
1	- {"docType":"schema"}

package/build/dist/docs-index/c12a096a-1cf2-4e52-8ea6-3da0f31144fd.txt DELETED Viewed

@@ -1,27 +0,0 @@
-# StartInvestigationRequest
-Request body for the manual-trigger endpoint. The engineer's user identity is taken from the request's auth context, not the body.
-**Type**: `object`
-## Properties
-- name: agentId (required)
-  type: string
-  description: TSID of the agent to investigate.
-- name: issueId (optional)
-  type: string
-  description: When set, hands the agent this issue (its TSID): the run's subject, which its first message holds and whose history records the handoff. Only a person may hand off an issue, and a handoff can't be a continuation. `null` for a plain run.
-- name: next (optional)
-  type: boolean
-  description: With `issueId`, true to have the agent work on the issue next: the run starts ahead of the agent's other queued runs, without stopping a running one. Allowed only with `issueId`; `null` or false for the usual place in the queue.
-- name: parentInvestigationId (optional)
-  type: string
-  description: When set, seeds the new investigation from this parent's journalled transcript — a continuation; the parent must belong to `agentId`. `null` for a fresh investigation.
-- name: userProvidedContext (optional)
-  type: string
-  description: Free-form context for the agent's first turn, or `null`.

package/build/dist/docs-index/c1c49366-8035-4e9d-bdb4-14b60d0a3724.json DELETED Viewed

	@@ -1 +0,0 @@
1	- {"docType":"schema"}

package/build/dist/docs-index/c1c49366-8035-4e9d-bdb4-14b60d0a3724.txt DELETED Viewed

@@ -1,26 +0,0 @@
-# DataQuality
-**Type**: `object`
-## Properties
-- name: embeddingFailures (optional)
-  type: integer
-- name: incompleteContentSessions (optional)
-  type: integer
-- name: labelFailures (optional)
-  type: integer
-- name: metadataOnlyEvents (optional)
-  type: integer
-- name: missingUsageSessions (optional)
-  type: integer
-- name: truncatedEvents (optional)
-  type: integer
-- name: warnings (optional)
-  type: integer

package/build/dist/docs-index/c2013b75-bffc-4efe-87ba-1291728b092e.json DELETED Viewed

	@@ -1 +0,0 @@
1	- {"docType":"schema"}

package/build/dist/docs-index/c2013b75-bffc-4efe-87ba-1291728b092e.txt DELETED Viewed

@@ -1,20 +0,0 @@
-# RecordMemoryResponse
-**Type**: `object`
-## Properties
-- name: alreadyRecorded (optional)
-  type: boolean
-- name: memoryId (optional)
-  type: string
-- name: nearestMemoryId (optional)
-  type: string
-- name: nearestSimilarity (optional)
-  type: number
-- name: review (optional)
-  type: `MemoryReview`

package/build/dist/docs-index/c208bf8d-924f-412c-b4d1-1408c9308e22.json DELETED Viewed

	@@ -1 +0,0 @@
1	- {"docType":"api"}

package/build/dist/docs-index/c208bf8d-924f-412c-b4d1-1408c9308e22.txt DELETED Viewed

@@ -1,18 +0,0 @@
-# Get a skill
-**GET** `/v1/skills/{id}`
-**Operation ID**: `get_4`
-**Summary**: Get a skill
-## Parameters
-- **id** (required) - path
-  - Type: string
-## Responses
-### 200
-Skill retrieved successfully
-- **Content-Type**: `application/json` / `SkillView`

package/build/dist/docs-index/c224b846-c654-48a1-af81-2098a0feca2c.json DELETED Viewed

	@@ -1 +0,0 @@
1	- {"docType":"api"}

package/build/dist/docs-index/c224b846-c654-48a1-af81-2098a0feca2c.txt DELETED Viewed

@@ -1,33 +0,0 @@
-# List agent suggestions
-**GET** `/v1/agent-suggestions`
-**Operation ID**: `list_2`
-**Summary**: List agent suggestions
-Returns the organization's agent suggestions, newest first, optionally filtered by pipeline, review status, and proposing agent.
-## Tags
-- Agent Suggestions
-## Parameters
-- **jobId** (optional) - query
-  - Type: string
-- **status** (optional) - query
-  - Type: enum: `PENDING`, `APPLIED`, `REJECTED`
-- **agentId** (optional) - query
-  - Type: string
-- **page** (optional) - query
-  - Type: integer
-- **pageSize** (optional) - query
-  - Type: integer
-## Responses
-### 200
-Suggestions retrieved successfully
-- **Content-Type**: `application/json` / `AgentSuggestionsList`
-### 401
-Unauthorized

package/build/dist/docs-index/c24c21a6-a7d5-4dc7-9567-ee1efd260c6b.json DELETED Viewed

	@@ -1 +0,0 @@
1	- {"docType":"api"}

package/build/dist/docs-index/c24c21a6-a7d5-4dc7-9567-ee1efd260c6b.txt DELETED Viewed

@@ -1,33 +0,0 @@
-# Create a new SSO claim mapping
-**POST** `/v1/sso-claim-mapping`
-**Operation ID**: `createClaimMapping`
-**Summary**: Create a new SSO claim mapping
-Creates a new SSO claim mapping that assigns roles when token claims match
-## Tags
-- SSO Claim Mappings
-## Request Body
-**Content-Type**: `application/json`
-**Schema**: `WriteSsoClaimMapping`
-## Responses
-### 201
-Claim mapping created successfully
-### 400
-Invalid request data (missing required fields, invalid role/team IDs, or validation failed)
-### 403
-Insufficient permissions
-### 409
-Claim mapping with this key-value pair already exists

package/build/dist/docs-index/c26906f9-9e33-434c-8a98-1a287c771c4f.json DELETED Viewed

	@@ -1 +0,0 @@
1	- {"docType":"schema"}

package/build/dist/docs-index/c26906f9-9e33-434c-8a98-1a287c771c4f.txt DELETED Viewed

@@ -1,15 +0,0 @@
-# PreserveAllAttributesMergeStrategy
-**Type**: `object`
-## Properties
-- name: limit (optional)
-  type: integer
-- name: type (required)
-  type: enum: `preserve`
-  description: PreserveAllAttributesMergeStrategy: Collects all incoming values/objects into a collection. If an incoming value is a collection, its elements are unpacked and added individually. The 'limit' field defines when an attribute size will trigger a cluster overflow emission. The 'unique' flag determines if the collection behaves like a Set or a List.
-- name: unique (optional)
-  type: boolean

package/build/dist/docs-index/c284a09e-c230-4a9a-bd0e-c0ab5cf93870.json DELETED Viewed

	@@ -1 +0,0 @@
1	- {"docType":"api"}

package/build/dist/docs-index/c284a09e-c230-4a9a-bd0e-c0ab5cf93870.txt DELETED Viewed

@@ -1,38 +0,0 @@
-# Resume a stopped investigation
-**POST** `/v1/investigations/{investigationId}/resume`
-**Operation ID**: `resume`
-**Summary**: Resume a stopped investigation
-Resumes a stopped (resumable) investigation in place. A non-blank message is appended as a new user turn; an empty body continues the agent with no added input.
-## Tags
-- Investigations
-## Parameters
-- **investigationId** (required) - path
-  - Type: string
-## Request Body
-**Content-Type**: `application/json`
-**Schema**: `ResumeInvestigationRequest`
-## Responses
-### 202
-Resume requested
-### 401
-Unauthorized
-### 404
-Investigation not found
-### 409
-Investigation is not resumable

package/build/dist/docs-index/c2c28c13-be2b-4e8b-92fa-c50f8eac2874.json DELETED Viewed

	@@ -1 +0,0 @@
1	- {"docType":"schema"}