@grepr/cli 1.12.6-f4cc8d6 → 1.12.7

package/build/dist/docs-index/{ac730f63-5389-414d-960e-c306c3ed20bf.txt → 129e0179-fa04-488c-a125-17d8d33e6bb5.txt}

@@ -12,7 +12,7 @@ Request body for the manual-trigger endpoint. The engineer's user identity is ta
 
 - name: issueId (optional)
   type: string
-  description: When set, hands the agent this issue (its TSID): the run's subject, which its known issues hold alone 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.
+  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

package/build/dist/docs-index/{e8f3ea63-6e1c-491f-9cee-d67e3200a31a.txt → 394ff1bb-b59b-4d5c-b7e1-6271349a9b6a.txt}

@@ -32,7 +32,7 @@ One durable problem or task on the organization's issue board.
 
 - name: entities (optional)
   type: object
-  description: The `entity:*` tags it concerns, the same vocabulary as memory tags, sorted by key.
+  description: The `entity:*` tags it concerns, the same vocabulary as memory tags, keys in lower case, sorted by key.
 
 - name: evidence (optional)
   type: array of `IssueEvidence`

package/build/dist/docs-index/{33f3730a-07c5-4712-90f2-6f8f7b6e2e1f.txt → 3ab7218f-9ae8-4251-9980-03e93ed634c6.txt}

@@ -79,7 +79,9 @@ An agent's pipeline changes are scoped to a pipeline's Grok parsers and its SQL
 
 A SQL transform an agent adds is a filter and nothing further. It reads the pipeline's logs and selects them unchanged against a single condition, so it cannot join, aggregate, read a dataset, register a function, or keep state. It routes the events it matches to the agent signal sink, which you configure yourself when you set the pipeline up. An agent can add routes to that sink, and it cannot create, change, or remove the sink. That limit is on what an agent adds by itself. A SQL output you route to the agent signal sink yourself carries no such restriction, so you can build the event an agent receives however you need. See [_](/ai-agents/subscriptions#agent-signal-sink).
 
-The tools an agent uses with memories and issues are not in this list. Every agent can search and read both, and the **Remember past investigations** and **Works on issues** switches in the **Memory and issues** section decide whether it also records memories and changes issues. See [_](/ai-agents/memory).
+The tools and skills you grant also decide which `grepr` CLI commands the agent can run.
+
+The tools an agent uses with memories and issues are not in this list. Every agent can search and read both. The **Remember past investigations** switch, on the agent's **Memories** step, and the **Works on issues** switch, on its **Issues** step, decide whether it also records memories and changes issues. When you create an agent, both are in the wizard's **Memory and issues** section. See [_](/ai-agents/memory) and [_](/ai-agents/issue-board).
 
 ## Let an agent call an MCP server's tools \[#mcp-integrations]
 

package/build/dist/docs-index/{b7b4ba47-d14e-41e8-aa93-de1c5833f57d.txt → 5418ce71-5708-44c2-aeff-c789c356517b.txt}

@@ -12,6 +12,10 @@
   type: string
   description: The name of the S3 bucket to use for the data warehouse
 
+- name: orgName (required)
+  type: string
+  description: The organization's name, which names its folder under the bucket's query-results prefix. The stack expires that folder's query results after a day.
+
 - name: region (required)
   type: string
   description: The AWS region the bucket must be created in. Matches the region the Grepr deployment is running in.

package/build/dist/docs-index/{a51049a4-9971-4766-aef9-8424ef7f29c6.txt → 87559b61-e4d7-4aca-8d93-f341b49ed1a8.txt}

@@ -4,6 +4,14 @@ Learn how AI agents work on issues on the issue board, how to hand an issue to a
 
 An agent with **Works on issues** turned on files issues, works on them, and records what it found on the issue board. An agent works on an issue in an investigation started on that issue, called a *run* on the issue. A run starts on an issue in one of two ways: you hand the issue to the agent, or the agent picks the issue up from the **Ready** column.
 
+An agent's issue settings are on its **Issues** step: **Works on issues**, whether it can put issues in **Ready**, and which **Ready** issues it picks up. When you create an agent, they're in the wizard's **Memory and issues** section.
+
+## How an agent finds issues \[#finding-issues]
+
+Before an agent acts on a problem or files an issue, it searches the board for the problem and reads what it finds, including guidance comments. The search also finds issues people closed as **Ignored** or **Not a problem**, so an agent doesn't redo work a person ruled out. The issue page shows which runs each guidance comment was given to.
+
+An issue's entities, such as `entity:service=checkout`, say what the problem is. When an agent files an issue from an alert, it names at least one entity from the alert.
+
 ## How an agent works on an issue \[#how-it-works]
 
 When a run on an issue starts, the agent joins the issue as an assignee, and an issue in **Ready** moves to **In progress**. The issue page lists the issue's runs with their status and a link to each one, and the issue's card shows an agent whose run is waiting to start.
