test(executor-e2e): upload-build-attachment & upload-pipeline-artifact never exercised — harness emits un-staged NDJSON (missing staged_file) #1421

Summary

In the deterministic executor E2E smoke suite, the upload-build-attachment and upload-pipeline-artifact scenarios both fail to even parse, so these two safe outputs are effectively not smoke-tested end-to-end:

• Build: msazuresphere/AgentPlayground #619303 (executor e2e, 20260708.4)

[FAIL] upload-build-attachment  (Failed to parse upload-build-attachment: missing field `staged_file`)
[FAIL] upload-pipeline-artifact (Failed to parse upload-pipeline-artifact: missing field `staged_file`)

Root cause

These two executors consume the post-staging Result shape, not the agent-facing Params shape. In src/safe_outputs/upload_build_attachment.rs the execute command deserializes UploadBuildAttachmentResultFields, which requires staged_file, file_size, and staged_sha256 — fields the Stage‑1 MCP server injects after copying the agent's file into the safe-outputs dir and hashing it. Stage 3 then reads ctx.working_directory.join(staged_file) and re-verifies the SHA-256.

The E2E harness (scripts/ado-script/src/executor-e2e/scenarios/build.ts) emits only the raw agent Params:

ndjson: async (ctx) => ({
  artifact_name: `ado-aw-det-${ctx.buildId}`,
  file_path: "build-att.txt",
}),

It never replicates the MCP staging step, so staged_file/file_size/staged_sha256 are absent and the executor rejects the NDJSON before doing any real work.

By contrast, upload-workitem-attachment passes because that executor reads file_path directly from ctx.source_directory (src/safe_outputs/upload_workitem_attachment.rs) with no staging indirection — so the harness's Params-shaped NDJSON is valid for it.

Areas for investigation / fix options

1. Harness fix (make the smoke test real): have the build.ts upload scenarios replicate the MCP staging — copy the file into the safe-output dir under a staged_file name, compute file_size + staged_sha256, and emit all three fields in the NDJSON. This makes the two safe outputs actually exercised end-to-end and would have surfaced e.g. debug: upload-pipeline-artifact fails with ContainerWriteAccessDeniedException when uploading to other builds #471.
2. Consistency question: three "upload a workspace file" safe outputs use two different models — upload-build-attachment/upload-pipeline-artifact use a hash-verified staged-file model, while upload-workitem-attachment reads file_path directly (see fix(safe-outputs): add file staging to upload-workitem-attachment #381, which proposes adding staging to workitem-attachment). Decide on a single model, or at minimum document the split and provide a shared harness helper that stages a file for whichever scenarios need it.

Until fixed, treat green-ness of these two safe outputs in the E2E suite as untested, not passing.