Compiled <safe-output-tools> can omit custom safe-output tools/jobs

[j-srodka]

Summary

Authors can define custom safe-output jobs/tools, but the compiled <safe-output-tools> section of the prompt / tool description can omit them. The runtime and configuration surface and the compiled instructions shown to the agent can drift apart.

Analysis

The agent is steered by what appears in the compiled prompt/tool description. If custom entries exist in the workflow but not in <safe-output-tools>, behavior is inconsistent: the model may not use tools that are actually wired up, or operators may assume parity between config and instructions when there is none. That pushes consumers toward manual lockfile edits to resync text and reality.

Custom safe-output job present in emitted YAML; same logical tool/job missing from <safe-output-tools> in the compiled markdown/prompt block.

Implementation plan

1. Build <safe-output-tools> from a single internal list that includes default + custom safe-output jobs/tools so emitted instructions match what the workflow exposes.
2. Add a compile-time consistency check (or test) that every user-defined safe-output job/tool has a matching entry in the generated <safe-output-tools> block.
3. If some entries must be hidden, require an explicit source-level opt-out so omissions are intentional, not accidental.

Expected outcome

The compiled prompt/tool description reflects the full safe-output surface the workflow actually provides—no silent drift between config and agent-facing text.