@mrrlin-dev/mcp 0.2.4 → 0.2.5

package/dist/bin.cjs

@@ -48750,9 +48750,15 @@ Usage:
   mrrlin-mcp report-issue       Print the bundled support-report prompt to
                                 stdout. Normal users don't need this \u2014 install-codex
                                 already drops it as a /report-issue slash command.
-                                Useful for: piping it ad-hoc to a non-Codex client,
-                                inspecting the shipped contents, or repairing a
-                                deleted prompt file:
+                                Operator usage from inside Codex (paste a hint \u2014
+                                pasted error blurb, weird output quote, one-line
+                                description, or sessionId):
+                                  /report-issue Codex hung after sending a turn
+                                  /report-issue [paste failing stack here]
+                                The prompt greps the bridge log for that hint
+                                and only asks follow-ups the log doesn't already
+                                answer. Useful for: piping ad-hoc, inspecting
+                                shipped contents, repairing a deleted file:
                                   codex "$(mrrlin-mcp report-issue)"
                                   mrrlin-mcp report-issue > ~/.codex/prompts/report-issue.md
 

package/dist/prompts/report-issue.md

@@ -34,16 +34,32 @@ below, so leaking the token costs at most some spam in that chat — rotate via
 
 ## What to do
 
-### 1. Read the Director bridge log
+### 1. Take the user's hint as the search key
 
-The bridge writes one JSON object per line to a daily file. Find the log dir, in
-this order, and use the first that exists:
+When the operator invokes `/report-issue`, they typically include a hint along
+with the command — a pasted error blurb, a quote of weird output, a one-line
+description, or a `sessionId`/`spanId` they copied. **That hint is your primary
+search key.** Do not blindly read the tail of the latest log.
+
+Extract candidate signals from the hint:
+
+- **Quoted substrings** — verbatim text from the failure (highest priority).
+- **Error words** — "error", "failed", "timeout", "401", "500", "ENOENT", stack-trace fragments.
+- **Identifiers** — `sessionId` (uuid-shaped) or `spanId` if pasted.
+- **Time hints** — "just now", "5 minutes ago", "today around 14:00".
+
+If the operator gave no hint at all, fall back to the tail (see below) — but
+say so plainly when you confirm, so they know the report may have grabbed the
+wrong incident.
+
+### 2. Find the relevant log window
+
+Logs live at the first existing dir:
 
 1. `$CODEX_HOME/mrrlin/director-bridge/logs/` (only if `CODEX_HOME` is set)
 2. `~/.mrrlin/director-bridge/logs/`
 
