Record session-environment lessons and separate review axes

CHANGELOG.md

@@ -2,6 +2,8 @@
 
 ## Unreleased
 
+- Learn from the session or its log about navigation, wasteful tool use, and steering instructions that do not change behavior. Mechanical lessons become checks; judgment lessons become standards the reviewer applies, so implementation context stays lean. Review keeps plan or spec deviation separate from repository standards or simplicity.
+
 ## 7.7.0
 
 - When a planning assignment is vague or underspecified, allow an optional short decision round with a recommendation. Clear assignments still need no interview. Raise the plan-and-readiness context limit to hold that instruction.

docs/behavior-validation.md

@@ -95,6 +95,7 @@ For each example ask: What is the result? What does it mean for the goal? What f
 | Native implementation has only the approved plan and assignment. | The plan carries reporting expectations and the host's review invocation. The executor reports actual checks and recommends a separately commissioned Review, without claiming it passed. | [Planning](../skills/plan-work/SKILL.md), [implementation handoff](manual-workflow.md#plan-and-implementation), built host instructions |
 | Planning is asked to address a repeated correction, and both a structural change and a CI check could work. | Apply the learning guidance to choose the smallest sufficiently effective measure proportionate to the assignment. Prefer structural prevention among comparably proportionate options. Ask before a consequential design change; technical feasibility alone does not justify widening the plan. | [Planning](../skills/plan-work/SKILL.md), [learning guidance](../references/learning-work.md) |
 | A required check failed, although other checks passed. | State the failed behavior, consequence, and named correction. Recommend the host's correction invocation without starting it or claiming completion. | [Review](../skills/review-work/SKILL.md), CSV export example |
+| The change matches the plan but breaks a repository convention, or it follows local conventions while missing specified behavior. | Report the axes separately: deviation from the plan or spec, and violation of repository standards or simplicity. A pass on one axis leaves the other intact. When simplicity is in question and the Efficiency plugin is already available, apply its design and code simplicity guidance in this same review. | [Review](../skills/review-work/SKILL.md) |
 | A required result is missing but an authorized local test route exists. | Explain the gap and a verification-only correction the human can commission; do not demand a human attestation or invent a code fix. | [Review](../skills/review-work/SKILL.md), settings example |
 | Actual earlier output covers the requirement and the relevant source, dependencies, configuration, and environment are unchanged. | Inspect provenance, output, coverage, and current applicability; explain the reuse basis without automatically rerunning the check. Still assess every success criterion. | [Review](../skills/review-work/SKILL.md), settings example |
 | Earlier passing output is followed by a relevant source, dependency, configuration, or environment change. | Recheck affected proof or report the current evidence gap; widen checks when the change or uncertainty warrants it. A success summary alone never proves applicability. | [Review](../skills/review-work/SKILL.md), [correction](../skills/correct-work/SKILL.md) |
