@grepr/cli 1.12.5 → 1.12.6-043e074

package/build/dist/docs-index/{d9c6142c-59ba-43ff-98da-5f293bccf0d4.txt → 0e7dfbaa-ab3e-4587-86ab-04094636d91e.txt}

@@ -16,7 +16,7 @@ Files a new issue. Creating never deduplicates: search first, and update or reco
 
 - name: entities (optional)
   type: object
-  description: The `entity:*` tags it concerns; an unprefixed key is put in the `entity:` namespace.
+  description: The `entity:*` tags it concerns; an unprefixed key is put in the `entity:` namespace. Keys are stored in lower case, and values as given; searches match both in any case.
 
 - name: evidence (optional)
   type: array of `IssueEvidence`

package/build/dist/docs-index/{64e607dd-a964-4e37-8080-f7c8349205d7.txt → 220c83c3-39e1-4948-88ef-41aa43699df2.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/{39cfcc50-b9f1-40df-9663-71ccb08bce05.txt → 2a91a232-8dc4-4b92-9c00-49c34ff8a064.txt}

@@ -122,6 +122,8 @@ The webhook mapping reads the service and host from field names Grepr expects. I
 
 Consistent tag values matter more than complete ones. A service tagged `checkout` in some memories and `checkout-svc` in others splits its history in two, and a timeline search finds only half. An agent can ask a search for the tag values already in use in your organization, so an agent that checks before recording reuses existing values rather than inventing new ones.
 
+Case doesn't split a history: `Service=Checkout` and `service=checkout` are the same tag.
+
 ## Set how an agent uses its memory \[#policy]
 
 The **Retrieval policy** settings on the agent's **Memories** step tell the agent how much to search and what to record. Grepr adds them to the agent's instructions, so you do not restate them in the agent's own prompt.

package/build/dist/docs-index/{04ca12b6-a71b-4ccb-a271-9a7037c8a5f2.txt → 3a95dc40-a1ec-48cd-9974-34caa27c38e3.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/{8ff17f53-39b5-44ed-b02d-1147af107067.txt → 3e803045-b08c-4256-a9e4-fa5d4515fa8b.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/{56aee1a4-07a3-43bf-b727-b37d59273eb5.txt → 49763710-fb42-4a72-974f-04149778ba8a.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/{4f3ca81d-147b-4709-8fb9-13c63ee78aef.txt → 7670da94-962e-4144-ba9a-b77df8c5f1c8.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