dsh-harbor-evolution 0.4.0 → 0.6.0

package/schemas/ground-truth.schema.json

@@ -0,0 +1,61 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "title": "Evaluator Ground Truth v1",
+  "type": "object",
+  "additionalProperties": false,
+  "required": ["schema_version", "protocol", "ground_truth_id", "version", "source", "criteria", "cases"],
+  "properties": {
+    "schema_version": { "const": 1 },
+    "protocol": { "const": "ground-truth/v1" },
+    "ground_truth_id": { "type": "string", "minLength": 1 },
+    "version": { "type": "string", "minLength": 1 },
+    "source": {
+      "type": "object",
+      "required": ["kind", "description", "provenance", "independent_of_candidate"],
+      "properties": {
+        "kind": { "enum": ["human", "programmatic", "consensus", "model", "external"] },
+        "description": { "type": "string", "minLength": 1 },
+        "provenance": { "type": "string", "minLength": 1 },
+        "independent_of_candidate": { "const": true }
+      }
+    },
+    "criteria": {
+      "type": "array",
+      "minItems": 1,
+      "items": {
+        "type": "object",
+        "required": ["id", "label"],
+        "properties": {
+          "id": { "type": "string", "minLength": 1 },
+          "label": { "type": "string", "minLength": 1 }
+        }
+      }
+    },
+    "cases": {
+      "type": "array",
+      "items": {
+        "type": "object",
+        "required": ["id", "artifact_ref", "criteria"],
+        "properties": {
+          "id": { "type": "string", "minLength": 1 },
+          "artifact_ref": { "type": "string", "minLength": 1 },
+          "badcase": { "type": "boolean" },
+          "criteria": {
+            "type": "array",
+            "minItems": 1,
+            "items": {
+              "type": "object",
+              "required": ["id", "score", "weight", "reason"],
+              "properties": {
+                "id": { "type": "string", "minLength": 1 },
+                "score": { "enum": [0, 0.5, 1] },
+                "weight": { "type": "number", "exclusiveMinimum": 0 },
+                "reason": { "type": "string", "minLength": 1 }
+              }
+            }
+          }
+        }
+      }
+    }
+  }
+}

package/schemas/meta-evaluation-report.schema.json

@@ -0,0 +1,23 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "title": "Evaluator Meta-Evaluation Report v1",
+  "type": "object",
+  "required": ["schema_version", "protocol", "ground_truth", "evaluator", "coverage", "metrics", "disagreements"],
+  "properties": {
+    "schema_version": { "const": 1 },
+    "protocol": { "const": "meta-evaluation-report/v1" },
+    "ground_truth": { "type": "object" },
+    "evaluator": { "type": "object" },
+    "coverage": { "type": "object" },
+    "metrics": {
+      "type": "object",
+      "required": ["esf", "sce", "rcr"],
+      "properties": {
+        "esf": { "type": "number", "minimum": 0, "maximum": 1 },
+        "sce": { "type": "number", "minimum": 0, "maximum": 1 },
+        "rcr": { "type": ["number", "null"], "minimum": 0, "maximum": 1 }
+      }
+    },
+    "disagreements": { "type": "array" }
+  }
+}

package/skills/evolve-agent-with-harbor/SKILL.md

@@ -1,127 +1,198 @@
 ---
 name: evolve-agent-with-harbor
-description: Initialize, evaluate, compare, and safely improve a DeepSeek Harness Agent with Harbor. Use when the user asks to set up Harbor evaluation or Agent self-evolution, clarify an evaluation contract, create a Candidate, Dataset, or Promotion Policy, investigate a failed Job, or decide whether a Candidate should replace a baseline.
+description: Architect, initialize, run, diagnose, compare, and safely improve a DeepSeek Harness business Agent with Harbor Trial Lifecycle, Score Validity, Evidence Provenance, Evaluation Stack, Context v2, Architecture Doctor, and explicit Promotion Gate. Use for Harbor setup, Agent self-evolution, vertical-search evaluation loops, running Job inspection, failed Trial diagnosis, Candidate optimization, evaluator governance or meta-evaluation, and promotion decisions.
 ---
 
 # Evolve Agent With Harbor
 
