/feedback

Turn a correction into reusable context without rewriting what the user actually said or widening its authority.

1. Preserve the exact prompt, source/session, affected task/artifact, relevant surrounding context and resulting evidence. If the prompt contains a credential or never-copy material, do not copy it into another model/cloud record; keep the source locally under its existing boundary and record only an allowed redacted pointer.
2. Identify the observable correction and extract one specific lesson. Separate preference, project fact, temporary exception and delivery authorization. “Keep this crop tighter” is not permission to replace the person's image everywhere or a general identity fact.
3. Choose applicability and scope: this artifact/task, workspace/project, or an explicitly approved personal preference. Do not let unrelated workspaces inherit project feedback. State confidence and the evidence supporting the lesson rather than inferring it from an emotional tone.
4. Create FDK with the exact feedback as body, context/evidence relationships and candidate lesson/scope/risk in data. FDK bodies are immutable after creation; a follow-up becomes another FDK. Use the capture and lesson template.
5. Read the returned status. The current runtime only auto-applies bounded recognized low-risk preferences. Unknown, sensitive, identity/employer/security/authority/rule changes, never-copy content and agent-created personal scope remain proposed or require owner approval. Do not set applied through a generic update to bypass rejection.
6. If explicit application is appropriate, use feedback.apply with the current revision and lesson. A rejection is a review boundary. The standalone writer preserves proposals but does not apply learning automatically. Private zen-code profile edits still use that profile's own inbox/log governance; do not directly rewrite its private references from a public skill.
7. Link superseded lessons and preserve evidence/history and rollback. Confirm application by reading the resulting record, then retrieve it on the next relevant task and show its reference as an influence. Do not claim learning propagated merely because it was captured.

Use tools.md for actual payloads and records.md for visibility. Without a writer, deliver the exact feedback and proposed lesson as a labelled unsaved draft, not a fictional FDK ref.

Example: “Use flat dashboard cards in this workspace” can be a scoped design preference. “Always skip approval and push” changes authority and must not become automatic instruction. A legitimate exception names its scope and duration instead of erasing the standing rule.