@@ -35,7 +43,7 @@ When you continue an investigation that was on an open issue, the new investigat
 
 ## Let an agent pick up Ready issues \[#pickup]
 
-To let an agent pick up issues on its own, open the agent's **Memory and issues** section, turn on **Pick up Ready issues**, and choose which issues it takes: a priority, labels, entities, and teams. An issue must match every filter you set.
+To let an agent pick up issues on its own, open the agent's **Issues** step, turn on **Pick up Ready issues**, and choose which issues it takes: a priority, labels, entities, and teams. An issue must match every filter you set. Labels are the dependable way to route issues to an agent.
 
 The agent picks up issues in **Ready** that no one is assigned to and no run is on, most urgent first, then the one that has been in **Ready** the longest. It follows these rules:
 
@@ -49,7 +57,7 @@ Pausing an agent discards its runs on issues that are waiting to start, so that
 
 ## Let an agent put issues in Ready \[#allow-ready]
 
-By default, an agent files issues in **Triage** for a person to review, and can't move an issue to **Ready**. To let an agent file issues in **Ready** and move issues there, choose **Allow Ready** in the agent's **Memory and issues** section. Agents whose pickup filters match an issue in **Ready** pick it up, and every agent can see the other agents' pickup filters, so an agent can label an issue for the agent that handles it.
+By default, an agent files issues in **Triage** for a person to review, and can't move an issue to **Ready**. To let an agent file issues in **Ready** and move issues there, choose **Allow Ready** on the agent's **Issues** step. Agents whose pickup filters match an issue in **Ready** pick it up, and every agent can see the other agents' pickup filters, so an agent can label an issue for the agent that handles it.
 
 ## Remove an agent from an issue \[#remove]
 

package/build/dist/docs-index/{91ba7347-01c3-4911-845d-d8c89000788f.txt → 8d56dbed-341a-4ef8-a1fd-99835901e98a.txt}

@@ -1,6 +1,6 @@
 # IssueGuidanceRead
 
-One investigation whose agent was given a guidance comment in its known-issues context.
+One investigation whose agent was given a guidance comment: returned by its `get_issue`, or in the issue it was handed.
 
 **Type**: `object`
 

package/build/dist/docs-index/99a4cfdf-e03c-43ca-b34a-97a39bdd2695.txt

@@ -0,0 +1,30 @@
+# Get a backfill's progress
+
+**GET** `/v1/jobs/{id}/progress`
+
+**Operation ID**: `getBackfillProgress`
+**Summary**: Get a backfill's progress
+Gets what a logs backfill is doing: waiting, selecting its events with Athena, or sending them, with how many it has read and each vendor has received. Read live while the backfill runs; the final counts once it ends.
+
+## Tags
+- Jobs
+## Parameters
+
+- **id** (required) - path
+  - Id of the backfill
+  - Type: string
+
+## Responses
+
+### 200
+
+Progress retrieved successfully
+
+- **Content-Type**: `application/json` / `BackfillProgress`
+### 401
+
+Unauthorized
+
+### 404
+
+No logs backfill has this id.

package/build/dist/docs-index/{a952f252-2f53-4bdd-b7b4-74c301134dd2.txt → 9a4651b2-9fe7-4f7d-b9e9-b6a4b8a7fbf6.txt}

@@ -39,4 +39,4 @@ Schema for the logs backfill job graph.
 
 - name: vendorSinkIntegrationIds (optional)
   type: array of string
-  description: Vendor integration IDs, if any, whose prior delivery the backfill source skips. Empty when the source does no per-vendor dedup join.
+  description: Vendor integration IDs, if any, whose prior delivery the backfill source skips: exactly the integrations the sinks send to, or empty when the source does no per-vendor dedup join.

package/build/dist/docs-index/{9bba71a2-4e86-4243-b28c-1ec807bff732.txt → 9ff44a91-f61c-45f0-9c73-ed7f4c8476da.txt}

@@ -11,7 +11,7 @@ Filters for searching the issues the caller can see. Every filter is optional; a
 
 - name: closedWithinDays (optional)
   type: integer
-  description: Include closed issues closed within this many days. Absent: 30 when `states` is absent, and no window when it is given.
+  description: Include closed issues closed within this many days. Absent: 30 when `states` is absent, with those closed as IGNORED or NOT_A_PROBLEM kept at any age, and no window when it is given. Given, it's exact.
 
 - name: cursor (optional)
   type: string