-Turn a vague improvement request into a reproducible evaluation contract, immutable Candidates, comparable Harbor Jobs, and an auditable promotion recommendation. Treat Harbor as the experiment boundary; deployment remains outside this workflow.
+Build a reproducible improvement loop around three boundaries:
 
-## Choose the operating mode
+- **Generator/Candidate**: the immutable DSH Agent composition being improved.
+- **Evaluator/Evaluation Stack**: Integration, Renderer, Evaluator, Rubric, Diagnoser, Optimizer, Runner, Reporter, and Judge identities.
+- **Optimizer**: proposes one evidence-linked Candidate change; it never controls the final Gate.
 
-Infer the narrowest mode that satisfies the request:
+Treat Harbor as the experiment boundary. Deployment, CI/CD, and Champion replacement remain external actions requiring separate authority.
 
-- **Clarify**: define what progress means and what may change.
-- **Initialize**: create the missing Candidate, Dataset, and Promotion Policy structure.
-- **Evaluate**: snapshot and run one Candidate.
-- **Compare**: compare an existing baseline Job with a new Candidate Job.
-- **Evolve**: run the complete baseline, diagnosis, controlled change, regression, and gate loop.
-- **Meta-evaluate**: optimize a Verifier or Judge against human ground truth rather than optimizing the business Agent.
+## Select the narrowest mode
 
-Do not expand an evaluate-only request into code mutation or deployment.
+- **Clarify**: define progress, identities, constraints, and promotion ownership.
+- **Architecture**: inspect role boundaries and run `harbor_evolution_doctor`.
+- **Initialize**: read `references/initialization.md`, obtain explicit values, then call `harbor_evolution_init`.
+- **Diagnostic**: investigate failures without making a promotion claim.
+- **Promotion**: run a `promotion-eligible` Job and apply the deterministic Gate.
+- **Evolve**: baseline → diagnose → one controlled change → regression Job → Gate.
+- **Meta-evaluate**: improve an Evaluator/Judge against independently maintained, provenance-bearing GT.
+- **Govern**: inspect Evaluator/Rubric/Judge source and identities; preview whether a change requires a fresh baseline.
 
-## Clarify the evaluation contract
+Do not turn an inspection or diagnostic request into Agent mutation or deployment.
 
-Inspect the workspace and existing configuration before asking questions. Summarize known values, then resolve only material gaps. Prefer no more than three grouped questions in one turn.
+## Clarify before initializing
 
-Establish these fields:
+Inspect the workspace first. Resolve only material gaps, preferably in no more than three grouped questions. Obtain:
 
-1. Business behavior and the failure being improved.
-2. Candidate path and stable Agent product identity.
-3. Harbor Dataset path, test population, and environment constraints.
-4. Primary metric, minimum metrics, non-regression metrics, and tolerances.
-5. Baseline Candidate or baseline Job.
-6. Allowed mutation surface, forbidden files, and side-effect boundaries.
-7. Run budget, repeat policy for stochastic Agents, and stopping condition.
-8. Promotion owner and external CI/CD boundary.
+1. Business behavior, failure pattern, and Candidate path/product identity.
+2. Dataset path/id/version, task population, holdout boundary, and side-effect sandbox.
+3. Evaluation Stack id/version and one entry for every required role.
+4. Judge provider/model/version/parameters without credentials.
+5. Evaluation Contract id/version, primary metric and direction, diagnostic metrics, groups, and hard requirements.
+6. Promotion Policy id/version, delta, minimums, maximums, non-regression metrics, and metric directions.
+7. Baseline Job/Candidate, repeat policy, run budget, stopping rule, allowed mutation surface, and forbidden files.
+8. Promotion owner and external CI/CD handoff.
 
-Candidate and Dataset paths are hard blockers for a run. Baseline and promotion criteria are hard blockers for a comparison. Do not invent ground truth, metrics, or deployment authority. Offer explicit draft defaults when helpful, but obtain acceptance before using them as the evaluation contract.
+Never invent GT, a Judge model, reward definitions, thresholds, credentials, or deployment authority. Offer draft values only when clearly labeled and accepted.
 
-## Initialize safely
+## Enforce the strict architecture
 
-When required files are missing, read `references/initialization.md` before creating them. Initialize only inside the configured `projectRoot` and preserve existing files.
+Require these before every Job:
 
