Design & implement self-modifying pipelines (§21)

[AlexChesser]

Summary

Design and implement the ability for pipelines to modify their own definition during execution.

Parent issue: #105 — Tier 4, Priority #19

Why

Self-modifying pipelines enable meta-learning: a pipeline could add steps, adjust parameters, or restructure itself based on observed results. This is an interesting but risky capability — the issue author notes "low trust without strong safety primitives first."

Dependencies

• Safety guardrails (Design & implement safety guardrails (§21) #122) — self-modification without safety constraints is dangerous. Guardrails must be in place before this feature ships.

Design Decisions Needed

• Scope of modification — can a pipeline add/remove steps? Change prompts? Modify its own FROM?
• Modification mechanism — special step type? API? Template-based rewriting?
• Sandboxing — are modifications validated before application? Can they violate guardrails?
• Persistence — do modifications persist across runs? Or only within a single run?
• Audit trail — how are self-modifications recorded in the turn log?
• Rollback — can modifications be undone if they cause failures?
• Fundamental question: is this actually needed, or can the same goals be achieved with loops + conditional flow?

Spec Reference

• Referenced in spec/core/s21*.md as a planned feature

Acceptance Criteria

• Design document / spec section authored addressing safety concerns
• Safety guardrails (Design & implement safety guardrails (§21) #122) are a hard prerequisite
• Modification scope is well-defined and constrained
• All modifications recorded in turn log
• Guardrail violations during self-modification are caught