@@ -19,7 +19,7 @@ Filters for searching the issues the caller can see. Every filter is optional; a
 
 - name: entities (optional)
   type: object
-  description: Entity tags to match: every key must match, and any of a key's values matches it. An unprefixed key is put in the `entity:` namespace.
+  description: Entity tags to match: every key must match, and any of a key's values matches it. Keys and values match in any case. An unprefixed key is put in the `entity:` namespace.
 
 - name: fingerprint (optional)
   type: string
@@ -42,11 +42,11 @@ Filters for searching the issues the caller can see. Every filter is optional; a
 
 - name: query (optional)
   type: string
-  description: Full-text search over titles, descriptions and comments.
+  description: Words to search the whole issue for, comments included, split and stemmed as the issue is, so checkout-api is also checkout and api: an issue matches when it has any one of them, and those with the most, above all in their title, fingerprint and entities, come first.
 
 - name: states (optional)
   type: array of enum: `TRIAGE`, `READY`, `IN_PROGRESS`, `WAITING`, `MONITORING`, `CLOSED`
-  description: Only issues in these states. Absent: open issues plus those closed within `closedWithinDays`.
+  description: Only issues in these states. Absent: open issues plus those closed within `closedWithinDays`, and, when that is absent too, those closed as IGNORED or NOT_A_PROBLEM at any age.
 
 - name: teamIds (optional)
   type: array of string

package/build/dist/docs-index/{40c245da-0a20-4fd2-a610-7678ac053cce.txt → a080c770-2986-4983-bcbf-0197559485b1.txt}

@@ -34,7 +34,7 @@ Investigations are long-running and tool-heavy, so the model you choose changes
 
 The **Capabilities** step is where you choose the service account the agent acts as, the tools and skills it can use, the MCP servers it can call, and whether the pipeline changes it proposes need your approval. To learn more, see [_](/ai-agents/capabilities).
 
-The step ends with the **Memory and issues** section, which is collapsed. Every new agent records memories and works on issues, so open the section to turn off **Remember past investigations** or **Works on issues**, to set the store for searching memories by meaning, or to choose **Allow Ready** so the agent can file issues in Ready and move issues there. Every agent can search and read memories and issues, whichever switches are on. To learn more about memory, see [_](/ai-agents/memory). To learn more about how agents work on issues and pick up Ready issues, see [_](/ai-agents/issue-board).
+The step ends with the **Memory and issues** section, which is collapsed. Every new agent records memories and works on issues, so open the section to turn off **Remember past investigations** or **Works on issues**, to set the store for searching memories by meaning, or to choose **Allow Ready** so the agent can file issues in Ready and move issues there. Every agent can search and read memories and issues, whichever switches are on. After the agent exists, these settings are on its **Memories** and **Issues** steps. To learn more about memory, see [_](/ai-agents/memory). To learn more about how agents work on issues and pick up Ready issues, see [_](/ai-agents/issue-board).
 
 ### Step 4: Subscribe to signal sources \[#step4-subscriptions]
 
@@ -106,10 +106,11 @@ When a token budget is exhausted, new investigations stop starting and resume wh
 An agent's settings are spread across the steps on its page, which hold the same fields as the wizard:
 
 * **Behavior** holds the name, the system prompt, the model, and the limits.
-* **Capabilities** holds the service account, the tools, the skills, the MCP integrations, the change approval mode, and the **Memory and issues** section, which holds whether the agent works on issues.
+* **Capabilities** holds the service account, the tools, the skills, the MCP integrations, and the change approval mode.
 * **Memories** holds the memory settings and, below them, the memories the agent recorded.
+* **Issues** holds whether the agent works on issues, whether it can put issues in **Ready**, and which **Ready** issues it picks up. See [_](/ai-agents/issue-board).
 
-Changes to the settings on these three steps are held until you click **Save Changes**, so you can revise several steps in one pass. To abandon them, click **Discard Changes**. Subscriptions are not part of this and apply as soon as you make them. Neither are changes to individual memories on the **Memories** step: an edit, a verdict, or a delete applies as soon as you confirm it, and **Discard Changes** does not undo it.
+Changes to the settings on these four steps are held until you click **Save Changes**, so you can revise several steps in one pass. To abandon them, click **Discard Changes**. Subscriptions are not part of this and apply as soon as you make them. Neither are changes to individual memories on the **Memories** step: an edit, a verdict, or a delete applies as soon as you confirm it, and **Discard Changes** does not undo it.
 
 An investigation reads the agent's instructions, model, and limits when it starts, so correcting those mid-incident leaves the current run on the settings it began with and applies to the next one.