-- Keep the baseline immutable; create a new versioned Candidate directory for every optimization attempt.
-- Keep secrets out of Candidate files. Inject equal credentials and permissions at runtime.
-- Pin direct and transitive dependencies with a lockfile.
-- Make the Verifier emit a primary reward plus diagnostic metrics and failure evidence.
-- Version the Promotion Policy. A policy or Verifier change requires a fresh baseline.
-- Use test accounts, mocks, or sandboxes for business side effects.
+- `candidate-manifest.json` verified against the Candidate files.
+- `dataset-manifest.json` with unique task ids, non-empty instructions, safe paths, and a matching source digest.
+- `.harbor/evaluation-stack.yml` with all eight roles, Judge identity, and Evaluation Contract.
+- Evaluation Context v2 preview.
 
-If file-editing capabilities are unavailable, produce the exact initialization plan and unresolved choices instead of pretending files were created.
+Require `input_integrity`, `agent_completed`, `integration_valid`, `renderer_valid`, `judge_completed`, and `artifact_schema_valid` in the Trial validity contract. Specify which failures are hard requirements. Never infer that a numeric raw verifier reward is a valid Candidate quality score.
 
-## Run the stable evolution loop
+Before a formal Job, call in order:
 
-### 1. Establish the baseline
+1. `harbor_candidate_snapshot`
+2. `harbor_dataset_validate`
+3. `harbor_evolution_doctor`
+4. `harbor_context_preview`
 
-Call `harbor_candidate_snapshot` for the baseline Candidate. Then call `harbor_eval_run` with the accepted Candidate and Dataset paths. Record the Candidate id, version, digest, Job path, evaluation-context digest, metrics, exceptions, and failed trials.
+Do not launch a `promotion-eligible` Job when Doctor reports an error, no comparable baseline exists, or `fresh_baseline_required` is true. A diagnostic Job may investigate architecture warnings, but still requires a valid Candidate, Dataset Manifest, Evaluation Stack, and Context v2.
 
-`harbor_eval_run` already snapshots again before execution. Treat a digest mismatch as a real Candidate change, not as noise.
+Keep Runner orchestration-only. Treat these as architecture errors:
 
-### 2. Diagnose before changing
+- Runner combines HTTP integration, rubric, and Judge logic.
+- Runner makes a promotion/Champion decision.
 
-Use the summary returned by `harbor_eval_run`; call `harbor_eval_result` only when reopening an existing Job or when the stable summary is needed again. Read failed samples and trajectories when available.
+## Initialize without overwriting
 
-Classify each failure as one of:
+Read `references/initialization.md` when required files are missing. After the user accepts all required identities and metric semantics, call `harbor_evolution_init`. It preserves existing files and creates explicit placeholders that still require business implementation.
 
-- Agent capability or policy failure.
-- Tool-call, search, citation, or output-contract failure.
-- Dataset, Verifier, or ground-truth defect.
+After initialization:
+
+- Replace placeholders with real role implementations.
+- Pin Candidate dependencies and keep secrets runtime-injected.
+- Re-snapshot the Dataset after intentional Dataset changes.
+- Run Doctor again; initialization success is not evaluation readiness.
+
+## Determine comparability correctly
+
+Use the Context v2 `digest`, not timestamps or Job names.
+
+A fresh baseline is required when any of these change:
+
+- Dataset id, version, or source digest.
+- Integration, Renderer, Evaluator, or Rubric identity.
+- Judge provider, model, version, or parameters.
+- Runner marked `semantic: true`.
+- Harbor or integration runtime identity.
+
+Diagnoser, Optimizer, Reporter, and non-semantic Runner changes remain comparable but change the full audit digest. A Candidate digest must differ from the baseline Candidate digest. Promotion Policy is reapplied as a separately versioned decision contract; changing it does not rewrite Evaluation Context.
+
+## Run the evolution loop
+
+### Establish a baseline
+
+Call `harbor_eval_run` with Candidate, Dataset, Stack, explicit `mode`, and a Policy for `promotion-eligible`. Preserve Candidate, Dataset, Stack, Context, Doctor, Contract, Trial assessments, Population report, Summary, and later Promotion report.
+
+Never cherry-pick stochastic runs. Apply the accepted repeat/seed policy symmetrically.
+
+### Diagnose before changing
+
+Use `harbor_eval_result` to reopen evidence without guessing local artifact paths: default `view=summary`, `view=job` for capabilities and stage artifacts, `view=dataset` for Agent-visible instructions, `view=progress` while running, `view=trial` with a returned `trialId` for the generated output and sanitized evidence, and `view=governance` for Evaluator/Rubric/Judge source and upgrade impact. Inspect in this order:
+
+1. Confirm every Dataset item reached a terminal Trial state. Running, queued, cancelled, or missing Trials are not quality evidence.
+2. Check `score.valid` and every validity requirement. Display an invalid score as `—`, never `0`.
+3. Inspect evidence provenance. Keep `Real Renderer`, `ACP Agent Output Fallback`, raw transport evidence, Judge explanation, and deterministic diagnosis distinct.
+4. Inspect findings, recommendations, user-visible output, criteria, and timing.
+5. Classify the owning layer before proposing a mutation.
+
+Treat `raw_rewards` as audit-only when `score.valid=false`. Aggregate and compare only valid quality scores. Inspect Trial assessments and classify each failure as:
+
+- Candidate capability or policy.
+- Tool-call, invalid search, citation, or output-contract failure.
+- Dataset, Evaluator, Rubric, Judge, or GT defect.
 - Infrastructure, dependency, permission, timeout, or deployment failure.
