Design manifest command allow flow for unfamiliar repositories

[codeforester]

Problem

Base correctly documents manifest-declared commands as trusted project code, but there is no persisted first-run allow flow before executing commands from an unfamiliar repository. basectl workspace clone and workspace pull can shorten the path from receiving a workspace manifest to running project-owned shell commands.

Evidence

• Manifest command execution uses project-owned shell command strings.
• README and docs warn users to review unfamiliar manifests before running basectl test, build, or run.
• There is no per-repo allow record comparable to direnv allow.

Desired outcome

Design a Base-native trust flow that requires explicit user approval before first execution of manifest-declared commands from a repository that has not been allowed on this machine.

Scope

• Define the trust identity: repository path, Git remote, manifest path, manifest digest, or a combination.
• Define commands that require approval and commands that remain read-only.
• Define storage location under Base-managed local state.
• Define non-interactive and CI behavior.
• Preserve existing dry-run/list inspection paths.

Non-goals

• Do not sandbox project commands.
• Do not claim hostile manifests are safe after linting.
• Do not block read-only manifest validation.

Acceptance criteria

• A design document or first implementation slice defines the allow model.
• The design includes user-facing command text and JSON/non-interactive behavior.
• Follow-up implementation issues are split if the full feature is too large for one PR.