NAME

repocfg-demo - show per-repo command allowlist loading

SYNOPSIS

repocfg-demo

DESCRIPTION

repocfg-demo exercises the per-repo command allowlist. cli-guard walks up from cwd looking for a .coily/coily.yaml that declares named verbs (build, test, lint, deploy, ...). Each verb is a fixed argv. Each argv token is policy.ValidateArg'd at load time, so the exposed surface at runtime can never be a shell pipeline or contain shell metacharacters.

Why a per-repo file vs embedding the verbs in coily itself:

- Repo-specific dev tools change too often to warrant a
  rebuild+install cycle.
- The file is checked into git where a human reviews diffs.
  Adding a verb is a PR-visible event.
- The blast radius is bounded by the same policy.ValidateArg
  gate as every other coily verb. There is no "it's just a dev
  script" carve-out.

Threat-model corner cases the gate addresses:

- A repo-yaml verb that names a shell pipeline as its argv:
  rejected at load time, the verb never becomes invocable.
- A repo-yaml verb that names a fixed argv but at runtime the
  user appends a metacharacter-bearing extra arg: rejected at
  call time by the same gate.
- A repo-yaml verb in a repo that is not actually checked out
  (downloaded zipball, malicious upstream): the verb loads, but
  every audit row binds to the resolved git toplevel, so an
  audit reader sees the call did not come from a real commit.

Operating model for an agent calling repo verbs:

- The discovery walk stops at the first .coily/coily.yaml. If a
  sub-repo wants different verbs, the file in the sub-repo
  shadows the parent's.
- There is no merge / override semantics. The closest yaml
  wins; the rest is ignored.
- Verb arg appending: `coily test -v ./pkg/...` appends `-v
  ./pkg/...` to the yaml-declared argv, after the same gate.

Usage:

repocfg-demo [GLOBAL OPTIONS] [command [COMMAND OPTIONS]] [ARGUMENTS...]

COMMANDS

list

print the verbs declared in coily.yaml

run

execute a declared verb by name