Guarded workflow approval gates conflict with the founding policy to reuse existing authorization #156

Observed during an explicitly authorized user-level CLI installation on 2026-10-23 with LocalSetup 4.57.0. The conflicting instructions below were also retrieved from current repository main.

Conflicting instructions

WORKFLOW_STANDARD.md, Founding design principle says to reuse unchanged approvals and ask only at a material decision or genuine authorization boundary.

ls-wf-risky-operations-safety-approval/SKILL.md, required gate sequence unconditionally requires a frozen exact command/edit payload and a fresh explicit approval immediately before execution. It also states that a changed command, value, target, scope or rollback plan invalidates approval, without an explicit distinction between ordinary implementation details within authorized work and a material change in authority or consequences.

Observable session behavior

1. The user explicitly requested installing the supported CLI clients and said to deploy them.
2. The user then narrowed the set, specified package-manager preferences and requested staging so updates would not affect working installations.
3. The agent read the guarded workflow, interpreted its unconditional gate as requiring an additional exact-plan approval, prepared a version/path inventory and backups, and stopped before installing.
4. The user had to restate approval and explicitly requested a global policy that an already assigned task should proceed without another approval request unless the approval stance materially changes.
5. Installation then completed within user-owned isolated roots, without elevation or default-client replacement.

This is an observed interpretation of the written workflow in one agent session, not evidence of an enforced runtime authorization check. The agent also bears responsibility for resolving instruction priority; the framework wording made the extra gate appear mandatory despite existing task authority.

Correction context

Please reconcile the owning workflow with the founding policy and global/client/user authority. The workflow should first determine whether applicable authorization already exists; routine command/path/version choices within that scope should not automatically force another user round trip. Fresh approval should remain required for an actual material scope/consequence/risk change, a destructive operation outside existing authority, or a client-enforced permission boundary.

Keep risk review, required backups, rollback evidence, credential protection and native permission enforcement. The requested correction concerns redundant approval, not removal of those controls or indefinite caching of destructive approval.

Related context: #66 proposed broad safety-skill consolidation and was closed as not planned. This report is the narrower, currently observable wording conflict; it does not require that consolidation.