-- Stochastic variance requiring repeats.
+- Stochastic uncertainty.
+
+Do not optimize the Candidate around broken evaluation infrastructure. Never leak holdout answers or GT into Candidate prompts, skills, tools, or memory.
+
+Use the formal terminal states precisely:
+
+- `candidate-quality-failed`: valid execution reached evaluation, but a Candidate-owned hard requirement failed.
+- `infrastructure-error`: dependency, sandbox, permission, transport, timeout, or runtime failure; no Candidate quality score.
+- `evaluation-error`: Renderer/Judge/Verifier did not complete; no Candidate quality score.
+- `cancelled`: preserve the attempt and do not score it.
 
-Do not optimize the Agent to compensate for a broken evaluation environment. Do not leak holdout answers or ground truth into the Candidate.
+For retry or resume, retain the old attempt and create a new attempt. Never replace an assessment or event history in place.
 
-### 3. Make one controlled change
+### Propose one controlled change
 
-State one hypothesis that connects evidence to the proposed change. Create a new immutable Candidate version and modify only the accepted mutation surface. Never edit the baseline Candidate in place.
+Require every optimization hypothesis to include:
 
-Snapshot the new Candidate and verify that its digest differs. If it does not differ, stop because no new Candidate exists.
+- Evidence references to Job/Trial/findings.
+- Root-cause classification.
+- Expected metric effect.
+- Exact mutation surface and forbidden surface.
+- Rollback condition.
 
-### 4. Re-run under the same context
+Create a new immutable Candidate version; never edit the baseline in place. Stop when the new digest is unchanged.
 
-Call `harbor_eval_run` with the same Dataset and evaluation settings. For stochastic Agents, use the accepted repeat policy for both baseline and Candidate; never cherry-pick the best run.
+### Re-run and gate
 
-Compare only Jobs whose `evaluation-context` digests match. If the context changed, establish a new baseline instead of claiming improvement.
+Call `harbor_context_preview`; establish a fresh baseline if needed. Run the Candidate under the same comparable Context. Then call `harbor_candidate_compare`.
 
-### 5. Apply the deterministic gate
+- `PROMOTE`: recommend external promotion with the complete evidence package.
+- `REJECT`: keep the Champion and explain every structured reason code.
 
-Call `harbor_candidate_compare` with the baseline Job, Candidate Job, and accepted Promotion Policy. Respect its decision:
+Never bypass `INFRASTRUCTURE_EXCEPTION_PRESENT`, `ARTIFACT_SCHEMA_INVALID`, Dataset/Stack/Rubric/Judge mismatch, or non-regression failures.
 
-- `PROMOTE`: recommend promotion and provide the evidence package.
-- `REJECT`: keep the current Champion and explain each failed criterion.
+A `diagnostic` Job must never invoke Gate. Reading the Workbench, generating a Reporter summary, or producing a non-reward Optimization Report also must not promote, deploy, publish, or replace the Champion. Gate remains a separate, explicit comparison action.
 
-The gate is a recommendation boundary. Never deploy, mutate the active DSH profile, merge code, or replace the Champion unless the user separately authorizes the external CI/CD action.
+## Govern evaluator changes
 
