docs(plugin): the instruction surfaces teach moments - reading a line that arrived at one, correcting a misfire, and giving a new rule its moments (milestone 458 step 8, #4926)
CI & Build / Python lint (push) Successful in 13s
CI & Build / Plugin hooks (push) Successful in 16s
CI & Build / TypeScript typecheck (push) Successful in 56s
CI & Build / integration (push) Successful in 1m38s
CI & Build / Python tests (push) Failing after 1m59s
CI & Build / Build & push image (push) Skipped
CI & Build / Python lint (push) Successful in 13s
CI & Build / Plugin hooks (push) Successful in 16s
CI & Build / TypeScript typecheck (push) Successful in 56s
CI & Build / integration (push) Successful in 1m38s
CI & Build / Python tests (push) Failing after 1m59s
CI & Build / Build & push image (push) Skipped
Until now only the tool arguments knew moments existed. The guidance surfaces described rules as reached by resemblance alone: - using-scribe: a short reflex paragraph and a new reference file, moments.md. It covers reading "at <moment>, reached by <action>", the reply held once at reply.report, map_action / unmap_action offered in one line, and the step 7 proposal line answered with judge_rule_moments. - writing-records: asks WHEN a rule applies as well as what it is about. A rule, preference or process about a point in the work gets moments=[...] as it is written, and the trigger stays as the net. - missed-retrieval: a missed WHEN is mounted or mapped, not reworded. A misfire is unmounted or unmapped. - _INSTRUCTIONS: one clause (list_moments; mount rules about WHEN), 1594 of 1600 chars. - static context: injected lines include the rules mounted on a moment that was reached. - test_guidance_ownership: three owned topics, so the text cannot quietly drop out. Plugin minted. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
@@ -11,6 +11,21 @@ does **either noticer**: the operator saying *"that should have fired"*, and you
|
||||
noticing it yourself — you reached for a rule nobody offered you, or you were
|
||||
handed the same rule five times and set it aside five times.
|
||||
|
||||
**First ask whether it missed a WHEN or a WHAT.** A rule about a point in the
|
||||
work — it governs delivering, finishing, verifying, reporting, whatever the
|
||||
work is about — is not a trigger to reword: no wording resembles every piece
|
||||
of work that reaches that point. Mount it on the moment instead
|
||||
(`update_rule(moments=[...])`, from `list_moments`); a mount is a lookup, and
|
||||
it arrives every time the moment happens. When it is already mounted and still
|
||||
did not arrive, the action did not reach the moment on this install — offer
|
||||
`map_action` for that action. The reverse — a mounted rule arriving where it
|
||||
does not apply — is a mount or a mapping that is wrong: take the moment off
|
||||
the rule, or `unmap_action` the action that reached it. Each of these
|
||||
changes what the operator's sessions receive, so offer it in one line and make
|
||||
it on their yes. [moments.md](moments.md) has the
|
||||
detail. A rule about a subject missed its WHAT, and the rest of this page is
|
||||
for that.
|
||||
|
||||
**Take it to the record first and the dial second.** A rule's `when_to_apply`
|
||||
IS the text its similarity score is computed against, so when a rule misses a
|
||||
moment it governs, the overwhelmingly likely cause is that its trigger does not
|
||||
|
||||
Reference in New Issue
Block a user