Guard human-only Intent commands from agent execution

Problem

IntentAudience controls presentation and redaction only. It is not authority. A TTY proves terminal interaction, not human identity. Current hooks are soft, fail-open convenience controls, not a security boundary. An agent with unrestricted shell and repository write access can bypass CLI guards or edit files directly. OS and host permissions remain the hard boundary.

Intent needs a command effect and authority classification that is separate from audience so an agent context cannot use presentation state or a pseudo-TTY to authorize trust or delivery changes.

Intent has no skill download command today. load reads an already installed permitted skill; it does not download content.

User outcome

Humans can keep existing confirmation-based trust and delivery workflows. Agents can inspect permitted Intent state and load already installed permitted skills. Automation can run its supported paths only through an explicit automation context. Audience never grants mutation authority.

In scope

• Introduce a command effect and authority classification separate from IntentAudience: observe, trust-mutation, delivery-mutation, source-mutation, and automation.
• Classify these as agent-safe observation:
  • list and list --json
  • load of an already installed permitted skill
  • meta
  • exclude list
  • validate and validate --check
  • stale and stale --json
  • install --dry-run
  • install --map --dry-run
  • install --print-prompt
  • scaffold
• Classify these as human-only trust or delivery mutations:
  • install when it writes intent.skills or guidance
  • install --map when it writes guidance
  • exclude add and exclude remove
  • hooks install
  • setup and setup-github-actions
  • any future skill acquisition or download command, if introduced
• Classify validate --fix, validate --set-version, and edit-package-json as source mutations governed by the caller's repository-write authority, not by IntentAudience.
• Classify validate --github-summary and supported CI workflow paths as automation-only, with explicit CI identity and token permissions.
• Require command implementations to declare their effect and authority class at registration or through one shared command policy.
• Deny an agent context before a human-only command can prompt, scan for selectors, write package policy, write guidance, install hooks, or install workflows.
• Preserve explicit automation paths without treating a TTY, an environment variable, or audience as authenticated human authority.
• Add focused tests for every command class, dry-run exception, mutation denial, automation allowance, and the rule that audience cannot grant authority.

Out of scope

• Cryptographic proof of human identity.
• A claim that Intent can contain an actor with unrestricted shell and repository write access.
• New dependencies or a new skill-content download command.
• Changes to the current Clack interactive permission setup work.
• Amendments to #220 or #228.

Acceptance criteria

• Every registered command action has an explicit effect and authority class.
• Agent execution can run only classified observation paths and can load only already installed permitted skills.
• Agent execution fails before any human-only trust or delivery mutation and before its related prompt or write path.
• IntentAudience, TTY detection, host permissions, and CI identity have separate documented roles.
• Existing supported automation paths remain usable only through an explicit automation context.
• Tests cover the command matrix and prove that changing audience or using a pseudo-TTY cannot grant human mutation authority.
• The documentation states that host permissions remain the security boundary for actors with unrestricted shell and repository write access.

Dependencies

Blocked by: None

#220 and #228 remain independent. This issue must not block or alter the current Clack work.

Start by locating command registration and the existing IntentAudience, agent, and automation-context handling. Map every listed command to an explicit effect and authority class, then run or add focused tests covering observation, mutation denial, dry-run exceptions, automation allowance, and audience or pseudo-TTY non-authority; done means all registered commands are classified and the acceptance matrix passes.