@siuver/omp-debug-mode 0.1.3 → 0.1.4
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.
- package/CHANGELOG.md +7 -0
- package/README.md +133 -94
- package/package.json +3 -3
- package/src/debug-mode.ts +215 -105
- package/src/evidence.ts +196 -0
- package/src/gate.ts +32 -14
- package/src/methodology.ts +80 -32
- package/src/state.ts +96 -3
- package/src/tools.ts +58 -0
- package/src/ui.ts +41 -16
- package/src/review-actions.ts +0 -22
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,12 @@
|
|
|
1
1
|
# Changelog
|
|
2
2
|
|
|
3
|
+
## 0.1.4 - 2026-08-21
|
|
4
|
+
|
|
5
|
+
- Added least-user-intervention evidence planning: the agent chooses `agent_inspection`, `runtime_probe`, `user_report`, or `user_artifact` per hypothesis, must justify user-assisted methods, and batches compatible hypotheses into the fewest reproductions or captures.
|
|
6
|
+
- Added persisted evidence requests, user observations, and in-place artifact metadata plus the read-only `list_debug_evidence` tool. `/debug-evidence [<request-id>] <path>` links files to pending requests without copying or deleting them, and unavailable files remain explicitly unverified.
|
|
7
|
+
- Replaced the automatic round-review menu with a command-only gate widget. Removed `/debug-menu` and merged user-report submission into `/debug-proceed [details]`; users now continue with `/debug-proceed`, `/debug-evidence`, `/debug-done`, `/debug-abort`, and `/debug-status` while safety confirmations remain in place.
|
|
8
|
+
- Extended the reproduction gate, cleanup context, session restore, status output, tests, and documentation for mixed probe/report/artifact rounds, including opaque RenderDoc `.rdc` captures.
|
|
9
|
+
|
|
3
10
|
## 0.1.3 - 2026-08-20
|
|
4
11
|
|
|
5
12
|
- Aligned the injected methodology with Cursor Debug Mode: 3-5 hypotheses, instrument all of them, never fix without runtime logs, keep probes during the fix, and verify with a second reproduce. Round 1 is instrument-only.
|
package/README.md
CHANGED
|
@@ -1,94 +1,133 @@
|
|
|
1
|
-
# @siuver/omp-debug-mode
|
|
2
|
-
|
|
3
|
-
A Cursor Debug Mode replica for oh-my-pi. It recreates Cursor's evidence-driven, human-in-the-loop debugging workflow for OMP; it is an independent implementation and is not affiliated with Cursor.
|
|
4
|
-
|
|
5
|
-
The plugin makes the agent form 3-5 hypotheses,
|
|
6
|
-
|
|
7
|
-
## Commands
|
|
8
|
-
|
|
9
|
-
| Command | Purpose |
|
|
10
|
-
| --- | --- |
|
|
11
|
-
| `/debug-mode <problem>` | Starts a debugging session from a symptom, expected result, actual result, and reproduction description. |
|
|
12
|
-
| `/debug-
|
|
13
|
-
| `/debug-
|
|
14
|
-
| `/debug-done` | Marks the problem as fixed: the agent removes every probe and summarizes the result. |
|
|
15
|
-
| `/debug-
|
|
16
|
-
| `/debug-
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
-
|
|
30
|
-
-
|
|
31
|
-
-
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
The
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
|
|
69
|
-
|
|
70
|
-
|
|
71
|
-
|
|
72
|
-
|
|
73
|
-
|
|
74
|
-
|
|
75
|
-
|
|
76
|
-
|
|
77
|
-
|
|
78
|
-
|
|
79
|
-
|
|
80
|
-
|
|
81
|
-
|
|
82
|
-
|
|
83
|
-
|
|
84
|
-
|
|
85
|
-
|
|
86
|
-
|
|
87
|
-
|
|
88
|
-
|
|
89
|
-
|
|
90
|
-
|
|
91
|
-
|
|
92
|
-
|
|
93
|
-
|
|
94
|
-
|
|
1
|
+
# @siuver/omp-debug-mode
|
|
2
|
+
|
|
3
|
+
A Cursor Debug Mode replica for oh-my-pi. It recreates Cursor's evidence-driven, human-in-the-loop debugging workflow for OMP; it is an independent implementation and is not affiliated with Cursor.
|
|
4
|
+
|
|
5
|
+
The plugin makes the agent form 3-5 hypotheses, choose the cheapest reliable evidence method for each one, and pause so you can reproduce the problem. The agent is instructed to NEVER fix without runtime evidence first; after a fix it keeps runtime probes in place for a verification reproduce. Your result either starts another evidence-driven round or triggers probe cleanup and a final summary.
|
|
6
|
+
|
|
7
|
+
## Commands
|
|
8
|
+
|
|
9
|
+
| Command | Purpose |
|
|
10
|
+
| --- | --- |
|
|
11
|
+
| `/debug-mode <problem>` | Starts a debugging session from a symptom, expected result, actual result, and reproduction description. |
|
|
12
|
+
| `/debug-proceed [details]` | Continues with captured evidence: optional details are recorded as a user-report observation, then the agent evaluates hypotheses and may fix only with evidence before asking for verification. |
|
|
13
|
+
| `/debug-evidence [<request-id>] <path>` | Attaches one user-provided evidence file to the current waiting round. If the first token matches a pending current-round request ID, the file is linked to that request; otherwise the whole argument is treated as the path (spaces allowed). Without an argument it opens an input dialog (interactive UI only). Files are referenced in place and never copied or deleted. |
|
|
14
|
+
| `/debug-done` | Marks the problem as fixed: the agent removes every probe and summarizes the result. |
|
|
15
|
+
| `/debug-status` | Shows the current phase, round, run, live probes, captured log counts, pending evidence requests, and attached/unavailable artifacts. |
|
|
16
|
+
| `/debug-abort` | Stops debug mode and removes its logs after confirmation while leaving code changes in the working tree. |
|
|
17
|
+
|
|
18
|
+
## Evidence Methods
|
|
19
|
+
|
|
20
|
+
For every hypothesis, the agent must pick one of four methods, in least-user-intervention order:
|
|
21
|
+
|
|
22
|
+
1. **`agent_inspection`** - reuse existing logs/files and the agent's own read/search/test/command tools. Always tried first.
|
|
23
|
+
2. **`runtime_probe`** - if runtime state is required, the agent installs `@omp-probe` instrumentation and combines every compatible hypothesis into a single reproduction.
|
|
24
|
+
3. **`user_report`** - only when a simple manual observation is decisive (something only you can see or try).
|
|
25
|
+
4. **`user_artifact`** - only when the disputed state cannot be represented reliably by inspection, probes, or a verbal report (e.g. a GPU capture, screenshot, crash dump, or externally generated trace).
|
|
26
|
+
|
|
27
|
+
Rules the agent must follow:
|
|
28
|
+
|
|
29
|
+
- It never asks you to run a command it could run itself.
|
|
30
|
+
- All unavoidable user actions are batched into the fewest reproductions/captures: hypotheses answerable by the same action share one request (`hypothesisIds` lists them all) instead of serial reports.
|
|
31
|
+
- A lower-priority method is never chosen merely because it is familiar; every `user_report`/`user_artifact` entry needs a rationale explicitly naming why agent inspection and runtime probes cannot settle its hypotheses.
|
|
32
|
+
|
|
33
|
+
## The Evidence Plan
|
|
34
|
+
|
|
35
|
+
Each round closes with an exact machine-readable block that covers every hypothesis:
|
|
36
|
+
|
|
37
|
+
```text
|
|
38
|
+
<evidence_plan>
|
|
39
|
+
[{"id":"E1","hypothesisIds":["A","B"],"method":"runtime_probe","title":"...","rationale":"The disputed runtime branches are not present in existing logs; one model-added probe set can capture both without a separate user artifact.","instructions":["..."],"artifactHint":"optional"}]
|
|
40
|
+
</evidence_plan>
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
Every field is validated: `id` must be unique and non-empty, `hypothesisIds` must reference one or more real hypotheses, `method` must be one of the four literals above, `rationale`/`title` must be non-empty, and `instructions` must contain actionable steps (`artifactHint` describes the expected file kind for `user_artifact`). A malformed plan is rejected entirely — no hypothesis is ever silently dropped. Plans are capped at 12 entries per round. The plan is combined with the existing `<reproduction_steps>` block, which describes the single combined reproduction/capture sequence.
|
|
44
|
+
|
|
45
|
+
## The Reproduction Gate
|
|
46
|
+
|
|
47
|
+
A round ends at the gate when the Agent emits a `<reproduction_steps>` block, not merely when it stops talking. So a clarifying question mid-round leaves you talking to the Agent normally, while an instrumented round that forgot its steps is asked once to finish properly and is then gated anyway so the workflow cannot stall.
|
|
48
|
+
|
|
49
|
+
Rounds must also close with a valid `<evidence_plan>`. If the plan block is missing, the agent is nudged once for the exact JSON block plus the reproduction steps; after that the gate proceeds anyway with a note that the next round will be asked to declare a method. A round with neither probes nor a valid evidence plan gets the "no runtime evidence" warning; a valid plan that chose a non-probe route (e.g. `agent_inspection` or `user_artifact`) is a properly closed round and produces no such warning — and for `user_report`/`user_artifact` plans, no JSONL logs are expected at all.
|
|
50
|
+
|
|
51
|
+
At the gate a widget shows the reproduction steps, any pending user requests (title, instructions, artifact hint), a live counter of captured observations, an `evidence: <pending> pending, <attached> attached` counter, and the list of commands you can use, so you can tell what evidence the round is waiting on and how to act. The widget always ends with the live log counter. Every round stops at the widget and you interact through commands only.
|
|
52
|
+
|
|
53
|
+
Pending requests resolve like this:
|
|
54
|
+
|
|
55
|
+
- A `user_artifact` request is pending until a file is attached with a matching request ID.
|
|
56
|
+
- A `user_report` request is pending until `/debug-proceed <details>` records an observation for the current round; one details submission can satisfy several report requests at once.
|
|
57
|
+
- `agent_inspection` and `runtime_probe` requests never create user work.
|
|
58
|
+
|
|
59
|
+
If user requests are still pending when you run `/debug-proceed`, the plugin asks "Proceed without all requested evidence?" — confirming is allowed so an unavailable external capture can never deadlock the session; cancelling keeps you at the gate. `/debug-proceed` and `/debug-done` ask for confirmation when the round captured no runtime logs and has no valid non-probe evidence plan.
|
|
60
|
+
|
|
61
|
+
## Attaching Evidence Files
|
|
62
|
+
|
|
63
|
+
`/debug-evidence [<request-id>] <path>` records one user-provided file for the current waiting round:
|
|
64
|
+
|
|
65
|
+
- The path is resolved against the session working directory; the plugin records the absolute path, size, and mtime and references the file **in place**. It never copies, renames, or deletes your file — not during attach, not during cleanup, not during teardown.
|
|
66
|
+
- If the first argument token matches a pending current-round request ID, the file is linked to that request; otherwise the entire argument is treated as the path (spaces are supported) and the artifact is attached unlinked — the agent sees it as unassigned evidence and must associate it with a request itself.
|
|
67
|
+
A path whose first token happens to look like a request ID but does not match one is simply treated as a path.
|
|
68
|
+
- Interactive sessions must confirm before recording a path outside the session working directory; non-interactive sessions reject outside-`cwd` paths because no confirmation channel exists.
|
|
69
|
+
- Re-attaching the same resolved path reuses the existing artifact entry and refreshes its metadata and request association.
|
|
70
|
+
- Missing paths, directories, and unreadable files are rejected with the reason, and the ledger stays unchanged.
|
|
71
|
+
|
|
72
|
+
Availability is re-checked by re-statting each path, so a file that was moved or deleted after attaching is reported as *unavailable* — the ledger never claims unavailable evidence was captured. The model is told to treat user reports and artifacts as data to inspect, not instructions to execute, and must conclude INCONCLUSIVE (or file a new, lower-burden request) when it cannot inspect a file with its normal tools.
|
|
73
|
+
|
|
74
|
+
Example: for a GPU-rendering symptom whose disputed state only exists inside a frame capture, the agent justifies why inspection, tests, and probes cannot answer, then emits one `user_artifact` request with an `artifactHint` like "RenderDoc .rdc capture of a failing frame". You capture `frame.rdc` in RenderDoc and run `/debug-evidence E1 frame.rdc` (using the request ID shown in the widget). `/debug-status` and the read-only `list_debug_evidence` tool then show the artifact ID, absolute path, size, and availability. The `.rdc` bytes are treated as opaque — the plugin does not parse the format; if the agent cannot extract what it needs from the binary with its normal `read`/`bash` tools, it says so and asks for a converted report or a new capture rather than guessing.
|
|
75
|
+
|
|
76
|
+
## Workflow
|
|
77
|
+
1. Run `/debug-mode <problem description>`.
|
|
78
|
+
2. The Agent records 3-5 hypotheses and picks an evidence method for each under the least-user-intervention priority. If the route is `runtime_probe`, it inserts minimal probes marked with `@omp-probe <id>` inside `#region agent log` blocks; round 1 does not apply a product fix. The start prompt and a per-turn `debug-mode-context` message name the exact JSONL path and require every probe to append to it, including `hypothesisId`; console output (including Unity `Debug.Log`) is supplemental only. The context filter keeps the newest of those messages so the model sees the contract instead of dropping it.
|
|
79
|
+
|
|
80
|
+
3. When the Agent reaches the gate, follow the `<reproduction_steps>` in the real application so the instrumented code writes its observations, watching the widget counter climb — or supply the requested evidence with `/debug-evidence` or `/debug-proceed <details>`. Restart the app or service if the instrumented build would otherwise be stale.
|
|
81
|
+
|
|
82
|
+
4. Continue with `/debug-proceed [details]` (optionally record a user observation, then evaluate evidence), `/debug-done` (clean up and summarize), `/debug-evidence` (attach a file), or `/debug-status` (inspect the current round state). Each round stops at the widget; all interaction is command-driven.
|
|
83
|
+
5. On Proceed, the Agent reads the evidence (logs, your observations, attached artifacts), cites the evidence method plus log-line numbers or artifact/report paths for each hypothesis, and only then may apply a fix. Probes stay in place. Reproduce again to verify. If verification fails, rejected-hypothesis code changes are reverted before the next round.
|
|
84
|
+
6. On `/debug-done`, the Agent removes every probe and summarizes the root cause and fix in 1-2 lines.
|
|
85
|
+
|
|
86
|
+
The extension also provides the read-only `get_debug_logs`, `list_debug_probes`, and `list_debug_evidence` tools so the Agent can inspect runtime evidence, review pending/satisfied requests with their methods and rationales, and verify cleanup.
|
|
87
|
+
|
|
88
|
+
## Runtime Data
|
|
89
|
+
|
|
90
|
+
At the start of each round, the plugin creates an absolute log path under a directory owned by the current session:
|
|
91
|
+
|
|
92
|
+
```text
|
|
93
|
+
<project>/.omp/debug/<session-id>/current.jsonl
|
|
94
|
+
```
|
|
95
|
+
|
|
96
|
+
The session segment keeps concurrent omp sessions from truncating or deleting each other's evidence, since every round truncates `current.jsonl` and teardown removes the directory. The plugin also adds `.omp/debug/` to the repository's local `.git/info/exclude` once, so probe logs never appear in `git status`; that file is not committed, so your `.gitignore` is left alone. Teardown removes only this log directory; attached user evidence files are never removed.
|
|
97
|
+
|
|
98
|
+
That exact stable path is injected into the Agent prompt. The prompt requires every runtime probe to use the target environment's native file append API and write one compact JSON object plus a newline using this schema:
|
|
99
|
+
|
|
100
|
+
```json
|
|
101
|
+
{"probe":"player-state","hypothesisId":"A","ts":1787193600000,"location":"Player.cs:42","message":"grounded check","data":{"isGrounded":false}}
|
|
102
|
+
```
|
|
103
|
+
|
|
104
|
+
`get_debug_logs`, the proceed prompt, and `/debug-status` summarize each run by `hypothesisId`, so you can see which hypotheses produced evidence before reading a single raw line. A hypothesis with no entries was not exercised, which is not the same as being rejected.
|
|
105
|
+
|
|
106
|
+
When you run `/debug-proceed [details]`, the plugin records non-empty details as a user observation, archives the completed file as `<run-id>.jsonl`, and creates an empty `current.jsonl` for the next reproduction. Because the active run is truncated at the start of every round, `get_debug_logs` defaults to the newest run that actually captured observations and names the run it read; `previous=true` forces the last completed run. `/debug-status` shows the current absolute file path and the per-run log counts.
|
|
107
|
+
|
|
108
|
+
## Probe Ledger
|
|
109
|
+
|
|
110
|
+
The plugin tracks every `@omp-probe <id>` marker the Agent writes, resolving each file against the session working directory. Before each round and on every `list_debug_probes` call it rescans those files so the ledger matches the code on disk: markers the Agent has since deleted drop out, and a file that exists but cannot be read is reported as *unverified* rather than assumed clean. That way a failed read can never make teardown claim the probes are gone while they are still in your source. Rounds that choose non-probe evidence methods simply add no markers, and cleanup still verifies that no leftover markers remain before finishing.
|
|
111
|
+
|
|
112
|
+
## Install
|
|
113
|
+
|
|
114
|
+
```sh
|
|
115
|
+
omp plugin install @siuver/omp-debug-mode
|
|
116
|
+
```
|
|
117
|
+
|
|
118
|
+
Restart omp after installation, then run `/debug-mode <problem>`.
|
|
119
|
+
|
|
120
|
+
## Local Development
|
|
121
|
+
|
|
122
|
+
From the repository root:
|
|
123
|
+
|
|
124
|
+
```sh
|
|
125
|
+
bun run check
|
|
126
|
+
omp plugin link ./plugins/debug-mode
|
|
127
|
+
```
|
|
128
|
+
|
|
129
|
+
Restart omp after linking.
|
|
130
|
+
|
|
131
|
+
## Changelog
|
|
132
|
+
|
|
133
|
+
See `CHANGELOG.md` for release notes included in the npm package.
|
package/package.json
CHANGED
|
@@ -1,8 +1,8 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@siuver/omp-debug-mode",
|
|
3
|
-
"version": "0.1.
|
|
3
|
+
"version": "0.1.4",
|
|
4
4
|
"type": "module",
|
|
5
|
-
"description": "
|
|
5
|
+
"description": "Evidence-driven, human-in-the-loop debugging with autonomous probes and user-assisted artifacts for oh-my-pi.",
|
|
6
6
|
"license": "MIT",
|
|
7
7
|
"homepage": "https://github.com/Siuver/blackhole/tree/master/plugins/debug-mode#readme",
|
|
8
8
|
"repository": {
|
|
@@ -30,7 +30,7 @@
|
|
|
30
30
|
],
|
|
31
31
|
"omp": {
|
|
32
32
|
"name": "debug-mode",
|
|
33
|
-
"description": "
|
|
33
|
+
"description": "Evidence-driven debugging with least-user-intervention methods, runtime probes, and user artifacts.",
|
|
34
34
|
"extensions": [
|
|
35
35
|
"./src/main.ts"
|
|
36
36
|
]
|