# 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.deliver` came:
  offer `map_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.