approvalsUndenyNotice
approvalsUndenyNotice(
lift):SlashCommandNotice
Defined in: packages/agent/src/modules/slashCommands.ts:1217
[[EXT-107]] — the notice for a /approvals undeny, built from what the runner RETURNS rather
than from what was asked for, so it can only describe the refusal actually lifted.
Three outcomes, and the two that are not a plain success are the ones worth the branches:
- A configured entry is not lifted, because
approvals.denyis a file the user wrote and no session command rewrites it. Saying where it lives is the whole of the help they need. - A lifted entry that
approvals.denyALSO matches is still refused. Reporting the removal without that would tell the user they had opened something that is still closed — the same “offered and then refused” failure the escalation menu is written to avoid, one layer up. - A lift whose file rewrite did not land comes back tomorrow ([[EXT-149]]). The refusal is gone for this session and still in the project file, so the promise this notice used to make unconditionally — it will not come back in a new session — is the one thing that is false there. The store’s own error names the file and the reason the write failed; what this adds is what that means for the refusal the user just asked to lift.