-## Preserve experimental invariants
+Read `references/evaluator-upgrade.md` whenever the user asks to improve, replace, align, calibrate, debug, or explain an Evaluator, Rubric, Judge, reward, or meta-evaluation loop.
 
-- One Job binds one Candidate digest; one Candidate may have many Jobs.
-- Baseline and Candidate must share the same evaluation-context digest.
-- Keep Candidate, evaluation context, policy, summaries, trajectories, and gate report as checkpoints.
-- Separate infrastructure failures from capability failures in every report.
-- Change one causal factor per iteration unless the user explicitly accepts a bundled experiment.
-- Use hidden or held-out evaluation data for promotion; do not let the Optimizer train directly on it.
-- Report uncertainty when sample size or stochastic variance prevents a stable conclusion.
+Use the Workbench Governance view to read component identity, source, Rubric, Judge parameters, Contract, and Context impact. Before any Evaluator/Rubric/Judge edit:
+
+1. Show the current source and proposed diff.
+2. State which reward semantics change.
+3. Create a new component and Stack version; never overwrite historical identity.
+4. Establish a fresh baseline when a reward-affecting digest or Judge identity changes.
+5. Run meta-evaluation against independently maintained GT when aligning the Evaluator itself.
+
+Saving a new identity does not automatically launch an evaluation or Gate.
+
+An Evaluator implementation must use `harbor-dsh-evaluator/v1`. It may declare `kind=script` or `kind=llm-as-judge`, but both kinds accept `evaluation-input/v1` and return `evaluation-result/v1`. Every Descriptor-declared Criterion must return its declared score plus a non-empty `reason` string and a non-empty `recommendation` string. Missing explanations or recommendations invalidate the evaluator result; Reporter must not invent them. Use `harbor_evaluator_inspect` before proposing a change. After the user approves, use `harbor_evaluator_update` only for an exact `editable_files` path and provide the current digest plus new Evaluator and Stack versions. The tool creates a new versioned bundle; it does not overwrite the old implementation, run meta-evaluation, establish a baseline, or invoke Gate.
 
 ## Handle evaluator meta-evaluation
 
-When the object being improved is the evaluator, rotate the roles:
+Rotate roles when improving the Evaluator:
 
-- Candidate is a Verifier or Judge version.
-- Dataset contains cases with independently maintained human ground truth.
-- Metrics measure evaluator alignment, such as RCR, bias, variance, calibration, latency, and cost.
-- Promotion compares evaluator Candidates under a fixed GT set and policy.
+- Candidate is the Evaluator/Rubric/Judge version.
+- Dataset contains fixed artifacts plus independently maintained GT with explicit source kind and provenance.
+- Metrics include RCR, bias, variance, calibration, latency, and cost as appropriate.
+- The Candidate evaluator must not author its own GT or final promotion decision.
 
-Never let the Candidate Judge provide its own final ground truth or promotion decision.
+GT may be human, programmatic, consensus-based, produced by an independently pinned model, or imported from an external standard. Independence and provenance matter more than the author type. The Candidate evaluator must never see labels before producing its observation.
 
-## Report each cycle
+When GT is missing, clarify its id/version, source kind, owner, provenance, Criteria, case selection, and adjudication process. Then call `harbor_ground_truth_init`; it creates a non-overwriting draft and never invents cases or labels. After cases are populated, collect repeated `evaluator-observations/v1` and call `harbor_evaluator_meta_evaluate`. Report ESF, SCE, RCR, coverage, disagreement slices, latency, and cost as applicable.
+
+Manage evaluator Candidates and meta-evaluation Jobs with the same Manifest, Context v2, Doctor, evidence, and Gate rules.
 
-Return a compact audit record containing:
+## Report each cycle
 
-- Accepted evaluation contract and any remaining assumptions.
-- Baseline and Candidate ids, versions, digests, and Job paths.
-- Evaluation-context and Promotion Policy identities.
-- Primary and diagnostic metric deltas.
-- Representative failure evidence and root-cause classification.
-- Gate decision with exact reasons.
-- External action required for promotion and the next controlled hypothesis if rejected.
+Return:
+
+- Accepted Evaluation Contract and unresolved assumptions.
+- Candidate, Dataset, Stack, Context, Judge, and Policy identities.
+- Comparable baseline or fresh-baseline decision.
+- Metric deltas, exception counts, Population groups, and artifact validation.
+- Dataset coverage, terminal-state counts, valid/invalid score counts, and selected attempt policy.
+- Representative Trial evidence and root-cause classes.
+- Evidence provenance and any capability unavailable on a legacy Job.
+- Controlled change hypothesis and mutation surface.
+- Gate decision with exact reason codes.
+- External CI/CD action still required.

