fix(agents): idempotency discipline for git-ops (context-truncation thrash)

[Brian Krabach (bkrabach)]

Summary

• Adds a compact Idempotency Discipline checklist to agents/git-ops.md, positioned right after the existing "Git Safety Protocol" section (near the top of operational guidance, before the command references) so it survives context truncation.
• Addresses work item openai_improvement-bq0: 5 production eval runs (fast-tier model, enable_long_context=false) showed git-ops re-running git clone --branch main --single-branch <same URL> up to 8x and git ls-remote --symref <same URL> up to 7x within a single session (one run: 30 bash calls, only 14 unique) — the signature of context truncation losing the memory that setup work already completed. Sessions ran 809–1168s despite the "fast" label.
• Prompt/agent-definition change only — no Python touched.

Added text (exact)

## Idempotency Discipline

Disk and repo state are the source of truth — not your memory of what you already ran.

**Before ANY clone:** check whether the target directory already exists with the right remote (`git -C <dir> remote get-url origin`). If it matches, `git -C <dir> fetch` instead of re-cloning. Never clone the same URL twice in one session.

**Remote-discovery commands run at most once per remote per session.** `git ls-remote`, default-branch lookups, and similar discovery calls are one-shot — write the result into your working notes immediately and reuse it. Don't re-derive it.

**About to repeat a command you believe you already ran? Stop.** Check the filesystem/repo state first. Repeated identical commands are the signature of lost context, not a reason to run them again.

Inserted between the existing "Git Safety Protocol" and "Common Git Commands" sections (agents/git-ops.md:124-133 on this branch).

Test plan

• N/A — prompt/agent-definition-only change (Markdown frontmatter + prose), no code paths to unit test.
• Diff reviewed for minimality: 10 lines added, 0 removed, no restructuring of surrounding sections.
• Recommend validating with a DTU/eval re-run against the same fast-tier/enable_long_context=false matrix entry that produced the original evidence, to confirm the repeat-clone/repeat-ls-remote pattern no longer recurs.

Recommendation for routing-matrix maintainers (informational — no code change here)

I looked in microsoft/amplifier-bundle-routing-matrix (shallow clone of main) for where the fast role sets enable_long_context=false, to cite it here. Honest finding: the literal key enable_long_context does not appear anywhere in that repository — not in any of the eight shipped matrices (routing/anthropic.yaml, balanced.yaml, copilot.yaml, economy.yaml, gemini.yaml, ollama.yaml, openai.yaml, quality.yaml), not in behaviors/routing.yaml or context/routing-instructions.md, and not in the hooks-routing module source (modules/hooks-routing/amplifier_module_hooks_routing/{__init__,matrix_loader,resolver,resolver_class}.py). Every fast: role block in every shipped matrix is configless (candidates only, no config: block at all); the only per-candidate config: keys used anywhere in the repo are reasoning_effort (and priority, internally). matrix_loader.validate_matrix_config is explicitly "closed on values, OPEN on keys" — it validates candidate config: keys against whatever config_fields the installed provider module reports, meaning enable_long_context is a provider-level config field, not something the routing-matrix repo itself declares or sets.

The enable_long_context=false value cited in the eval evidence traces to this CI harness's own run summary (_ci_eval_summary.json in openai-evals-team-ci), where the fast-role spawn for anchors-amp-dev:git-ops resolves to provider: luna, model: gpt-5.6-luna with config: {enable_long_context: "false", ...} — i.e. it's set by the eval harness's per-role provider config (or the underlying provider module it resolves to), not by a literal setting inside amplifier-bundle-routing-matrix.

Recommendation: whoever owns that per-role provider config (eval harness config, or the luna/fast-tier provider module if enable_long_context is a first-class field there) should re-evaluate defaulting enable_long_context=false for agents like git-ops that accumulate long, repetitive bash command histories across a session — this idempotency fix reduces the symptom (repeated commands), but the truncation-thrash evidence above suggests the root cause (losing session memory mid-run) would also benefit from being addressed at the context-window-management layer for operational agents.

Generated with Amplifier

[Brian Krabach (bkrabach)]

Maintainer admin-merge basis (documented per team policy):

• Author: this PR was authored by our own automated account. GitHub structurally forbids self-approval, so no self-review can satisfy branch protection here — an external human reviewer is not in the loop for this change.
• Test evidence: 10-line agent-definition addition (no code). Root cause verified via fast-tier git-ops re-running identical clone (x8) and ls-remote (x7) under context truncation — idempotency discipline added to prevent this thrash. No new test suite changes required; behavior is instruction-level.
• CI status at merge time: all 6 matrix jobs (ubuntu/windows × Python 3.11/3.12/3.13) + license/cla check green. See status checks on this PR.
• Action: merging via maintainer admin override (gh pr merge --admin) at the explicit direction of the repository owner, following the same sanctioned pattern previously used for gemini#39 (self-authored, self-approval-impossible, explicit maintainer direction).

Squash-merging now.

[Brian Krabach (bkrabach)]

CORRECTION: this PR's evidentiary basis has been refuted. Deduped payload-level re-analysis shows the "git clone x8 / ls-remote x7 thrash" was 8 DIFFERENT provider repos cloned once each plus per-repo remote checks — legitimate work, not context-truncation thrash. The original count came from duplicate snapshot copies of session event files being counted 2-4x (verified via identical tool_call_id + timestamps). The Idempotency Discipline section is being removed in #328. The mid-PR observation that enable_long_context config is provider-level (not routing-matrix) stands.