@@ -135,6 +136,8 @@ Use these scenarios for an instruction-level walkthrough of the [working agreeme
 | Existing guidance already addresses a recurring mistake, and an affordable CI check can detect it. | Recommend the check instead of adding the same guidance again. Keep implementation pending if the check falls outside the commissioned scope. |
 | The selected preventive repair is outside the current assignment. | Preserve it as a concrete future assignment with evidence, benefit, destination, expected outcome, and checks. Learning does not implement product, tool, or verifier repairs. |
 | Technical prevention is disproportionate, but Review confirms a useful bounded project instruction and learning is commissioned. | Save the supported guidance under the learning rules. A merely feasible technical alternative does not block an appropriate guidance update. |
+| The session or its log shows a long search for an existing file, repeated expensive tool calls, or a steering instruction that changed nothing. | Record an environment lesson. Prefer a navigation pointer, a cheaper tool path, or removal of the dead instruction, using the existing prevention order. A one-off observation stays a candidate, not a permanent rule. |
+| A repeated mistake is a fixed pattern a check can catch. Another is a judgment about consistency that no check can replace. | Turn the mechanical lesson into a check. Turn the judgment lesson into a standard the reviewer applies, and leave that standard out of implementation context. A dedicated standards file stays optional. |
 
 ## Engineering playbook decisions
 

docs/manual-workflow.md

@@ -60,7 +60,7 @@ A successful implementation report is the input to review. It does not mean revi
 
 Review checks the result without changing repository files. It can use still-applicable evidence after checking its origin, output, and relevance; changed or uncertain evidence needs a fresh check. It must cover the whole plan, not just the tests that happened to pass. Test output may only be created outside the repository, and checks that cannot run within those limits remain visible gaps.
 
-The result tells you whether the goal is achieved, corrections are needed, or proof is missing. A finding explains the observed problem, why it matters, what should change, and how to check the fix.
+The result tells you whether the goal is achieved, corrections are needed, or proof is missing. A finding explains the observed problem, why it matters, what should change, and how to check the fix. Keep a miss against the plan or spec separate from a break with repository standards or simplicity, so one does not hide the other.
 
 ### 4. Correct findings, then review again
 
@@ -87,7 +87,7 @@ For an Auto-Work handoff, also preserve the mode, correction budget already used
 
 ## Learning across reviews
 
-Review can offer to save useful project knowledge, such as the verified download helper for CSV exports. Saving remains your choice. If the same correction has already come back, a structural change or a CI check is preferred over another guidance paragraph when it is sufficiently effective and proportionate to the assignment. See [how learning works](project-improvement.md#save-project-knowledge).
+Review can offer to save useful project knowledge, such as the verified download helper for CSV exports. Saving remains your choice. If the same correction has already come back, a structural change or a CI check is preferred over another guidance paragraph when it is sufficiently effective and proportionate to the assignment. A session can also show a navigation failure, wasteful tool use, or a steering instruction that does not change behavior. See [how learning works](project-improvement.md#save-project-knowledge).
 
 ## Supporting work
 

docs/methodology-sources.md

@@ -43,6 +43,12 @@ An optional short decision round for a vague or underspecified assignment is the
 
 Workflow does not add a grill-me or grill-with-docs skill, a required glossary, a product-design interview, or a mandatory interview before planning or Auto-Work. Product-design judgment stays with the Design plugin when that plugin is in use. Material security or auth effects stay on plan-work's existing second-order line. Change sketches stay with Efficiency's change-communication. Packaged instructions remain original Workflow wording. This note attributes the idea; it does not load an upstream skill.
 
+## Agent environment and two-axis review
+
+Session-environment lessons and the split between plan or spec deviation and repository standards or simplicity are adapted from Matt Pocock's [retro](https://github.com/mattpocock/skills/blob/24fe0ef7737efae15c87225755e9f6f5965e4888/skills/engineering/retro/SKILL.md) and [code-review](https://github.com/mattpocock/skills/blob/24fe0ef7737efae15c87225755e9f6f5965e4888/skills/engineering/code-review/SKILL.md) skills in `mattpocock/skills` v1.3.1, commit `24fe0ef7737efae15c87225755e9f6f5965e4888`, announced at <https://x.com/mattpocockuk/status/2107062474914550098>. Workflow keeps the existing correction ladder in the [learning guidance](../references/learning-work.md). It adds the session or log as a source for environment lessons: navigation, tool economy, and steering instructions that do not change behavior. Mechanical lessons become checks. Judgment lessons become standards the reviewer applies, so implementation context stays lean. Review reports both axes in the same read-only pass. When simplicity is in question and the Efficiency plugin is already available, that pass may use its design and code simplicity guidance, inspected in `geldmacher/efficiency` at `e8d81d02af5071484383896e1ab1cf4a585f267d`.
+
+Automated checks were already on the ladder. This adaptation does not add a `/retro` command, a required `CODING_STANDARDS.md`, parallel review subagents, or the Fowler smell baseline. It does not adopt `/implement-spec`, which conflicts with Auto-Work, the written plan handoff, and host-configured models. Grill-me, grill-with-docs, and a required glossary stay out, as [Vague-scope planning](#vague-scope-planning) already records. Packaged instructions remain original Workflow wording. This note attributes the ideas; it does not load the upstream skills.
+
 ## Shared integration decisions
 
 Each method remains one reference file. Catalog and skill entrypoints load only the selected method. The playbooks describe useful result content, not mandatory user-document headings, metadata, or machine state.

docs/project-improvement.md

@@ -70,7 +70,7 @@ A subagent role is optional, narrowly scoped and tested through actual discovery
 
 During implementation and correction, Workflow records useful discoveries as **learning candidates**: proposed lessons with evidence, a future benefit, where they apply, and where they could be saved. Collection happens as part of the work; it does not silently change project instructions.
 
-When a correction recurs despite a fix or existing guidance, follow the [learning guidance](../references/learning-work.md) to choose prevention proportionate to the task. A structural change or CI check can be more useful than another guidance paragraph, but technical feasibility alone does not justify a large change. A first finding can also justify proportionate prevention within its assignment. Learning saves supported, bounded guidance only when requested and appropriate; larger repairs remain future assignments.
+When a correction recurs despite a fix or existing guidance, follow the [learning guidance](../references/learning-work.md) to choose prevention proportionate to the task. A structural change or CI check can be more useful than another guidance paragraph, but technical feasibility alone does not justify a large change. A first finding can also justify proportionate prevention within its assignment. The session or its log can also show where the agent could not find something, wasted tool calls, or followed an instruction that changed nothing. Mechanical lessons become checks. Judgment lessons become standards the reviewer applies. Learning saves supported, bounded guidance only when requested and appropriate; larger repairs remain future assignments.
 
 Every review checks earlier and new candidates against the current work. If any lessons are confirmed and useful, it offers `learn-from-work`. A lesson can be sound even when an unrelated code correction remains; the learning offer does not change the review judgment. If there is nothing useful to save, there is no offer.