alignmentApprovalNotice
alignmentApprovalNotice(
options):string
Defined in: packages/core/src/core/shell/alignment.ts:932
What the human is told when an alignment check is the reason a command ran without them.
At auto a destructive command used to reach a person or the agent, always. An aligned
approval is new authority, so the event has to be visible: an event the user never sees reads as
the agent quietly deciding things on their behalf ([[EXT-106]] §4.6, arguing the same point for
the carve-out’s own notice). That applies with MORE force here than to the rarer floored arm,
because this is the common one.
One renderer for all three arms, deliberately. A plain destructive lifted by the checker,
§4.6’s open-world floor lifted by the checker, and a §4.6-CARVED command lifted by the checker are
the same claim — a second model read your messages and concluded this matches what you asked
for — differing only in what else the user has to be told, so they differ by a clause rather than
by being three hand-written sentences. Two copies of one security notice is how the surfaces come
to describe one event two ways, which is the defect [[TUI-C72]] exists for; this is the second
time in this area, so it is not a hypothetical. The neutralisation below runs ONCE, above the
branch, for that same reason: an arm that interpolated the command for itself would be protected
only by whichever cell happened to drive the other arm.
The carved arm is a MERGED notice, and on that path it REPLACES [[EXT-106]]’s own. §4.6’s
notice says the user named the host, and adds “the auto-rater found nothing wrong with it” —
true on the path it was written for, and false here, because reaching a check at all requires the
classifier to have rated the command destructive. So where both apply, the two are announced as
one sentence stating what actually happened: the host the user named, the rating the classifier
gave, and the check that lifted it. The call site fires §4.6’s notice only where this arm does
not, so a user is never reading two accounts of one command — and never learning to skim a stack
of warnings about a single event.
The host is carried in, not inferred from the floor. reachesNetwork is the caller’s reading
of which floor stood, and a carved command has no floor left standing — so an arm that leaned on
it would drop the only line telling the user to look at the host, on the one path where the
user’s own message is what authorised the fetch. The hosts are passed because the caller is the
one reader that knows arm precedence resolved to a carve.
The command is model-authored, so it is neutralised to one line before it reaches a terminal —
the same treatment the negotiation transcript’s own rows give it. Deliberately not truncated:
this notice’s whole job is to say WHICH command ran. The hosts are not neutralised and do not need
to be: carvedOpenWorldHosts returns a host only where it matched the user’s own words verbatim,
so no character of one is the model’s to choose.
Parameters
Section titled “Parameters”options
Section titled “options”carvedHosts?
Section titled “carvedHosts?”readonly string[]
command
Section titled “command”string
reachesNetwork
Section titled “reachesNetwork”boolean
rungLabel
Section titled “rungLabel”string
Returns
Section titled “Returns”string