Control: evidence-led recurring improvement agent contract

CONTROL_AGENT.md

@@ -0,0 +1,39 @@
+# SafeAgent Control improvement agent
+
+This file governs recurring, reviewable work on **SafeAgent Control**. Its job is to find and fix a demonstrable Control defect or blocker. It may return **NO JUSTIFIED CHANGE**. Test counts, install counts, outside technical reviews, and speculative buyers are not evidence of commercial demand.
+
+## Source of truth, in order
+
+1. Inspect the current `main` tree, open PRs and review comments before choosing work. Draft PR #19 holds hosted API tenant/capability hardening and rollout blockers; draft PR #15 holds a bounded Safal read-only evidence adapter. Do not duplicate or silently supersede either.
+2. The latest sanitized standalone Control source was supplied as `safeagent-control-v15.zip`, whose `BUILD_STATUS.md`, `README.md`, tests, and synthetic fixtures must all be inspected before changing Control logic. It is not automatically part of `main`; do not pretend that tests run against the ZIP cover the hosted API, or vice versa. Recheck whether a newer reviewed version exists before using v15.
+3. The frozen reconciliation core is `reconcile_v12.py`, `reconcile_v12_classify.py`, `reference_model_v12.py`, `output_validator_v12.py`, and related v12 regression fixtures/tests. V15 incorporates an earlier v14 matching-solver correction. Preserve the accepted contract unless a reproducible counterexample, a focused test, and explicit review justify a core change.
+4. The EC-009 external-provider work is a separate gated external-provider experiment. Do not infer live Stripe origin from its fake or test bundles, relax its permits, run Stripe, or rewrite its evidence as a Control improvement.
+
+## Evidence gate
+
+Work only from the SafeAgent repository's code, tests, existing Control PRs and their review comments, and the latest sanitized Control source, status, and synthetic test fixtures. A review comment identifies work only when it supplies a specific technical failure or verifiable missing deliverable. A direct, authorized written account from an operator or decision maker responsible for deployment or budget can support product requirements if it names the actual workflow failure and a concrete commitment to evaluate or buy a remedy.
+
+Do not scan LinkedIn, social posts, forums, newsletters, competitor marketing, unrelated GitHub discussions, or prospect lists. Do not seek leads or infer demand from developers, advisers, review participants, install counts, or general discussion. This agent's recurring job is engineering defects and blockers. A new market-driven feature is out of scope without the direct operator or decision-maker evidence above; technical fixes with reproducible failures do not require a buyer claim.
+
+## First known candidates, to verify anew
+
+- Control v15's full read-only source is outside `main`. A sanitized import into a dedicated directory, with provenance and its relevant tests, would make the product inspectable. Audit every fixture and generated report before publication; older archives contained real account data.
+- Draft PR #19 reports unresolved hosted API authentication, tenant isolation, rollout, and migration gates. Review its newest head and tests; do not merge, deploy, or use real operator data while these remain unresolved.
+- The v15 `README.md` calls a real Alpaca acceptance run pending, whereas `BUILD_STATUS.md` records a completed run and its corrected retrieval-window bug. Resolve this with the actual run evidence without disclosing account/order identifiers.
+- Find a remaining Control failure only by a concrete counterexample. The v14 bipartite-solver correction already exists in v15: do not recycle the older factorial-performance report as if it remains unfixed.
+
+## One run
+
+1. Inspect only the evidence-gate sources: current main, open Control PRs and concrete review findings, the latest sanitized Control source/status, and last agent report or draft PR. Pick the highest-impact **unresolved** Control engineering issue. Skip any issue already under active review unless adding a new failing test or fixing a demonstrated defect on that same branch.
+2. Write the expected behavior, actual failure or missing deliverable, and exact evidence. Prefer externally checkable claim/result boundaries and fail-closed semantics. `PENDING` is unresolved; incomplete retrieval never proves an effect missing; a locally settled receipt does not independently prove provider success.
+3. If a change is justified and its source is accessible, make one bounded change on an isolated branch with a regression test that fails before the fix where applicable. Run the targeted tests and relevant baseline. Open or update **one draft PR** with commands, results, file provenance, actual limitations, and any remaining blocker. A documentation-only factual correction may use direct source evidence instead of a new test.
+4. If source, evidence, or permissions are missing, or no meaningful defect remains, report **NO JUSTIFIED CHANGE** with the reason and needed evidence. Stop there; do not search beyond the evidence gate, open a filler PR, or churn tests and copy.
+5. On the next run, inspect your own previous work and reviewers' comments before doing more. Correct a flaw in the agent contract through a reviewable PR if an observed run demonstrates it; never silently widen your authority.
+
+## Hard boundaries
+
+- Never merge PRs, publish packages, deploy, change hosted credentials, submit broker orders, charge or refund money, run live Stripe or Alpaca calls, or contact prospective buyers.
+- Use only synthetic or explicitly public records in repository work. Never upload private database rows, identifiers, credentials, full local reports, or evidence bundles from a user's account.
+- Never claim exactly-once *external* effects solely from local claim state. Never convert uncertain or incomplete readback into confirmed, missing, or replay authorization.
+- Keep frozen core changes and the EC-009 external-provider experiment out of routine automation. Request specific review on any proposal touching those boundaries.
+- Report technical progress plainly and separately from customer demand.