[agent-issue]: target: 1es needs configurable 1ES template wrapper, SDL pool, and network isolation settings #2270

Submission requirements

• I generated this issue with an agent that used .github/agents/ado-aw.agent.md.
• I reviewed the generated issue and confirm it is being filed directly in githubnext/ado-aw.

Problem summary

Some Azure DevOps organizations require every pipeline to extend a 1ES Pipeline Template, often through an organization-owned wrapper template. In those environments, target: standalone is not allowed, while target: job / target: stage must be included under an existing 1ES parent template.

target: 1es is the closest fit, but today it emits a fixed 1ES shape that cannot be adapted to those org requirements without hand-editing the generated lock file. Hand edits then fail ado-aw check, so the workflow is no longer reproducible or mergeable.

Verified defaults in the current 1ES target:

There is also a related embedding gap: target: job / target: stage emit inline - publish: steps (lower_publish), while only target: 1es sets templateContext and lifts Step::Publish into templateContext.outputs (lower_job_steps). Some 1ES parent templates reject inline publish steps in included templates.

Reproduction details

1. Create any workflow with target: 1es.
2. Run ado-aw compile <workflow.md>.
3. Inspect the generated YAML:
   • resources.repositories[0] is always 1ESPipelineTemplates/1ESPipelineTemplates at refs/heads/main with alias 1ESPipelineTemplates.
   • extends.template is always v1/1ES.Unofficial.PipelineTemplate.yml@1ESPipelineTemplates.
   • extends.parameters.sdl.sourceAnalysisPool is always name: AZS-1ES-W-MMS2022, os: windows.
   • extends.parameters.featureFlags.disableNetworkIsolation is always true.
4. Queue the pipeline in an org that requires an org wrapper template and does not provide the default SDL source-analysis pool.
5. Template or pool validation fails before the generated Agent / Detection / SafeOutputs jobs can run.
6. If the generated lock file is hand-edited to use the org wrapper and SDL pool, ado-aw check <pipeline.lock.yml> fails because the checked-in lock no longer matches compiler output.

Expected behavior: front matter can select the 1ES template repository/ref, template path, SDL source-analysis pool, and network-isolation/template settings while preserving deterministic lock generation and ado-aw check.

Observed behavior: only the built-in 1ES Unofficial template shape is expressible.

Sanitized field evidence: a pilot successfully ran the Agent → Detection → SafeOutputs chain inside an existing 1ES-extended pipeline after manually embedding a compiled stage target into the parent wrapper, disabling the integrity check, and using pre-staged AWF/MCPG images with --skip-pull because public registries were blocked. That suggests the agentic workflow graph can run under an org-approved 1ES wrapper and network-isolation policy, but the current compiler cannot generate that supported shape. supply-chain.registry addresses the image-mirroring part, not the 1ES wrapper/pool/settings part.

Proposed next step

Add an optional, backward-compatible onees: (name flexible) front-matter block valid only with target: 1es. When omitted, generated YAML should remain unchanged. The block could populate the existing 1ES IR/lowering path plus validated pass-through parameters, for example:

target: 1es
onees:
  template:
    repository:
      alias: 1ESPipelineTemplates
      name: Example/Templates
      ref: refs/tags/release
    path: v1/Example.Wrapper.PipelineTemplate.yml
  sdl:
    source-analysis-pool:
      name: ExampleWindowsPool
      os: windows
      image: windows-latest
  feature-flags:
    disable-network-isolation: false
    run-prerequisites-on-image: false
  extra-parameters:
    settings:
      networkIsolationPolicy: example-policy

Suggested implementation / owner area:

• Front matter/types: add a typed 1ES configuration block and validate it is only used with target: 1es.
• IR/lowering: replace the hard-coded template repo/path/ref, SDL source-analysis pool, and feature flags with configured values while preserving current defaults.
• Pass-through guardrails: allow org-wrapper parameters such as settings, but reject compiler-owned keys (stages, pool, sdl.sourceAnalysisPool, and featureFlags when set through typed fields) so pass-through cannot alter the generated job graph or trust boundary.
• Documentation: update docs/targets.md, docs/front-matter.md, and the trust-boundary note to explain that a custom 1ES wrapper runs org-owned steps around the generated jobs.
• Tests: cover byte-identical default output, each new field, reserved-key rejection, ado-aw check round-trip, and compatibility with supply-chain.registry.

As a follow-up, consider allowing target: job / target: stage to opt into 1ES-style templateContext.outputs lowering so generated templates can be included in an existing 1ES-extended parent without inline - publish: steps.