bvandeusenandClaude Opus 5.5
4e1320120d
The open-after-moment signal proposes a mount; nothing proposed taking one off, so a wrong mount was noise at every occurrence until someone happened to notice. rule_misfired(rule_id, moment, why, reached_by) records a report against a MOUNTED pair, counted per distinct day (the MCP door carries no session id) on a new rule_moment_judgments.misfire column (migration 0119, backup v24). At three days the response carries a line asking the agent to offer the operator the fix - reject takes the rule off, unmap_action stops the action reaching the moment, confirm keeps the mount and stops the asking - and Settings > Moments lists it as an unmount proposal with the reasons and the actions that reached it. A re-mount clears the count. Taught in moments.md, missed-retrieval.md and the reply hold's wording. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
4.6 KiB
Moments — rules that arrive when the work reaches a point
Part of the using-scribe skill. Read it when a line says a rule arrived at a moment, when a reply is held for one read, when an action reached the wrong moment or none, when a mounted rule arrived and did not apply, and when a line proposes mounting or unmounting a rule.
What a moment is
Most rules reach you by resemblance: what you are doing looks like what the
rule is about. A rule about WHEN — finishing, delivering, verifying,
reporting — resembles nothing said at that point, so resemblance misses it.
Such a rule is mounted on the moments of work it belongs to, and arrives
by lookup whenever an action reaches one. list_moments names them, each
with what is happening at it and the kinds of action that typically reach it:
work.deliver when work is sent beyond the place it was made, work.finish
when a piece of work is declared done, reply.report at the reply that ends a
turn, and so on. A named procedure is its own moment, skill.<name>, reached when it is
loaded.
Which ACTIONS reach a moment is the install's: one operator delivers with a push, another with a deploy script. Shipped defaults cover the common ones, and each install corrects them for itself.
Reading a line that arrived at a moment
The line names the moment and the action that reached it — "at work.deliver,
reached by git push" — and the rule, with get_rule(N) to read it. Read it
as you would any rule that arrived beside your work: it binds just as hard,
and it came because of what you are doing now, not because of what you said.
The reply that ends a turn is a moment too. When a rule mounted at
reply.report has not been opened this session, the reply may be held once
with its name: open it, then send the reply — unchanged, if it already does
what the rule asks. The same rule is never held twice.
When the moment is wrong — correct it in the session
A moment can fire on an action that is not that moment here, or an action can plainly be a moment and fire nothing. Either way the fix is one call, and it belongs in the session that noticed, not on a settings page:
- An action reached the wrong moment — the line names a moment that is not
what you did: offer
unmap_action(tool, moment, match, reason). - An action was a moment and nothing arrived — the operator ships with
their own script, and nothing mounted on
work.delivercame: offermap_action(tool, moment, match, reason).
Offer it in one line, the way the operator would say it ("that deploy script
is a deliver and nothing fired — map it?"), and make it on their yes. The
correction lasts for every later session on the install; list_moments shows
what each action reaches now.
When a mounted rule arrives and does not apply
A mount delivers its rule at every occurrence of the moment, so a mount that
is wrong is noise every time — and a rule you read and set aside leaves no
trace anyone else can see. When a rule arrived at a moment, you read it,
and it has nothing to do with what you were doing there, say so with
rule_misfired(rule_id, moment, why, reached_by): one call, nothing asked of
the operator. Name the action the line said reached the moment, and say what
you were doing, because the reports are what the operator decides from —
whether the rule does not belong at the moment, or one action is reaching it
that is not that moment here.
Reports gather across days. Once a rule has them on three, the response
carries a line asking you to offer the fix, and the operator sees it under
Settings › Moments too: judge_rule_moments reject takes the rule off,
unmap_action stops the action reaching the moment, and confirm keeps the
mount and ends the question. A rule that applied — even one you were already
following — is not a misfire, and a rule that arrived by its words rather
than a mount is fixed through its trigger instead.
When a line proposes a mount
A rule that keeps being opened just after the same moment, across several
sessions, probably belongs on that moment. A line says so, naming the rule,
the moment and how often. It is a question for the operator, not a change you
make: offer it in one line, and record their answer with
judge_rule_moments — confirm mounts the rule, reject with their reason
stops the question being asked again.
The same tool answers proposals from a pass over the rules
(rules_to_mount, propose_rule_moments, rule_moment_proposals): a pass
proposes, and only the operator's yes mounts. Writing a NEW rule is different
— its moments are part of writing it, and the
skill's guide to writing records says how.