package/skills/evolve-agent-with-harbor/references/evaluator-upgrade.md

@@ -0,0 +1,61 @@
+# Evaluator Upgrade Workflow
+
+Load this reference when the user wants to improve score reliability or change Evaluator, Rubric, Judge, reward semantics, or meta-evaluation.
+
+## Clarify the evaluator objective
+
+Inspect `harbor_eval_result view=governance` and representative Trial evidence first. Resolve:
+
+1. Which false positives, false negatives, disagreements, or calibration failures matter.
+2. Who owns the independently maintained GT, its source kind and provenance, and how adjudication works.
+3. Which meta-metrics define improvement: RCR, precision/recall, bias, variance, calibration, latency, or cost.
+4. The allowed Evaluator/Rubric/Judge mutation surface and budget.
+5. The approval owner for adopting new score semantics.
+
+Do not use the Candidate Agent to author its own GT. Do not infer GT from the current Evaluator output.
+
+## Create a new immutable evaluator identity
+
+Show the current identity, source, proposed diff, and expected semantic impact. Create new files and increment component plus Evaluation Stack versions. Never edit a historical Evaluator, Rubric, Judge identity, or old Job artifact in place.
+
+Use the `harbor-dsh-evaluator/v1` Descriptor as the implementation boundary:
+
+- `kind=script` for deterministic code, rules, or local models.
+- `kind=llm-as-judge` for a model-backed judge; keep credentials out of source and identity artifacts.
+- Both kinds consume `evaluation-input/v1` and return `evaluation-result/v1` with Descriptor-declared Criterion ids and score values.
+- Every Criterion also requires non-empty `reason` and `recommendation` strings. Missing fields invalidate the evaluator result; Reporter never fabricates them.
+- `editable_files` is the exact source allowlist used by the Workbench and `harbor_evaluator_update`.
+
+Call `harbor_evaluator_inspect` to capture the active digest. After explicit approval, `harbor_evaluator_update` requires the expected file digest plus new Evaluator and Stack versions, copies the whole bundle to a new version directory, and switches the active Stack. It never launches evaluation or Gate.
+
+Treat changes to any of these as reward-semantic changes requiring a new Context and fresh Agent baseline:
+
+- Evaluator source or digest.
+- Rubric source or digest.
+- Judge provider, model, version, or parameters.
+- Evaluation Contract metric meaning or hard requirements.
+
+## Meta-evaluate before adopting
+
+Rotate roles:
+
+- Candidate: the new Evaluator/Rubric/Judge version.
+- Dataset: independently maintained examples with provenance-bearing GT and disagreement metadata.
+- Evaluator: deterministic comparison between evaluator decisions and GT.
+- Reporter: RCR and accepted diagnostic slices.
+- Gate: explicit human-approved adoption decision.
+
+Use the same GT set, repeat policy, and measurement procedure for old and new evaluator Candidates. Report coverage, invalid measurements, aggregate metrics, disagreement slices, latency, cost, and representative errors. Do not select only favorable runs.
+
+GT is not synonymous with human labeling. It may be human, programmatic, consensus-based, produced by a separately pinned model, or imported from an external standard. Require explicit provenance and independence from the Candidate evaluator in every case. Use `harbor_ground_truth_init` to create the versioned draft and `harbor_evaluator_meta_evaluate` to calculate ESF, SCE, and RCR from repeated observations.
+
+## Re-baseline Agent progress
+
+After the evaluator Candidate passes its explicit Gate:
+
+1. Update Evaluation Stack identity.
+2. Preview Context v2 and confirm old Agent Jobs are no longer comparable.
+3. Run the current Champion Agent as a fresh baseline under the new evaluator.
+4. Compare later Agent Candidates only against Jobs sharing the new Context digest.
+
+Adopting an evaluator does not mutate, promote, deploy, or publish an Agent automatically.