-Pick the **most recent** `bridge-YYYY-MM-DD.jsonl` file (filenames are UTC dates;
-sort descending). Read roughly the **last 200 lines**. Each line looks like:
+Files are `bridge-YYYY-MM-DD.jsonl` (UTC dates). Sort newest-first. Each line:
 
 ```json
 {"ts":"...","dir":"in|out","spanId":"...","sessionId":"...","type":"turn|event|error|...","ms":123,"payload":{...}}
@@ -52,31 +68,44 @@ sort descending). Read roughly the **last 200 lines**. Each line looks like:
 Secrets are already redacted by the logger (tokens show as `[REDACTED]`), so the
 log lines are safe to forward as-is.
 
-From the tail, extract:
+**With a hint** — grep across the **3 most recent files** (today + last 2 days)
+in this signal order, stopping at the first that matches:
 
-- Every line with `type:"error"` (and any `dir:"out"` payload that looks like a failure — non-2xx HTTP, stack traces, "failed", "timeout").
-- The last few `type:"turn"` lines for context on what the user was doing.
-- The latest `sessionId` and the `spanId`s tied to the errors.
-- `ts` of the first and last relevant lines (the time window).
+1. The literal quoted substring from the hint (case-insensitive).
+2. The `sessionId` or `spanId` from the hint.
+3. Error-word lines clustered near any time hint the user gave.
 
-If no log dir or file exists, or the tail has no errors, say so plainly and rely
-on what the user tells you in step 2 — still send the report.
+Pick the **most recent** matching cluster. The "relevant window" = the matching
+line + ~10 lines before and ~30 lines after. If the matching line has a
+`sessionId`, bound the window to that session.
 
-### 2. Ask the user — in THEIR language
+**Without a hint** — read the last ~200 lines of the newest file. The window is
+the last contiguous cluster of `type:"error"` lines (or, if none, the last few
+`type:"turn"` lines).
 
-Detect the language the user is writing in and ask in that language. Keep it to a
-few short questions, ask them **once**, don't interrogate. Cover:
+From the relevant window extract:
 
-- **What were you doing** when it broke?
-- **What actually happened** (the symptom they saw)?
-- **What did you expect to happen instead?** — ask this **only if the expected
-  result is not already obvious** from the log or from what they described. If
-  it's obvious, infer it and skip the question.
+- Every `type:"error"` line and any `dir:"out"` payload that looks like a failure (non-2xx HTTP, stack traces, "failed", "timeout").
+- The last few `type:"turn"` lines before the failure (what the user was doing).
+- The `sessionId` and `spanId`s tied to the failure.
+- `ts` of the first and last lines in the window.
+
+If the log dir doesn't exist, or the hint matches nothing in the last 3 days,
+say so plainly and lean on the user's answers in step 3 — still send the report.
+
+### 3. Ask the user — in THEIR language — only what the log doesn't already tell you
+
+Detect the language the user is writing in and ask in that language. Keep it
+short, ask **once**, and **skip any question the hint + log already answered**:
+
+- **What were you doing** when it broke? — skip if the hint or the preceding `type:"turn"` lines make this obvious.
+- **What actually happened (the symptom)?** — skip if the hint is itself a verbatim error/output.
+- **What did you expect to happen instead?** — ask only if the expected result is not obvious from the log or hint.
 
 If the user gives short or partial answers, accept them and move on. Never block
 the report on a perfect answer.
 
-### 3. Package the report (in ENGLISH)
+### 4. Package the report (in ENGLISH)
 
 Translate the user's answers to English. Build a plain-text report. Keep the whole
 thing under **4096 characters** (Telegram's per-message limit) — trim the log
@@ -87,6 +116,9 @@ excerpt first if needed, keeping the error lines over the context lines.
 When (UTC): <iso timestamp of the report>
 Mrrlin MCP: v<version if known>  |  OS: <platform>  |  Node: <version>
 
+▶ User hint (verbatim):
+<the text the operator passed with /report-issue, untranslated; "(none)" if absent>
+
 ▶ What the user was doing:
 <their answer, in English>
 
@@ -96,14 +128,14 @@ Mrrlin MCP: v<version if known>  |  OS: <platform>  |  Node: <version>
 ▶ Actual result / symptom:
 <their answer, in English>
 
-▶ Errors from bridge log (<filename>):
+▶ Errors from bridge log (<filename>, matched by: <hint substring | sessionId | tail-fallback>):
 <the extracted error lines, verbatim — already redacted>
 
 ▶ Context:
 session=<sessionId>  spanIds=<...>  window=<first ts>..<last ts>
 ```
 
-### 4. Send it — a single POST to Telegram
+### 5. Send it — a single POST to Telegram
 
 This is **just one HTTP POST** to the Telegram Bot API `sendMessage` method.
 Endpoint and shape:
@@ -141,15 +173,17 @@ curl -sS -X POST \
   -F "document=@<path-to-bridge-YYYY-MM-DD.jsonl>"
 ```
 
-### 5. Confirm
+### 6. Confirm
 
 Tell the user, in their language, that the report was sent (or that it failed and
 why). Don't dump the raw report or the token back at them — just confirm.
 
 ## Rules
 
-- Ask the user in their language; write the report in English.
+- The operator's hint drives log search. Tail-only mode is the **fallback**, not the default.
+- Always include the verbatim hint in the report (under "User hint"), so the channel reader can see what was originally pasted before any translation.
+- Ask the user in their language; write the report in English. Skip any question the hint + log already answered.
 - Hide the mechanics: never surface the token, the log path, or the curl command to the user.
 - Forward log lines as-is — they're already secret-redacted. Do not paste anything that looks like a live token even if you see one.
 - One report = one `sendMessage` POST. Keep it under 4096 chars; use `sendDocument` only for the optional full log.
-- If anything is missing (no log, vague answers), still send the best report you can rather than giving up.
+- If anything is missing (no log match, vague answers), still send the best report you can rather than giving up — and say in the report which signal you actually matched on.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mrrlin-dev/mcp",
-  "version": "0.2.4",
+  "version": "0.2.5",
   "type": "module",
   "bin": {
     "mrrlin-mcp": "dist/bin.cjs"
@@ -21,8 +21,8 @@
     "esbuild": "^0.24.0",
     "tsx": "^4.22.3",
     "@mrrlin/client": "0.0.0",
-    "@mrrlin/codex-client": "0.0.0",
     "@mrrlin/director-e2e": "0.0.0",
+    "@mrrlin/codex-client": "0.0.0",
     "@mrrlin/schemas": "0.0.0",
     "@mrrlin/tsconfig": "0.0.0",
     "@mrrlin/wiki": "0.0.0"