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

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

@@ -9,6 +9,14 @@ 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

{ww_agentic_workflows-1.0.0.dev6 → 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.dev6
+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.dev6 → 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.dev6 → 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.dev6 → 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.dev6 → 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
 
@@ -4683,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.dev6 → 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},

{ww_agentic_workflows-1.0.0.dev6 → 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.dev6"
+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.dev6 → 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.dev6 → 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.dev6 → 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.