feat(feedback): add context anchoring instructions to plan denial

[aviadshiber]

Summary

Implements the context anchoring pattern from Martin Fowler's article on context anchoring, applied to both the plan denial and approval flows.

The problem: when an agent gets a plan denied and revises, it only receives the current round's feedback — not what was rejected in prior rounds. It can re-propose the same approaches without knowing they were already rejected, creating iteration loops. And on approval, nothing reminds the agent to carry forward the decision history into implementation.

Changes

packages/shared/feedback-templates.ts

planDenyFeedback() — adds a ## Context Anchoring section instructing the agent to maintain a ## Decisions Log in the plan itself:

## Context Anchoring

Before revising your plan:
1. Add (or update) a `## Decisions Log` section at the bottom of the plan.
2. For each rejected approach from this feedback, add an entry:
   - **Rejected:** [brief description]  **Why:** [reason from this feedback]
3. Do NOT re-propose approaches already listed in the Decisions Log — it is your cross-session memory.

planApproveFeedback() — new function used on plan approval, reminding the agent to reference the Decisions Log during implementation:

Plan approved!

If your plan contains a `## Decisions Log`, keep it as a reference during
implementation — it documents the rejected alternatives that shaped this design.

apps/opencode-plugin/index.ts

Uses planApproveFeedback() for both approval paths (with notes and without), replacing the previous inline strings.

packages/shared/feedback-templates.test.ts

Adds 4 tests covering the context anchoring behavior (all passing):

• Deny includes Decisions Log instructions, Rejected: entry format, and cross-session memory note
• Approve includes Decisions Log reminder
• Approve with notes includes both implementation notes and Decisions Log reminder
• Approve with saved path surfaces the file path

Why this approach

The plan is already the persistent artifact (saved to version history on every submission). By embedding rejected alternatives and their reasoning directly in the plan markdown, the ADR pattern works at zero infrastructure cost. The Decisions Log:

• Travels with every revision
• Is visible in the plan diff view (shows what was added/changed between iterations)
• Is archived with the final approved/denied decision
• Survives context window resets — it's in the document, not just the conversation

Test plan

• Deny → agent instructed to build ## Decisions Log with rejected approaches
• Deny again → Decisions Log grows ("add or update" instruction)
• Approve → agent reminded to reference Decisions Log during implementation
• Approve with notes → notes + Decisions Log reminder both appear

Part of #431

🤖 Generated with Claude Code

[backnotprop]

Hey @aviadshiber , thanks for this PR and sorry for taking so long to get back to you. The context anchoring idea is great.

We ended up going a different direction with the implementation though. Instead of hardcoding the context anchoring into the denial template, we built a configurable feedback pipeline that lets users customize all plan/annotation/review messages via ~/.plannotator/config.json with {{variable}} templates. Your context anchoring pattern is now a first-class config example in the docs rather than a default for everyone.

The new docs page walks through how to set it up: users drop your exact denial + approval templates into their config and they're done. You're credited by name with a link to your GitHub profile as the contributor behind the example.

We're going to close this PR, but you will get co-author credit on the commit that ships the feedback pipeline. Thanks again for the contribution, it directly shaped how we documented and designed the customization system.