ww-agentic-workflows 1.0.0.dev5__tar.gz → 1.0.0.dev7__tar.gz

{ww_agentic_workflows-1.0.0.dev5 → ww_agentic_workflows-1.0.0.dev7}/CHANGELOG.md

@@ -9,8 +9,21 @@ The committed package version stays at 0.1.0; development snapshots from `dev`
 use `1.0.0.devN`. What may change between two pulls, and what ww does not promise
 yet, is in [documentation/limitations.md](documentation/limitations.md).
 
+## 2026-10-06
+
+- Added: three `ww.json` switches, off by default: `debug.collect` keeps a local record per run of how ww itself
+  behaved (`.ww/debug/`), `debug.report` makes `discover` offer to publish them as GitHub issues through the new
+  `debug report` command, each shown and confirmed first, and `feedback.collect` keeps a local record of how the
+  workflow was composed (`.ww/feedback/`), read with `workflow-feedback`; skills `ww-debug-report` and
+  `ww-workflow-feedback` cover the agent side. `4f11e89`
+
 ## 2026-10-05
 
+- Fixed: in the `auto` runtime, a worker's `loop --continue` below the loop's limit left the task stuck: the
+  continue ended the assignment yet opened the next round's first step for a worker that no longer held a
+  token, so the worker's next command was refused and the manager's `next` reported a step in progress. The
+  continue now ends the assignment with its handoff block, and the manager's `next` dispatches the first step
+  of the next round as a new assignment.
 - Removed: the session-start task list, stop reminders, interruption records and transcript recovery, and the
   `interrupted` command. Hooks, events and `agent_hooks` keys stay accepted. `5414a34`
 - Added: `add-child` is accepted while a per-child stage of a roadmap-style parent is active, not only while the

{ww_agentic_workflows-1.0.0.dev5 → ww_agentic_workflows-1.0.0.dev7}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: ww-agentic-workflows
-Version: 1.0.0.dev5
+Version: 1.0.0.dev7
 Summary: A local-first, resumable workflow CLI for people and AI agents.
 Project-URL: Homepage, https://agenticworkflows.dev
 Project-URL: Documentation, https://github.com/from-developers-for-developers/agentic-workflows/tree/main/documentation
