Progress Feedback

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

A dependency scan takes minutes while users cannot see tool internals. Teaching records show 12 manifests discovered, 10 checked and two unreadable. Report actual progress/coverage rather than making partial work look complete.

Mechanism

Announce objective and expected evidence before work. At meaningful findings/status changes report observed counts, gaps and next checks. Deliver visible final complete/partial/blocked status with revision/evidence references. Progress is not a pass; keep narration concise rather than listing every internal action.

Bad example

Run the scan silently and finish with 'Dependency checks complete', omitting two unreadable manifests and scope.

Good example

State scan objective/revision, then 12 discovered manifests. Report 10 checked and two unreadable with gaps/next reads, without invented completion times. Finish as partial, naming covered scope, failed files and evidence. Use complete only after full agreed coverage/checks. Deliver the result in the user-visible final response.

Why the change matters

Invisible tool work plus a completion word hides coverage distinctions. Separate observations and terminal status let users assess progress and whether gaps affect use.

Observable expectation

The teaching final state is partial: 10/12 inspected, two unread, not all 12 passed. Check agreement between updates/final counts and actual records.

A ledger-only result, omitted unchecked areas or invented timing fails.

Limits

Choose cadence under task/channel expectations without narrating every action. The source demonstrates announcing workflow/purpose; counts and terminal fields are teaching conventions. Partial reporting does not establish unseen correctness or user acceptance.