feat(lessons): a lesson is yours to keep current too (#4195)
CI & Build / Python lint (push) Successful in 4s
CI & Build / Plugin hooks (push) Successful in 12s
CI & Build / integration (push) Successful in 52s
CI & Build / TypeScript typecheck (push) Successful in 55s
CI & Build / Python tests (push) Successful in 1m49s
CI & Build / Build & push image (push) Successful in 29s
CI & Build / Python lint (push) Successful in 4s
CI & Build / Plugin hooks (push) Successful in 12s
CI & Build / integration (push) Successful in 52s
CI & Build / TypeScript typecheck (push) Successful in 55s
CI & Build / Python tests (push) Successful in 1m49s
CI & Build / Build & push image (push) Successful in 29s
The lesson kind shipped with every mechanism for growing and nothing telling a session to use them. `learned_from` is a list on purpose, the dedup gate hands back an existing id rather than minting a twin, and `update_lesson` already names re-keying a bad trigger as the edit that pays most. None of that was reachable as a habit. The exclusivity claim was the bug. The skill said "a preference is the one record you keep current yourself", and by naming only preferences it put lessons outside the habit. That sentence is now "a preference is yours to keep current", which says the same thing about preferences without saying anything false about lessons. Beside it, a paragraph on what growing a lesson means: another incident added to what taught it, a claim stated more exactly, or a trigger re-keyed to the situation that really fired. Written as a practice rather than a prohibition (rule 165) — the reader is named as the one person placed to judge the trigger, because they are standing in the situation it claims to name. `get_lesson` carries the same prompt at the moment it bites: a session reading a lesson inside the situation it names is the only reader who can tell whether the trigger is keyed to what actually fired. The guidance-ownership registry gains the topic and re-points the preference topic's statement, since the phrase it pinned is the sentence this change rewrites — the module asks for exactly that, in the same commit. No index marker: the index names session-start reflexes and this one fires mid-work, so `_INSTRUCTIONS` stays at 1998/2000. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy
This commit is contained in:
@@ -110,15 +110,27 @@ Two constraints on *how* that's achieved:
|
||||
silently, because it sometimes answers that what you are holding was never
|
||||
a rule — and routing an observation is not losing it.
|
||||
|
||||
**A preference is the one record you keep current yourself.** When the
|
||||
operator corrects you, or the preference on file no longer matches how they
|
||||
actually want something done, `update_preference` — that is expected, not a
|
||||
liberty, and updating one mid-work is the normal case rather than an
|
||||
interruption of it. It wants the task or note that taught the change. Say in the
|
||||
same turn that you did it, so they can disagree while it is in front of
|
||||
them. A rule waits for the operator instead: `create_rule` proposes and
|
||||
asks. If what you learned is that something MUST be done a certain way,
|
||||
that is a rule to propose, not a preference to harden in place.
|
||||
**A preference is yours to keep current.** When the operator corrects you,
|
||||
or the preference on file no longer matches how they actually want
|
||||
something done, `update_preference` — that is expected, not a liberty, and
|
||||
updating one mid-work is the normal case rather than an interruption of it.
|
||||
It wants the task or note that taught the change. Say in the same turn that
|
||||
you did it, so they can disagree while it is in front of them. A rule waits
|
||||
for the operator instead: `create_rule` proposes and asks. If what you
|
||||
learned is that something MUST be done a certain way, that is a rule to
|
||||
propose, not a preference to harden in place.
|
||||
|
||||
**A lesson grows each time it proves itself.** When one arrives and the
|
||||
situation it names is the one you are actually in, you are the single
|
||||
reader placed to tell whether its trigger is keyed right and whether its
|
||||
claim covers what you are seeing. `update_lesson` takes what you now know:
|
||||
another incident added to what taught it, the claim stated more exactly,
|
||||
or — the edit worth most — a trigger re-keyed to the situation that really
|
||||
fired. A lesson nobody reaches is seldom wrong; far more often it is
|
||||
waiting in a situation nobody is in. One claim that has met the same
|
||||
failure four times is worth more than four claims that each met it once,
|
||||
so when a near-duplicate create hands back an existing id, that is the
|
||||
record to grow.
|
||||
|
||||
**Preferences shape how work is done, never what gets recorded.** They
|
||||
govern your conduct — how you report, how carefully you pace, which form
|
||||
|
||||
Reference in New Issue
Block a user