feat(skills): baseline-source ladder - greenfield and recipe-confirmed baselines

.agents/skills/author-baseline-dgd/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: author-baseline-dgd
+description: >-
+  Drafts a candidate baseline DynamoGraphDeployment from interview requirements when no catalog recipe matches the
+  user's model, hardware, and backend, presenting per-decision evidence for the user's confirmation. Use only from
+  user-interviewer at interview time, at rung 3 of the baseline-source ladder, and never to deploy or to replace a
+  baseline the user already provided.
+license: Apache-2.0
+metadata:
+  author: NVIDIA
+  tags:
+    - dynamo
+    - workload
+    - interview
+    - optimization
+---
+
+# Author Baseline DGD
+
+Draft ONE candidate baseline DGD for a greenfield engagement and present it for the user's explicit confirmation.
+Do not deploy, benchmark, apply, or record anything as the baseline: an unconfirmed draft is a proposal, and only
+the user's confirmation makes it a user-provided baseline.
+
+## Inputs
+
+Require:
+
+- the interview fact table from `synthesize-user-workload` (model source and revision, hardware type and count,
+  backend and precision preferences, workload shape, SLOs, Kubernetes context and namespace);
+- the recipe catalog scan that established rung 3 (no exact or close recipe), including the nearest recipes
+  considered and why each was rejected as a base; and
+- any user-stated constraints (`resources.pinned` candidates, budgets) already collected.
+
+If model identity or hardware type and count is missing, return the question to `user-interviewer` instead of
+guessing. Backend is different: when the user explicitly has no preference, CHOOSE it here with evidence - prefer
+the backend whose nearest catalog recipe scaffolds this model family and hardware, per the knob guides' coverage -
+and record the choice and its evidence in the decision table the user confirms. A confirmed draft's backend is a
+confirmed decision, not an invented default; the contract's `preferences.framework` still records only what the
+user themselves stated.
+
+## Read The Applicable Knowledge
+
+Always read:
+
+- all three files under `agent-docs/guides/model-sizing/` (memory fit, `min_tp`, classification);
+- `agent-docs/guides/knob-tuning/tuning-hierarchy.md`;
+- the chosen backend's guide (`agent-docs/guides/knob-tuning/vllm.md`, `sglang.md`, or `tensorrt-llm.md`) -
+  when choosing the backend here, read the candidates' guides as needed to make the choice;
+- `agent-docs/guides/knob-tuning/dynamo.md`; and
+- the nearest catalog recipes' manifests, as structural scaffolding only.
+
+Read `agent-docs/guides/rate-matching/matching.md` only when the draft is disaggregated (rare for a baseline;
+prefer aggregated unless the user's SLOs demand otherwise).
+
+## Author The Draft
+
+1. **Size the model**: compute weight bytes, `min_tp`, and `headroom_ratio` per `memory.md`, showing the
+   arithmetic. Choose the serving TP per `parallelism.md` (prefer lower TP and more replicas for throughput
+   workloads; raise TP above `min_tp` only when headroom demands it, recording the replica cost).
+2. **Choose topology conservatively**: an aggregated single-node layout unless the user's hardware or SLOs force
+   otherwise. The baseline's job is to run and measure, not to win; the optimization loop owns improvement.
+3. **Scaffold from the nearest recipe**: copy its structure (components, probes, service wiring, image versions
+   for the chosen backend) and replace model, parallelism, resources, and any hardware-bound fields, naming every
+   replacement. Never carry a hardware-bound topology, transport, or checkpoint choice across without evidence it
+   fits the target.
+4. **Set knobs to the backend guide's defaults**, deviating only where the sizing arithmetic requires it
+   (e.g. `gpu_memory_utilization`, `max_model_len` capped to the workload). Leave optimization headroom alone.
+5. **Validate the draft**: parse as YAML, exactly one `DynamoGraphDeployment` document, no secret values, and
+   confirm it would pass `kubectl apply --dry-run=server` semantics (correct API version, resource names, required
+   fields) to the extent checkable offline.
+
+## Present For Confirmation
+
+Return to `user-interviewer`, for relay to the user:
+
+- the complete draft manifest;
+- a per-decision evidence table: each major choice (TP, replicas, memory settings, backend, image, topology) with
+  the guide citation or arithmetic that produced it;
+- the nearest recipes considered and why each was rejected as a base; and
+- the explicit statement that this draft is unvalidated on hardware and iteration 0 will characterize it.
+
+Do not proceed on silence, enthusiasm, or a partial answer: confirmation is the user's explicit acceptance of THIS
+manifest (or of it as amended by the user). The confirmed manifest goes to `synthesize-user-workload` for canonical
+capture with `deployment.origin: agent-authored` and `deployment.origin_source: inputs/baseline-evidence.md`
+(the interviewer writes the evidence table and confirmation there at capture time, per `run-artifacts.md`).
+
+## Do Not
+
+- Deploy, benchmark, or apply anything.
+- Record an unconfirmed draft anywhere a downstream role could mistake it for the baseline.
+- Author when a user DGD exists (that engagement has a baseline) or when rung 1 or 2 produced a viable base.
+- Invent model, hardware, or SLO facts; missing facts return to the interview.
+- Embed secret values or Kubernetes `Secret` resources.

.agents/skills/perform-adversarial-review/SKILL.md

@@ -122,6 +122,9 @@ Attack the proposal from these directions:
   impact on the primary objective, reversibility, GPU cost, and risk at the target operating region?
 - **Attribution**: Does the complete diff express one independently testable knob? For a coupled bundle, is every field
   required for one mechanism or supported by prior interaction evidence, with an ablation where needed?
+- **Provenance**: When `deployment.origin` is `recipe-confirmed` or `agent-authored`, reject any framing of the
+  baseline as a production reference; iteration 0 characterizes an unvalidated starting point, and topology
+  families inherited from it are open questions, not settled decisions.
 - **Mechanism**: Does the proposed lever address a plausible reducible gap at the target operating region, or merely
   move work that evidence suggests is already bounded? Are internal causes still labeled as hypotheses?
 - **Evaluation**: Is the expected effect tied to the primary objective or failed SLO? Does the proposal state what the

.agents/skills/synthesize-user-workload/SKILL.md

@@ -24,7 +24,8 @@ not search for or select a recipe, deploy, benchmark, or propose tuning changes.
 Require:
 
 - the user's initial optimization request exactly as received;
-- the user-provided DGD as an attachment, local file path, or pasted YAML;
+- the user-provided DGD as an attachment, local file path, or pasted YAML, when one exists; otherwise the
+  ladder-confirmed baseline manifest handed over by `user-interviewer` with its confirmation record;
 - any attached workload descriptions, traces, or other local file paths;
 - an optional caller-supplied `EXP_ID` or `EXP_ROOT`; and
 - an existing `user_workload.yaml` only when the user is refining the interview before downstream work begins.
@@ -40,7 +41,8 @@ final YAML.
 
 Resolve these blocking fields:
 
-- one concrete user-provided YAML document containing a `DynamoGraphDeployment`;
+- one concrete baseline `DynamoGraphDeployment`: either user-provided, or produced by the baseline-source ladder
+  (`agents/user-interviewer/AGENTS.md`) and explicitly confirmed by the user;
 - workload profile name, type, and a concrete description of the serving traffic;
 - exact model source and revision when the user fixes one, plus the fallback policy when the requested revision
   may be unsupported by the available engine or weights (fall back to a named alternative and mark the target
@@ -110,12 +112,17 @@ Create the canonical baseline input:
 
 - When the user supplies a file, copy its bytes without editing the source or canonical copy.
 - When the user pastes YAML, materialize that YAML without changing its configuration.
+- When the baseline came from the ladder (rung 2 adapted recipe or rung 3 authored draft), materialize the exact
+  manifest the user confirmed - byte-for-byte as confirmed, including any user amendments - and record the
+  matching `origin` and `origin_source`.
 - Parse the canonical copy as YAML and require at least one mapping document whose `kind` is
   `DynamoGraphDeployment`.
 - Reject embedded secret values or Kubernetes `Secret` resources; references to pre-existing Secret names are allowed.
 - Reject a recipe directory, catalog choice, generated substitute, or inferred default in place of the user's DGD.
-  A specific manifest the user explicitly presents as their baseline is a user-provided DGD, whatever its origin;
-  the rejection targets substitutes the USER did not supply.
+  A specific manifest the user explicitly presents OR confirms as their baseline is a user-provided baseline,
+  whatever its origin; the rejection targets substitutes the user never confirmed. Record the provenance in the
+  contract: `deployment.origin` (`user`, `recipe-confirmed`, or `agent-authored`) and `deployment.origin_source`
+  per the schema.
 - Do not patch cluster compatibility or performance settings during capture.
 - Compute the canonical copy's SHA256 before writing the workload contract.
 - If the DGD contradicts an explicit workload constraint, return the contradiction as a blocking question; do not
@@ -136,7 +143,8 @@ Follow the schema and rules in `agent-docs/rules/execution/user-workload.md`.
 Before finalizing:
 
 1. Preserve all explicit user constraints without rounding or reinterpretation.
-2. Record the exact canonical DGD path and SHA256 under `deployment`.
+2. Record the exact canonical DGD path and SHA256 under `deployment`, plus `origin` and `origin_source`
+   (provenance of the confirmed baseline).
 2a. Record the user's stated budgets (GPU-hours, wall clock, failed-deploy limit) under `budgets`, verbatim;
     leave each `null` when the user declined to state one.
 3. Represent permitted unknowns as `null`, `""`, or `[]` according to the schema.

AGENTS.md

@@ -47,7 +47,8 @@ to it — edit only the canonical copy. Reach for the right group first:
 
 **For deploying and operating Dynamo:**
 
-- `synthesize-user-workload` — interview the user, capture their DGD, and create the canonical workload contract
+- `synthesize-user-workload` — interview the user, capture their confirmed baseline DGD, and create the canonical workload contract
+- `author-baseline-dgd` — draft a baseline DGD from interview requirements when no recipe matches, for the user's confirmation
 - `consult-perf-knowledge` — select one evidence-backed optimization proposal and write its reasoning record
 - `create-optimization-hypothesis` — materialize a performance consultation as a challenger-ready DGD draft
 - `perform-adversarial-review` — challenge a generated DGD candidate before it consumes GPU time
@@ -81,17 +82,25 @@ write and requires operator consent. Rules:
 
 ## Optimization Role Dispatch
 
-When the first user message starts a new Dynamo recipe optimization run, dispatch `user_interviewer` before any other
-specialized role. It must invoke `synthesize-user-workload` and produce a validated
-`<EXP_ROOT>/user_workload.yaml` plus an immutable `<EXP_ROOT>/inputs/user_provided_dgd.yaml` copied from the DGD the
-user supplied. Do not dispatch `recipe_deployer`, `perf_analyzer`, `hypothesis_generator`, or
+When the first user message starts a new Dynamo recipe optimization run, FIRST read
+`agent-docs/guides/optimization/optimize-loop.md` end to end - the individual SKILL.md files are auto-discoverable,
+but the loop's sequencing, state machine, and stopping rules live only in that guide - then dispatch
+`user_interviewer` before any other specialized role. It must invoke `synthesize-user-workload` and produce a validated
+`<EXP_ROOT>/user_workload.yaml` plus an immutable `<EXP_ROOT>/inputs/user_provided_dgd.yaml` copied from the baseline the
+user supplied or explicitly confirmed. Do not dispatch `recipe_deployer`, `perf_analyzer`, `hypothesis_generator`, or
 `hypothesis_challenger` until both exact paths and SHA256 values are available. Pass both inputs directly to
 `recipe_deployer`; pass the same immutable workload path and hash to every later role. Do not insert a recipe
-exploration or selection step before the baseline deployment.
+exploration or selection step after the interview: the baseline-source ladder
+(`agents/user-interviewer/AGENTS.md`) is the only place selection or authoring happens, always with the user's
+explicit confirmation, and always before the loop starts.
 
 ## Long-Running Runs And Harness Compatibility
 
-An optimization loop is long-running, unattended work. An interactive harness ends its turn whenever the agent stops
+An optimization loop is long-running, unattended work. Know which harness you are in: in a SINGLE-SHOT harness
+(headless `-p`/print mode, one-turn API calls), background-job completion notifications can never reach you - the
+session is gone when your turn ends. There, poll synchronously with bounded loops and never park the engagement on
+a wake-up you cannot receive; parking is only valid where the harness can re-invoke you (interactive sessions, goal
+mode). An interactive harness ends its turn whenever the agent stops
 calling tools — a turn that ends on narrated intent ("now I'll test disagg") silently stalls the loop until a human
 notices. Two rules:
 

agent-docs/guides/optimization/optimize-loop.md

@@ -33,9 +33,11 @@ rules:
 
 # Optimize Loop
 
-Use this workflow for an end-to-end Dynamo configuration optimization job. The user supplies the baseline DGD;
-`user-interviewer` captures it and hands it directly to `recipe-deployer`. There is no recipe-discovery or
-recipe-selection step in this workflow.
+Use this workflow for an end-to-end Dynamo configuration optimization job. The baseline DGD comes from the
+interview's baseline-source ladder (`agents/user-interviewer/AGENTS.md`): supplied by the user, or a recipe or
+authored draft the user explicitly confirmed. `user-interviewer` captures the confirmed baseline and hands it
+directly to `recipe-deployer`. Selection and authoring happen only at interview time with user confirmation; the
+LOOP itself has no recipe-discovery or recipe-selection step.
 
 When using Codex multi-agent mode, dispatch registered roles through `.codex/config.toml`. Each launcher must read and
 follow its corresponding `agents/<role>/AGENTS.md` contract.
@@ -58,7 +60,8 @@ answers; do not advance the workflow meanwhile.
 
 ## 2. Validate The Baseline Handoff
 
-Require the exact `EXP_ROOT`, `user_workload.yaml` path and SHA256, `user_provided_dgd.yaml` path and SHA256, and
+Require the exact `EXP_ROOT`, `user_workload.yaml` path and SHA256, `user_provided_dgd.yaml` path and SHA256,
+`deployment.origin` (with `origin_source` for non-user origins), and
 zero-based iteration `0`. Confirm that the user-provided DGD's model, framework, hardware, precision, and topology do
 not contradict the user workload. Do not edit, replace, or select an alternative DGD.
 
@@ -69,11 +72,11 @@ Give the exact assigned DGD path and SHA256, `user_workload.yaml` path and SHA25
 `user_provided_dgd.yaml`. No role selects or substitutes a baseline. When the user's DGD cannot run on the target as
 provided — it targets different hardware, checkpoints, or fabric — the deployer records the blocking
 incompatibilities in the deployment ledger and returns them; end the engagement with a report that states each
-incompatibility and its evidence, and invite the user to start a new engagement with a target-compatible DGD (a
-changed user DGD starts a new experiment, per `synthesize-user-workload`). Do not select a substitute, do not
-rewrite the captured baseline, and do not park the run waiting for a new manifest. Greenfield engagements — no user
-deployment at all — are likewise not supported by this workflow yet: say so at the interview, point the user at
-`recipes/README.md` to pick a starting recipe, and invite them to return with it as their baseline.
+incompatibility and its evidence, and invite the user to start a new engagement - with a target-compatible DGD of
+their own, or through the baseline-source ladder (rungs 2-3), which may use the incompatibility report as input
+evidence (a changed baseline starts a new experiment, per `synthesize-user-workload`). Do not select a substitute, do not
+rewrite the captured baseline, and do not park the run waiting for a new manifest. (A greenfield user without any
+DGD is handled at the interview by the baseline-source ladder, never here.)
 Later iterations use the exact challenger-approved draft. The deployer creates:
 
 ```text
@@ -87,7 +90,9 @@ semantics to hide a deployment failure.
 ## 4. Configure, Run, And Analyze The Benchmark
 
 Give the successful `DEPLOY_ROOT`, exact `user_workload.yaml` path and SHA256, and current performance question and
-target operating region to `perf-analyzer`. For iteration 0, use a baseline-characterization question. For later
+target operating region to `perf-analyzer`. For iteration 0, use a baseline-characterization question. When `deployment.origin` is not `user`, iteration 0
+is pure characterization: the baseline has no production history, so no result may be framed as an improvement or
+regression against it beyond the same-series comparisons the benchmark rules already govern. For later
 iterations, use the question approved with the candidate.
 
 - Select or create the benchmark series that best answers the question. Reuse a plan only when it remains fit; write

agent-docs/references/definitions.md

@@ -46,7 +46,7 @@ Default Pareto axes are `output_tput_per_gpu` and `tokens_per_sec_per_user`.
 - `EXP_ROOT`: `runs/<EXP_ID>/`, created by `user-interviewer` once for an optimization job.
 - `user_workload.yaml`: canonical workload contract synthesized from the user interview, with the baseline DGD
   path-and-hash record.
-- `user_provided_dgd.yaml`: immutable baseline DGD supplied by the user and captured under `EXP_ROOT/inputs/`.
+- `user_provided_dgd.yaml`: immutable baseline DGD supplied or explicitly confirmed by the user and captured under `EXP_ROOT/inputs/`.
 - `DEPLOY_ROOT`: `runs/<EXP_ID>/artifacts/deploy-iter-<NNN>/`, created for one candidate DGD.
 - `deployment_ledger.json`: deployment and smoke-test record.
 - `benchmark_summary.json`: parsed AIPerf metrics and comparison record.
@@ -60,7 +60,7 @@ Default Pareto axes are `output_tput_per_gpu` and `tokens_per_sec_per_user`.
 ## Agent Roles
 
 - **User Interviewer**: turns the user's initial request and minimal follow-up answers into `user_workload.yaml`,
-  captures the user-provided baseline DGD, and hands both immutable inputs to `recipe-deployer`.
+  captures the user-provided or user-confirmed baseline DGD, and hands both immutable inputs to `recipe-deployer`.
 - **Recipe Deployer**: deploys the user-provided baseline DGD or a later challenger-approved DGD and verifies the
   endpoint.
 - **Performance Analyzer**: interprets AIPerf artifacts.

agent-docs/rules/benchmarking/concurrency-grid.md

@@ -14,7 +14,10 @@ Perform a concurrency sweep during benchmarking only if you deem it is necessary
 
 Do not invent an unbounded sweep when the target and benchmark plan provide no safe maximum. Include `c=1` when the
 goal is to characterize the full latency/throughput frontier, but do not add it to a user-constrained set merely to
-complete a curve. Additionally, after selecting a particular concurrency value, keep the selected number of requests to be AT MOST 4x the concurrency. For example, if `c=4`, the number of requests should be at most 4.
+complete a curve. Additionally, after selecting a particular concurrency value, size the request count to AT MOST 4x the
+concurrency (for example, at most 16 requests for `c=4`), and never below the concurrency itself - fewer requests
+than slots cannot even fill the batch, and tiny counts cannot support the noise-floor and comparison rules in
+`comparison-uncertainty.md`. Within that cap, the count must also keep the measurement inside the standard 30-minute window per `comparison-uncertainty.md`.
 
 Use a non-power-of-two point only when it is required by the user workload, needed to reproduce a baseline, selected
 by an AIPerf search method, or chosen as a bounded refinement around an SLO boundary or observed knee. Record the