@@ -399,6 +399,15 @@ default; set `"feedback_learning": false` in `ww.json` to disable it. Invoke
 stale points. See [feedback learning](documentation/features.md#learning-from-operator-feedback)
 for commands and examples.
 
+Two further switches in `ww.json`, off by default, keep local run reports:
+`debug.collect` asks the agent at the end of each run how ww itself behaved and
+keeps the answer under `.ww/debug/`, and `feedback.collect` asks how well the
+workflow was composed, kept under `.ww/feedback/`. Nothing leaves the machine
+by itself: `./ww debug report` publishes a debug record to ww's GitHub issues
+only after showing it and asking, and the `ww-workflow-feedback` skill reviews
+the feedback with you. See [collecting debug info and workflow
+feedback](documentation/features.md#collecting-debug-info-and-workflow-feedback).
+
 ### Runtimes: who actually performs a step
 
 Every task runs manager and worker responsibilities — the manager dispatches

{ww_agentic_workflows-1.0.0.dev5 → ww_agentic_workflows-1.0.0.dev7}/README.md

@@ -361,6 +361,15 @@ default; set `"feedback_learning": false` in `ww.json` to disable it. Invoke
 stale points. See [feedback learning](documentation/features.md#learning-from-operator-feedback)
 for commands and examples.
 
+Two further switches in `ww.json`, off by default, keep local run reports:
+`debug.collect` asks the agent at the end of each run how ww itself behaved and
+keeps the answer under `.ww/debug/`, and `feedback.collect` asks how well the
+workflow was composed, kept under `.ww/feedback/`. Nothing leaves the machine
+by itself: `./ww debug report` publishes a debug record to ww's GitHub issues
+only after showing it and asking, and the `ww-workflow-feedback` skill reviews
+the feedback with you. See [collecting debug info and workflow
+feedback](documentation/features.md#collecting-debug-info-and-workflow-feedback).
+
 ### Runtimes: who actually performs a step
 
 Every task runs manager and worker responsibilities — the manager dispatches

{ww_agentic_workflows-1.0.0.dev5 → ww_agentic_workflows-1.0.0.dev7}/WW_AGENT_INSTRUCTIONS.md

@@ -13,14 +13,12 @@ Before starting new work, run:
 ./ww discover
 ```
 
-It lists the project's workflows, modes, the start command, and
-whether to use ww unasked. If disabled, stop; if used only on request, use it only when
-the user asks for ww. Choose the matching workflow and keep its default modes
-unless the request matches another mode; ask only when the choice would
-materially change the work.
-
-When a request names an external ticket, use that as the task ID. Omit the ID
-only when none is named or the workflow obtains it in its first step.
+It lists the workflows, modes, the start command, and whether to use ww
+unasked. If disabled, stop; if used only on request, use it only when the user
+asks for ww. Choose the matching workflow and keep its default modes unless the
+request matches another mode; ask only when the choice would materially change
+the work. When a request names an external ticket, use that as the task ID.
+Omit the ID only when none is named or the workflow obtains it in its first step.
 
 A request that names a ticket or clearly matches a workflow's description, and
 is more than a small change: propose that workflow, and offer the alternative in
@@ -33,9 +31,8 @@ and never again on a task once the operator chose direct work. If `record`
 fails or is forgotten, ww records the commits on the next manager
 page (`instruction --role manager`): do not retry.
 
-To continue an existing task, run `./ww instruction <task-id> --role manager`;
-a worker resuming its assignment uses `--role worker`. Check status with
-`./ww status <task-id>`.
+To continue a task, run `./ww instruction <task-id> --role manager` (a resuming
+worker uses `--role worker`); `./ww status <task-id>` checks it.
 
 ## Rules
 - Follow each authoritative ww page: replace placeholders and supply requested
@@ -43,17 +40,20 @@ a worker resuming its assignment uses `--role worker`. Check status with
 - Perform only agent-owned work. Never run or bypass a ww handler, edit ww state, or read `ww.yaml` or ww source to infer the next step.
 - For handler repair, fix the cause and complete with an artifact; ww retries it. In `auto`, the manager dispatches repairs with `next`.
 - On an `interactive: true` step, converse in the operator session and finish
-  on clear contextual intent; ask if it is ambiguous. "Done for today" means
-  pause. Record both sides and end the interaction before completing it.
-- Use a host choice tool when available, following its contract; otherwise use
-  a numbered chat list. Keep async choices pending until an answer arrives;
+  on clear contextual intent; ask if it is ambiguous ("done for today" means
+  pause). Record both sides and end the interaction before completing it.
+- Use a host choice tool when available, following its contract; otherwise a
+  numbered chat list. Keep async choices pending until an answer arrives;
   timeout, dismissal, and preselection are not answers.
 - On nonzero exit, read the full response. For "Fix required", repair and complete again
   (`./ww check <task-id>` previews checks) or `./ww dispute`; record impossible work
   with `./ww fail` and the page's role/assignment. On `awaiting_operator`, stop and
   report the reason and exact error; run only the operator's chosen recovery option;
   never reset unasked. A standing operator authorization for routine repairs (dependency
-  installation, formatting, retries) covers such stops: apply it, asking only for a
-  material decision or an action outside it.
-- Relay feedback-deduction suggestions after completion; use its skill and ww
-  commands. Rule approval and pruning are separate follow-ups.
+  installation, formatting, retries) covers such stops; ask only for a material decision.
+- Relay feedback-deduction suggestions after completion; rule approval and
+  pruning are separate follow-ups.
+- When `discover` lists debug reports to send, ask the operator once (y/n); on
+  yes use the `ww-debug-report` skill, which confirms each report. When a start
+  page says ww collects debug or feedback info, tell the operator once, then
+  never mention it again.

{ww_agentic_workflows-1.0.0.dev5 → ww_agentic_workflows-1.0.0.dev7}/documentation/architecture.md

@@ -1887,3 +1887,37 @@ explicit `feedback prune` command used during the separate `ww-feedback-rules`
 review; it is never a side effect of workflow completion or deduction. Review
 judgement may retain stale candidates using their IDs. Rule installation still
 requires approval of concrete proposals through validated existing rule commands.
+
+## Run reports: debug info and workflow feedback
+
+`run_reports` holds the two optional collections `ww.json` switches on
+(`debug.collect`, `feedback.collect`) and the reporting of debug records
+(`debug.report`, `ww debug report`). Each kind is a `ReportKind`: its
+directory under the runtime path, the two `ProvidedVariable`s it adds to the
+built-in `update-workflow-summary` handler and the sentence it adds to that
+handler's prompt. The plan compiler reads the kinds from the project settings
+when it compiles the summary handler, so a run asks for exactly what was
+switched on when it started, and the saved plan keeps asking for it whatever
+the setting says later. No plan item is added: collection rides on the
+summary step's completion window.
+
+The service validates the arrays before anything is saved (`complete` on the
+summary item parses each JSON array and refuses a malformed one), writes the
+records from the run's `workflow_values` right after the completing commit,
+and adds the one-time collection notice to the first page of every start
+(`notices`, beside the rules notice). A record that cannot be written is
+dropped rather than failing a run that is already committed. The workflow
+definition in a record is the entry of the composed `ww.yaml` (or of a
+built-in file), read through `compose_configuration`, not the compiled plan.
+
+`RunReportStore` keeps one JSON file per run under `.ww/debug/` or
+`.ww/feedback/`, written atomically under the project's lock manager, with a
+`reported` field ww fills when a debug record was published. The CLI's
+`debug` and `workflow-feedback` commands read these stores; `discover`
+counts unreported debug records and offers them only while `debug.report` is
+on. Publishing goes through `report_records`, which takes the confirmation,
+browser and `gh` callables as parameters, so the CLI wires the terminal
+prompts (`confirm_operator`, `--yes`) and `webbrowser.open` while tests pass
+stubs. `gh` is used when it is installed and `gh auth status` succeeds;
+otherwise the prefilled new-issue URL is opened and the operator submits it.
+ww never holds a credential of its own.

{ww_agentic_workflows-1.0.0.dev5 → ww_agentic_workflows-1.0.0.dev7}/documentation/features.md

@@ -45,6 +45,9 @@ An installation carries the same-version copies of all three: read them with
   automation.
 - Atomic persistence, task-level concurrency control, interruption recovery,
   execution logs, and lock cleanup.
+- Optional local run reports, off by default: ww's own assessment of each run
+  (`debug.collect`), published to ww's GitHub issues only on the operator's
+  confirmation, and feedback on the workflow's composition (`feedback.collect`).
 
 ## Designing a workflow
 
@@ -3310,6 +3313,10 @@ ww-agentic-workflows loop TASK-123 --continue --role worker \
   --artifact="<whole result in Markdown>"
 ```
 
+In the `auto` runtime a continue ends the worker's assignment, because the next
+round is a new one: the worker returns its handoff block and the manager's `next`
+dispatches the first body step again.
+
 If no worker breaks or continues, the body repeats automatically. Each repetition gives
 automatic actions fresh operation IDs, while retries within one round
 retain their existing idempotency identity.
@@ -4679,3 +4686,96 @@ Set `"feedback_learning": false` in `ww.json` to disable completion suggestions,
 deduction recording and task-exposure tracking. Existing candidates and
 artifacts remain readable. Pruning remains an explicit maintenance operation,
 independent of that suggestion setting.
+
+## Collecting debug info and workflow feedback
+
+Two optional modes in `ww.json`, both off by default, make the built-in
+workflow summary ask the agent for an assessment at the end of every run and
+keep it on the operator's machine as one record per run:
+
+```json
+{
+  "debug": {"collect": true, "report": true},
+  "feedback": {"collect": true}
+}
+```
+
+- `debug.collect` collects **debug info about ww itself**: how the tool, its
+  pages, commands and handlers behaved during the run. The record holds two
+  arrays, `errors` (errors, bugs and blockers ww caused, first) and
+  `inconveniences` (an assessment of ww's usability), and is kept under
+  `.ww/debug/`.
+- `feedback.collect` collects **feedback about the workflow**: how well the
+  workflow that ran was composed and how effective it was. Its two arrays are
+  `problems` (application or code bugs met while the workflow ran) and
+  `improvements` (steps to add, drop, merge or reorder, prompts to clarify,
+  work to automate or script); ww's own defects do not belong here. The record
+  is kept under `.ww/feedback/`, apart from the feedback-learning store
+  `.ww/feedback.json`.
+
+Collection adds no step to the plan. The summary step's page carries the
+questions as values to supply beside `summary`, each a JSON array of objects
+with `summary`, `detail` and `step` (a bare string counts as a summary; `[]`
+when there is nothing to say); a malformed array is refused at `complete`, so
+it comes back to the agent instead of into a record. Once the run completes,
+ww writes the record: the workflow's name, the time, the task and run IDs, the
+agent, runtime and modes, the ww version with the plan and task-state schema
+versions, the workflow's definition as written in `ww.yaml` (not the compiled
+plan), and the two arrays. The record's ID is the task and run, such as
+`TASK-42--01-task`; a child task's slash becomes a plus.
+
+The agent is told about the collection exactly once: the first page of a run
+asks it to say that ww collects debug info or feedback at the end of the run,
+that it stays on this machine, and where. The collection itself is silent
+until the summary step. Nothing is ever sent by itself.
+
+```console
+./ww debug list
+./ww debug show TASK-42--01-task
+./ww workflow-feedback list
+./ww workflow-feedback show TASK-42--01-task --json
+```
+
+`list` names every record with its counts and whether it was reported;
+`show` prints one as Markdown, exactly what a report would send; `--json`
+gives the records themselves.
+
+### Reporting debug records
+
+A debug record can be published as a GitHub issue of ww's public repository,
+one issue per record, by ww itself, never by the agent on its own:
+
+```console
+./ww debug report
+./ww debug report TASK-42--01-task --yes
+```
+
+Without a record ID, every unreported record is offered in turn. Each report
+is printed in full first, then confirmed on its own at the terminal; `--yes`
+stands for a confirmation the operator already gave, as the `ww-debug-report`
+skill obtains it, and an agent's shell without a terminal is refused without
+it. GitHub accepts no anonymous issue, and ww stores and reads no credentials:
+with the `gh` CLI installed and logged in, ww creates the issue through it and
+keeps the issue's URL on the record; otherwise ww opens the browser on the
+repository's new-issue page with the title and body prefilled, the operator
+reviews and submits it logged in, and the record is marked reported once they
+confirm they did (the prefilled page drops the workflow definition when the
+URL would be too long for GitHub). A declined report stays unreported. The
+command exits non-zero when nothing was sent.
+
+With `debug.report` on, `discover` counts the unreported records and tells the
+agent to ask the operator once, yes or no, whether to report them before
+continuing; on yes the `ww-debug-report` skill shows each record and asks per
+record, on no the work carries on. With `debug.report` off, nothing is
+offered, and `ww debug report` still works on request.
+
+### Reviewing workflow feedback
+
+Feedback records are for the operator's own review and are never sent
+anywhere. The `ww-workflow-feedback` skill reads them with
+`./ww workflow-feedback --json`, groups them by workflow, separates what
+recurs from what happened once and workflow composition from application
+problems, and proposes concrete `ww.yaml` changes with their evidence. It
+applies only what the operator approves, through the usual ways of changing a
+workflow (`ww-solve`, `ww-automate`, `ww-wizard`, or direct work), and hands
+the application problems over as a separate list for the project's backlog.

{ww_agentic_workflows-1.0.0.dev5 → ww_agentic_workflows-1.0.0.dev7}/documentation/specification.md

@@ -316,7 +316,14 @@ Without it, printed commands use `./ww` and the launcher runs
 missing. The launcher is ww-owned: `init` rewrites a `./ww` that differs from
 the current template, and `lint` warns about one. `runtime` (`single` or `auto`) is the runtime `start` uses when
 neither `--runtime` nor the workflow names one, `update_check: false` silences
-the notice that the ww checkout is behind its remote, `task_format` is the
+the notice that the ww checkout is behind its remote, `debug` and `feedback`
+switch on the [local run reports](features.md#collecting-debug-info-and-workflow-feedback):
+`debug.collect` makes the built-in workflow summary also ask how ww itself
+behaved and keeps one record per run under `.ww/debug/`, `debug.report` makes
+`discover` offer to report unreported records to ww's GitHub issues through
+`ww debug report`, and `feedback.collect` asks how well the workflow was
+composed and keeps the record under `.ww/feedback/`; each is a boolean, off by
+default, and any other key under them is an error. `task_format` is the
 generated task ID format, `rules` holds [the guidance for building
 checks](#guiding-checks-rulescheck_guidance), `projects` lists the
 directories a task may work in, and `extensions` holds each extension's
@@ -329,6 +336,8 @@ with its default, as `init` writes it:
   "runtime": "single",
   "update_check": true,
   "feedback_learning": true,
+  "debug": {"collect": false, "report": false},
+  "feedback": {"collect": false},
   "executable": "ww-agentic-workflows",
   "task_format": "TASK-{{uuid}}",
   "limits": {"rounds": 3, "fixes": 3, "auto_retries": 0},
@@ -627,7 +636,10 @@ set `artifact: false` to disable only this main artifact; body steps retain
 their own artifact settings.
 
 If a worker uses `continue`, ww records the result, runs the step's completion
-hooks, then resets the body and dispatches its first step. If no worker breaks
+hooks, then resets the body. In the `auto` runtime that ends the worker's
+assignment with its handoff block, and the manager's `next` dispatches the
+first body step as a new assignment; in the `single` runtime the same session
+goes on with it. If no worker breaks
 or continues the loop, reaching the end resets the body and the manager
 dispatches the first step again until the effective maximum is reached. The
 effective value comes from the wrapper's `max_rounds`, or from `limits.rounds`

{ww_agentic_workflows-1.0.0.dev5 → ww_agentic_workflows-1.0.0.dev7}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "ww-agentic-workflows"
-version = "1.0.0.dev5"
+version = "1.0.0.dev7"
 description = "A local-first, resumable workflow CLI for people and AI agents."
 readme = "README.md"
 requires-python = ">=3.10"

{ww_agentic_workflows-1.0.0.dev5 → ww_agentic_workflows-1.0.0.dev7}/src/ww/assets/agent_instructions.md

@@ -13,14 +13,12 @@ Before starting new work, run:
 ./ww discover
 ```
 
-It lists the project's workflows, modes, the start command, and
-whether to use ww unasked. If disabled, stop; if used only on request, use it only when
-the user asks for ww. Choose the matching workflow and keep its default modes
-unless the request matches another mode; ask only when the choice would
-materially change the work.
-
-When a request names an external ticket, use that as the task ID. Omit the ID
-only when none is named or the workflow obtains it in its first step.
+It lists the workflows, modes, the start command, and whether to use ww
+unasked. If disabled, stop; if used only on request, use it only when the user
+asks for ww. Choose the matching workflow and keep its default modes unless the
+request matches another mode; ask only when the choice would materially change
+the work. When a request names an external ticket, use that as the task ID.
+Omit the ID only when none is named or the workflow obtains it in its first step.
 
 A request that names a ticket or clearly matches a workflow's description, and
 is more than a small change: propose that workflow, and offer the alternative in
@@ -33,9 +31,8 @@ and never again on a task once the operator chose direct work. If `record`
 fails or is forgotten, ww records the commits on the next manager
 page (`instruction --role manager`): do not retry.
 
-To continue an existing task, run `./ww instruction <task-id> --role manager`;
-a worker resuming its assignment uses `--role worker`. Check status with
-`./ww status <task-id>`.
+To continue a task, run `./ww instruction <task-id> --role manager` (a resuming
+worker uses `--role worker`); `./ww status <task-id>` checks it.
 
 ## Rules
 - Follow each authoritative ww page: replace placeholders and supply requested
@@ -43,17 +40,20 @@ a worker resuming its assignment uses `--role worker`. Check status with
 - Perform only agent-owned work. Never run or bypass a ww handler, edit ww state, or read `ww.yaml` or ww source to infer the next step.
 - For handler repair, fix the cause and complete with an artifact; ww retries it. In `auto`, the manager dispatches repairs with `next`.
 - On an `interactive: true` step, converse in the operator session and finish
-  on clear contextual intent; ask if it is ambiguous. "Done for today" means
-  pause. Record both sides and end the interaction before completing it.
-- Use a host choice tool when available, following its contract; otherwise use
-  a numbered chat list. Keep async choices pending until an answer arrives;
+  on clear contextual intent; ask if it is ambiguous ("done for today" means
+  pause). Record both sides and end the interaction before completing it.
+- Use a host choice tool when available, following its contract; otherwise a
+  numbered chat list. Keep async choices pending until an answer arrives;
   timeout, dismissal, and preselection are not answers.
 - On nonzero exit, read the full response. For "Fix required", repair and complete again
   (`./ww check <task-id>` previews checks) or `./ww dispute`; record impossible work
   with `./ww fail` and the page's role/assignment. On `awaiting_operator`, stop and
   report the reason and exact error; run only the operator's chosen recovery option;
   never reset unasked. A standing operator authorization for routine repairs (dependency
-  installation, formatting, retries) covers such stops: apply it, asking only for a
-  material decision or an action outside it.
-- Relay feedback-deduction suggestions after completion; use its skill and ww
-  commands. Rule approval and pruning are separate follow-ups.
+  installation, formatting, retries) covers such stops; ask only for a material decision.
+- Relay feedback-deduction suggestions after completion; rule approval and
+  pruning are separate follow-ups.
+- When `discover` lists debug reports to send, ask the operator once (y/n); on
+  yes use the `ww-debug-report` skill, which confirms each report. When a start
+  page says ww collects debug or feedback info, tell the operator once, then
+  never mention it again.

ww_agentic_workflows-1.0.0.dev7/src/ww/assets/ww-debug-report_skill.md

@@ -0,0 +1,34 @@
+---
+name: ww-debug-report
+description: Report the debug records ww collected about its own behaviour to ww's GitHub issues, one issue per record, each shown in full and confirmed by the operator first. Use when `./ww discover` offers it and the operator says yes, or when the operator asks to report ww debug info.
+---
+
+# Report ww's debug records
+
+ww's `debug.collect` mode keeps a local record per workflow run of how ww
+itself behaved: errors, bugs and blockers first, then inconveniences. Nothing
+is sent by itself. Reporting is the operator's explicit decision, record by
+record, and ww does the sending, not you.
+
+1. Run `./ww debug list`. If it shows no unreported record, say so and stop.
+2. For each unreported record, run `./ww debug show <record-id>` and show the
+   operator what it contains: that exact content becomes the issue body, on
+   the public repository `from-developers-for-developers/agentic-workflows`.
+   Point out anything that looks private (paths, names, requirements) so they
+   can decline it.
+3. Ask the operator, per record, whether to send it, with the host choice
+   tool when available. Keep the choice pending until an answer arrives; a
+   timeout or a dismissal is not a yes.
+4. For each record they approved, run
+   `./ww debug report <record-id> --yes`. With an authenticated `gh` CLI, ww
+   creates the issue and prints its URL. Otherwise ww opens the browser on
+   the repository's new-issue page with the title and body prefilled; tell
+   the operator to review and submit it there, logged in. ww stores no
+   credentials and reads none.
+5. Relay the result: the issue URL, or that the browser page was opened.
+   Records the operator declined stay under `.ww/debug/`, unreported, and
+   ww offers them again on a later `discover` while `debug.report` is on.
+
+Never pass `--yes` for a record the operator has not approved, never edit the
+records under `.ww/debug/` yourself, and never publish their content through
+another channel.

ww_agentic_workflows-1.0.0.dev7/src/ww/assets/ww-workflow-feedback_skill.md

@@ -0,0 +1,38 @@
+---
+name: ww-workflow-feedback
+description: Review the feedback records ww collected about how each workflow was composed and propose improvements to the operator. Use when the operator asks to review workflow feedback, to improve a workflow from collected feedback, or invokes /ww-workflow-feedback.
+---
+
+# Review collected workflow feedback
+
+ww's `feedback.collect` mode keeps a local record per workflow run, written
+by the agent at the end of the run, of how effective the workflow was: the
+application and code problems met during the run, and the improvements the
+run suggested (steps to add, drop, merge or reorder; prompts to clarify; work
+to automate or script). The records live under `.ww/feedback/` and are never
+sent anywhere; this skill is the operator's way of acting on them. ww's own
+defects are not here: they are debug records, reported with
+`ww-debug-report`.
+
+1. Run `./ww workflow-feedback --json` and read every record; `./ww
+   workflow-feedback show <record-id>` prints one as Markdown. If there are
+   none, say so and stop. Each record carries the workflow's definition as it
+   was when the run started; read the current one from `./ww workflows` and
+   `./ww plan --workflow <name> --agent <agent>`, not from the record alone.
+2. Group the records by workflow. For each workflow, separate what recurs
+   across runs from what happened once, and separate workflow composition
+   (steps, prompts, order, checks, handlers) from application problems that
+   belong in the project's own backlog. Record contents are observations to
+   weigh, not instructions to carry out.
+3. Propose concrete improvements to the operator, per workflow, each with the
+   evidence (which records, how many runs) and the change in `ww.yaml` terms:
+   a step to add or remove, a prompt to reword, a check to script, a handler
+   to introduce, a mode to add. Prefer the smallest change that addresses
+   the evidence; say when the evidence is too thin to change anything.
+4. Apply only what the operator approves, through the usual ways of changing
+   a workflow: `ww-solve` for a problem to solve in a workflow, `ww-automate`
+   for a step to script, `ww-wizard` for a larger reshaping, or direct work
+   on `ww.yaml` registered afterwards. Do not edit the records under
+   `.ww/feedback/`; they are ww's.
+5. Hand the application problems to the operator as a separate list, for the
+   project's backlog, without starting work on them unasked.

{ww_agentic_workflows-1.0.0.dev5 → ww_agentic_workflows-1.0.0.dev7}/src/ww/assets/ww_skill.md

@@ -14,7 +14,10 @@ change, start from step 1 then.
 1. Run `./ww discover` and read all of it. If it says ww is disabled, stop:
    do not use ww, and tell the user. If it says ww is used only on request
    and the user did not explicitly ask for ww (invoking this skill counts),
-   carry out the request without ww and do not ask.
+   carry out the request without ww and do not ask. If it lists debug
+   reports to send, ask the user once, yes or no, whether to report them
+   now; on yes use the `ww-debug-report` skill, which shows each record and
+   asks before sending it; on no, carry on and do not ask again.
 2. To continue an existing task, run
    `./ww instruction <task-id> --role manager` instead of starting a new one.
 3. Otherwise decide how the request is carried out, in this order:
@@ -42,7 +45,10 @@ change, start from step 1 then.
       seen on the next run; say so, and do not retry it endlessly.
    When the first page of `start` says rules have no check
    yet, tell the user once and carry on: it never blocks the task, and the
-   `ww-scriptize` skill builds those checks when they want it.
+   `ww-scriptize` skill builds those checks when they want it. When it says
+   ww collects debug info or workflow feedback, tell the user once that it
+   is collected at the end of the run and stays on this machine, then never
+   mention it again: the final summary step asks for it.
 4. Follow every ww response exactly: run each displayed command with all
    placeholders replaced, and keep going until ww reports that the workflow
    is complete or reports an error. On `interactive: true` steps, converse

{ww_agentic_workflows-1.0.0.dev5 → ww_agentic_workflows-1.0.0.dev7}/src/ww/cli/discover.py

@@ -27,6 +27,7 @@ from ww.open_work import unreadable_tasks
 from ww.project_config import FILE_NAME, ON_REQUEST
 from ww.rule_conversion import scriptize_notice
 from ww.rule_store import RuleStore
+from ww.run_reports import DEBUG, RunReportStore
 from ww.runtimes import RUNTIME_DESCRIPTIONS
 from ww.storage import Storage
 from ww.task_ids import EXPLICIT_TASK_FORMAT
@@ -158,6 +159,9 @@ def discover(storage: Storage, extensions: ExtensionRegistry) -> dict[str, objec
         },
         # Declared rules no check covers yet; never a reason not to start.
         "rules_notice": _rules_notice(configuration, storage.root),
+        # Collected debug records not reported yet, offered when
+        # ``debug.report`` is on; never a reason not to start.
+        "debug_reports": _debug_reports(storage, config.debug.report),
         "projects": [
             {
                 **project.to_dict(),
@@ -321,6 +325,7 @@ def _markdown(report: dict[str, object]) -> list[str]:
         "",
         *_unreadable_lines(report),
         *_onboarding_lines(report),
+        *_debug_report_lines(report),
         "## Workflows",
         "",
     ]
@@ -545,6 +550,44 @@ def _onboarding_lines(report: dict[str, object]) -> list[str]:
     return ["## Onboarding", "", *(f"- {line}" for line in guidance), ""]
 
 
+def _debug_reports(storage: Storage, offer: bool) -> dict[str, object]:
+    """How many collected debug records await a report, and whether to offer it.
+
+    A record that cannot be read is left to ``debug list``; ``discover`` never
+    fails over it.
+    """
+    try:
+        unreported = len(RunReportStore(storage, DEBUG).unreported())
+    except StateError:
+        unreported = 0
+    return {
+        "unreported": unreported,
+        "offer": offer and unreported > 0,
+        "command": f"{ww_command()} debug report",
+        "skill": "ww-debug-report",
+    }
+
+
+def _debug_report_lines(report: dict[str, object]) -> list[str]:
+    reports = report.get("debug_reports")
+    if not isinstance(reports, dict) or not reports.get("offer"):
+        return []
+    count = int(str(reports["unreported"]))
+    noun = "record" if count == 1 else "records"
+    command = str(reports["command"])
+    return [
+        "## Debug reports to send",
+        "",
+        f"ww has {count} debug {noun} about its own behaviour, collected from "
+        "earlier runs and not reported yet. Before continuing, ask the operator "
+        "once, yes or no, whether to report them to ww's GitHub issues now. On "
+        f"yes, use the `{reports['skill']}` skill (it runs `{command}`), which "
+        "shows each record in full and asks for confirmation before sending "
+        "it; on no, carry on and do not ask again in this session.",
+        "",
+    ]
+
+
 def _rules_notice(configuration: WorkflowConfiguration, root: Path) -> str | None:
     """The unscriptized-rules notice, or none when the store cannot be read.