fix(#4539): surface artifact contract in spawn prompt

[jm27]

Problem

Issue #4539: an artifact-mode task declares a full contract (kind, output_path, acceptance criteria) but the spawn prompt never surfaces it. Agents only learn the contract from operator free-text; when that's skipped, completion fails on criteria the agent never saw.

Fix

Adds a shared render_artifact_contract(tasks) helper that renders the kind, the exact output path the verifier reads, and every declared criterion. It reads the same task.artifact_spec object and the same artifact_output_path / is_artifact_mode resolvers as the completion path, so prompt and verifier cannot drift (no second parse).

Wired into both render paths:

• spawner_core._render_prompt_with_receipt (the live production path)
• spawn_prompt._render_prompt (kept in sync per that file's convention)

Gated so a code_diff batch's prompt is byte-unchanged.

Closes #4539.

Tests

Three new tests in tests/unit/agents/test_artifact_contract_prompt.py:

1. test_artifact_task_prompt_names_kind_path_and_criteria
2. test_code_diff_task_prompt_is_unchanged
3. test_prompt_and_verifier_consume_the_same_spec_object

All pass (pytest tests/unit/agents/test_artifact_contract_prompt.py → 3 passed). Existing prompt-coherence tests unchanged (29 passed). Ruff clean.

[chernistry]

Reviewed against the code — this is right, and right for the reason that matters: the prompt and the verifier read the same artifact_spec through the same artifact_output_path / is_artifact_mode resolvers, so there is no second parse to drift. That is the part that would have rotted if the contract had been re-rendered from its own copy of the spec.

Checked the two things worth checking:

• spawner_core._render_prompt delegates to _render_prompt_with_receipt (spawner_core.py:1430–1439), so the test assembles the live production path rather than a parallel one. The assertion artifact_output_path(task) in prompt is what makes it a real test and not a string check.
• The gate is on is_artifact_mode, which resolves through artifact_spec.kind and defaults to code_diff, so an ordinary coding task's prompt is byte-unchanged — covered by test_code_diff_task_prompt_is_unchanged.

One thing you may be wondering, since the PR touches both render paths: only the spawner_core path is exercised by the tests. That is fine as it stands — spawn_prompt._render_prompt is kept in sync by that file's own convention and nothing spawns through it in production. No change requested.

Approved, auto-merge armed. It will enter the merge queue once the 3.13 shards finish.

If you want another one in the same area: #4571 — the agent timeout extension never reaches the spawned process. It is fully diagnosed and small:

• tuning.orchestrator.max_agent_runtime_s does reach OrchestratorConfig.max_agent_runtime_s (core/models.py:1603, default from _default_max_agent_runtime_s at models.py:44).
• Its only consumer is the extension logic at core/agents/agent_lifecycle.py:2834.
• Every real adapter.spawn(...) call site omits timeout_seconds, so adapters/base.py:42 DEFAULT_TIMEOUT_SECONDS = 1800 arms the threading.Timer instead. The configured value cannot take effect no matter what an operator sets.

The slice: thread the resolved runtime into the spawn calls so the Timer is armed from config. Proven by a test that spawns with a non-default max_agent_runtime_s and asserts the adapter received that timeout — not by reading the config back. Out of scope: the extension logic itself, and any change to the 1800 s default for callers that pass nothing.

I have assigned it to you. If it turns out bigger than it looks, say so in the thread and I will slice it further.

[chernistry]

Shard 4 was red on test_lessons.py, not on your change's logic: those two tests build their task with a bare MagicMock, so is_artifact_mode saw a Mock instead of code_diff and the renderer went looking for an output path. Pushed a commit to your branch giving the mock an ArtifactSpec() — the mock already enumerates every field the renderer reads, this adds the one it started reading. CI is re-running.

Worth knowing for next time: your first push sat for a few hours with no checks at all. That is the first-time-contributor workflow gate, not your PR — a maintainer has to release each run. Ping me here if it happens again and I will clear it.