fix: read the renamed results file and explain the issue counts

.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "datasqrl",
   "displayName": "DataSQRL",
-  "version": "0.3.0",
+  "version": "0.3.1",
   "description": "Plan and implement DataSQRL data pipelines with the Dockerized DataSQRL Code Agent.",
   "author": {
     "name": "DataSQRL",

.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "datasqrl",
-  "version": "0.3.0",
+  "version": "0.3.1",
   "description": "Plan and implement DataSQRL data pipelines with the Dockerized DataSQRL Code Agent.",
   "author": {
     "name": "DataSQRL",

.cursor-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "datasqrl",
-  "version": "0.3.0",
+  "version": "0.3.1",
   "description": "Plan and implement DataSQRL data pipelines with the Dockerized DataSQRL Code Agent.",
   "author": {
     "name": "DataSQRL",

DATA_HANDLING.md

@@ -28,7 +28,7 @@ The project directory is the only place a run can write. A run writes these file
 - `adr/requirements_<ts>.md` and `adr/plan_<ts>.md`, the requirements and the plan.
 - `AGENTS.md` and `.claude/`, the agent's instructions, its progress trail and its structured run log (`.claude/codeagent_logs.jsonl.bak`).
 - `build/`, the compiler output.
-- `.code_agent_results.json`, the run history.
+- `.datasqrl_agent_results.json`, the run history.
 - The DataSQRL project files the agent creates or edits.
 
 ## Environment variables

README.md

@@ -50,7 +50,7 @@ command open. Runs are therefore started **detached** and the launch returns in
 The run belongs to the Docker daemon, not to your session, which means:
 
 - **Close the session, interrupt your agent, reboot your editor** — the run finishes anyway and
-  still writes `.code_agent_results.json`.
+  still writes `.datasqrl_agent_results.json`.
 - **You follow it from another terminal.** The launch prints the command, `tail -f` on the run's progress log, that shows what the agent is doing as it happens. Ask your agent whether it is still going, what the output means, or to stop it (`progress`).
 - **Your agent learns when it ends.** Right after the launch, the agent starts `datasqrl-agent.sh --wait` in the background. That command waits for the run and prints the result when the run ends, so the agent reports back on its own. You can still ask at any time (`progress`).
 - **`progress` works from anywhere** — a different session, hours later, on a run you did not start.

scripts/datasqrl-agent.sh

@@ -662,7 +662,7 @@ RUN_NAME="datasqrl-agent-${PROJECT_SLUG}-$(_short_hash "$PROJECT_ABS")"
 # line, `+HH:MM:SS  KIND   text`, continuation lines indented. Truncated when a run starts and left
 # in place afterwards, so the last run's trail can be revisited until the next run overwrites it.
 PROGRESS_PATH="$PROJECT_ABS/.claude/datasqrl-agent-progress.txt"
-RESULTS_PATH="$PROJECT_ABS/.code_agent_results.json"
+RESULTS_PATH="$PROJECT_ABS/.datasqrl_agent_results.json"
 
 # --- Shared helpers ----------------------------------------------------------------------------
 run_is_live() {
@@ -699,20 +699,40 @@ fmt_elapsed() {
 # before failing on the bogus `%m` operand; GNU `stat -c` fails cleanly (no stdout) on BSD.
 file_mtime() { stat -c %Y "$1" 2>/dev/null || stat -f %m "$1" 2>/dev/null; }
 
-# Read one field out of the pretty-printed .code_agent_results.json.
+# Read one field out of the pretty-printed results file. The newest run is first, so the first
+# match belongs to it.
 result_field() {
     [ -f "$RESULTS_PATH" ] || return 0
     grep -m1 "\"$1\"" "$RESULTS_PATH" 2>/dev/null \
         | sed 's/.*: *//; s/[",]//g; s/^ *//; s/ *$//'
 }
 
+result_issues() {
+    _score="$(result_field issue_score)"
+    case "$_score" in ''|null) return 0 ;; esac
+    awk '
+        /"issue_count": \{/ { inside = 1; next }
+        inside && /}/ { exit }
+        inside {
+            gsub(/[",]/, ""); split($0, kv, ":"); key = kv[1]; val = kv[2]
+            gsub(/ /, "", key); gsub(/ /, "", val)
+            if (key == "total") total = val
+            else counts = counts (counts == "" ? "" : ", ") val " " key
+        }
+        END { printf "%s issue(s) (%s)", total, counts }
+    ' "$RESULTS_PATH"
+    printf ' · score %s' "$_score"
+}
+
 result_summary() {
     [ -f "$RESULTS_PATH" ] || return 0
     _ok="$(result_field success)"
     if [ "$_ok" = "true" ]; then _ok="success"; else _ok="failed"; fi
-    printf '%s · %s · %s · %s refinement(s) · %s issue(s)' \
-        "$_ok" "$(result_field mode)" "$(result_field scenario)" \
-        "$(result_field refinements)" "$(result_field issue_count)"
+    printf '%s · %s · %s · %s refinement(s)' \
+        "$_ok" "$(result_field mode)" "$(result_field scenario)" "$(result_field refinements)"
+    _issues="$(result_issues)"
+    [ -n "$_issues" ] && printf ' · %s' "$_issues"
+    return 0
 }
 
 # --- Actions: status / stop / wait -------------------------------------------------------------

skills/implement/SKILL.md

@@ -55,6 +55,7 @@ The run is still going. Start the same `--wait` command again in the background
 
 Do this when the background `--wait` ends with the line `No run in progress. Last result: …`, or when the user asks you how the run went (the [`progress` skill](../progress/SKILL.md) tells you whether it has finished) and it shows that the run finished.
 
-Read `.code_agent_results.json` and report success, mode, refinements, and issue score/count. If the file is absent, say so.
+Read the newest run, the first entry of `runs` in `.datasqrl_agent_results.json`, and report success, mode, refinements, `issue_score` and the counts for each severity in `issue_count`. If the file is absent, say so.
+`success` means the final iteration passed its tests. The judges' issues, each one listed in `issues`, are review notes only.
 That report is the complete deliverable, for every outcome. Stop after the report.
 The containerized agent has already run its own compile → test → judge → refine loop, so the result it returns is final and every change it made is already applied.

skills/patch/SKILL.md

@@ -73,6 +73,8 @@ The run is still going. Start the same `--wait` command again in the background
 
 Do this when the background `--wait` ends with the line `No run in progress. Last result: …`, or when the user asks you how the run went (the [`progress` skill](../progress/SKILL.md) tells you whether it has finished) and it shows that the run finished.
 
-Read `.code_agent_results.json` and report success, mode, refinements, and issue score/count. If the file is absent, say so.
+Read the newest run, the first entry of `runs` in `.datasqrl_agent_results.json`, and report success, mode and refinements. If the file is absent, say so.
+`success: true` means the patch passed its tests. `success: false` means the tests still failed after the fix round, or the agent could not run.
+A patch run has no judges, so its `issue_score` is `null` and it has no issues to report.
 That report is the complete deliverable, for every outcome. Stop after the report.
 The containerized agent has already run its own implement → test → fix loop, so the result it returns is final and every change it made is already applied.

skills/progress/SKILL.md

@@ -33,11 +33,11 @@ The trail has one line per event, `+HH:MM:SS  KIND   text`, where the stamp is t
 - `INFO` and `JUDGE`: other orchestrator messages, for example per-package judge results.
 - `WARN`: a recoverable problem, for example `tests failed, retrying`.
 - `ERROR`: a failure; `Run stopped (SIGTERM)` means someone stopped the run.
-- `DONE`: the end: `Finished · success|failed · mode · scenario · N refinement(s) · K issue(s)`.
+- `DONE`: the end: `Finished · success|failed · mode · scenario · N refinement(s) · K issue(s) (C critical, H high, M medium, L low) · score S`. `success` means the final pass passed its tests. The issues are review notes from the judges, not a run fail. Each issue is in the `issues` list of `.datasqrl_agent_results.json`.
 
 ## What an iteration is
 
-Iteration 0 implements the plan: the coding agent works through the plan's checklist, compiling and testing as it goes (every `cmd.sh test` line is one compile-and-test run while `cmd.sh compile` is a compile run only). Then the orchestrator runs the tests itself (`running tests`) and, for implementation runs, a panel of LLM judges reviews the result (`verifying`), which ends in `verified (K issues, score S)`. When the score is too high the run enters iteration 1: the agent fixes the reported issues, then tests and judges run again. `Finalizing` is the last gate, README and plan-checklist completeness. Planning and patch runs have no judge panel. An implementation usually takes 30 to 60 minutes; planning and patches take minutes.
+Iteration 0 implements the plan: the coding agent works through the plan's checklist, compiling and testing as it goes (every `cmd.sh test` line is one compile-and-test run while `cmd.sh compile` is a compile run only). Then the orchestrator runs the tests itself (`running tests`) and, for implementation runs, a panel of LLM judges reviews the result (`verifying`), which ends in `verified (K issues, score S)`. When the score is too high and a refinement remains, the run enters iteration 1: the agent fixes the reported issues, then tests and judges run again. The score decides only whether another iteration runs. `Finalizing` is the last gate, README and plan-checklist completeness. Planning and patch runs have no judge panel. An implementation usually takes 30 to 60 minutes; planning and patches take minutes.
 
 ## Stuck or working?
 

skills/start/SKILL.md

@@ -117,7 +117,7 @@ A run takes three choices: the harness, the model provider and the model. Settle
 For the run choices, take the source that applies:
 
 1. **The user named them** in this conversation: use those.
-2. **An earlier run in this project:** when `.code_agent_results.json` exists, ask in one line whether to reuse the `harness`, `provider` and `model` of its last run.
+2. **An earlier run in this project:** when `.datasqrl_agent_results.json` exists, ask in one line whether to reuse the `harness`, `provider` and `model` of its last run.
 3. **Otherwise, ask once.** Run `bash "$CODEAGENT" --show-options` and tell the user the default: the `anthropic` provider, with its default models for planning and implementation. Name the providers it marks `ready`, say that any provider in the list works once its variables are set, and ask which they want.
 
 The user makes each choice: the provider, the model and, for Amazon Bedrock, the AWS profile. Present the options neutrally, without promoting any provider, model or agent.
@@ -233,7 +233,7 @@ Condition 3 is satisfied by a statement referring to the plan just summarized 
 
 ### After any agent run
 
-The containerized agent runs its own compile → test → refine loop, plus judges in Lane B. Report the outcome it returns and end the turn. Every outcome (success, judge rejection, compile failure, test failure, error) is a finished result.
+The containerized agent runs its own compile → test → refine loop, plus judges in Lane B. Report the outcome it returns and end the turn. Every outcome (success, review notes, compile failure, test failure, error) is a finished result. Judge issues are review notes on a successful run, not a failure.
 
 The result is the end of the build. The agent does not commit the changes automatically, so the agent's work might be uncommitted in the working tree. After the agent run, express user to observe and review the changes done by agent, and then if the latest changes meet their requirements, tell them that they may commit and push the latest changes to remote remo.
 Deploying begins when the user asks for it, as a request of its own.