Implement

# Generate Behavioral Spec (Optional)

**Skip if:** `--no-spec` flag, or issue type is `docs`/`chore`/`ci`.

After verification passes, produce a behavioral spec documenting what the implementation
does. This feeds Stage 4 behavioral validation (STEP 1.8 in /validation).

```bash
mkdir -p .agents/specs
cat > .agents/specs/<issue-id>.json <<'SPEC'
{
    "id": "auto-<issue-id>",
    "version": 1,
    "date": "<YYYY-MM-DD>",
    "goal": "<one-line: what user outcome this implementation serves>",
    "narrative": "<2-3 sentences: what the implementation does and how a user interacts with it>",
    "expected_outcome": "<what a satisfied user observes when this works correctly>",
    "acceptance_vectors": [
        {
            "dimension": "<name: correctness|performance|usability|security|...>",
            "threshold": <0.0-1.0>,
            "check": "<optional: mechanical check command>"
        }
    ],
    "satisfaction_threshold": 0.7,
    "scope": {
        "files": ["<list of modified files>"],
        "functions": ["<key functions added/modified>"],
        "behaviors": ["<behavioral descriptions>"]
    },
    "source": "agent",
    "status": "active"
}
SPEC
```

**Guidelines:**
- `acceptance_vectors` should capture the BEHAVIORAL contract, not test assertions.
  Example: `{"dimension": "isolation", "threshold": 1.0, "check": "echo ... | bash hook; test $? -eq 2"}`
- Include at least 2 acceptance vectors (correctness + one other dimension).
- `scope.files` must match the files you actually modified (not planned files).
- The spec is validated by the evaluator council during STEP 1.8 — it is NOT
  visible to YOU during implementation (holdout isolation applies to agent-built
  specs the same way it applies to human-written scenarios).

**If skipped:** Log "Behavioral spec skipped (reason: <flag|issue-type>)" and proceed.


# Binary-Deployment Gate (CLI/Hook Bug Fixes)

**Purpose:** Block declaring "done" on any CLI or runtime-hook bug fix until the **deployed runtime** matches the **source fix**. The user invokes the deployed binary and the cached hook — those are the actual surfaces under test, not the source tree.

**Why this gate exists:** A fix shipped to source while the deployed runtime is pre-fix keeps reproducing the bug during its own post-mortem. The post-mortem of the close-loop dedup fix on 2026-05-01 hit exactly this: source-level tests passed, the issue was closed, but `~/go/bin/ao` was still the pre-fix binary, so duplicates kept generating during the post-mortem itself.

**Sources:**
- Council finding: `.agents/council/2026-05-01-evolution-cycle-council.md`, finding 1, action item A (6/6 judges concurred this is the highest-priority follow-up).
- Captured failure mode: `.agents/learnings/2026-05-01-fix-shipped-binary-stale.md`.

## Trigger

The gate fires when the diff touches CLI binaries or runtime hooks:

```bash
CHANGED=$(
    git diff --name-only HEAD~1 2>/dev/null
    git diff --name-only --cached 2>/dev/null
    git diff --name-only 2>/dev/null
)
TRIGGERS=$(printf '%s\n' "$CHANGED" | grep -E '^(cli/cmd/|hooks/|cli/embedded/hooks/)' | sort -u)
if [ -z "$TRIGGERS" ]; then
    echo "Binary-deployment gate: no CLI/hook surfaces touched — skip"
    exit 0
fi
echo "Binary-deployment gate FIRES on:"
printf '  %s\n' $TRIGGERS
```

If `$TRIGGERS` is empty, skip the gate. Otherwise, both checks below MUST pass before Step 5a.

## Check A: Deployed binary mtime ≥ source-fix commit timestamp

For each binary under `cli/cmd/<bin>/` touched by the diff (typically just `ao`):

```bash
BIN=ao   # substitute the binary you fixed

DEPLOYED=$(command -v "$BIN" 2>/dev/null)
if [ -z "$DEPLOYED" ]; then
    echo "BLOCK: $BIN not on PATH — fix is unreachable from a fresh shell"
    echo "  REMEDIATION: install the binary (cd cli && make install) or add to PATH"
    exit 1
fi

# Deployed mtime — Linux first, macOS fallback
DEPLOYED_MTIME=$(stat -c %Y "$DEPLOYED" 2>/dev/null || stat -f %m "$DEPLOYED")

# Source-fix commit ti