Evaluate Ponytail simplicity lens for deep-planning-codex

[dachent]

Recommendation

Evaluate adding a bounded Ponytail/Pony simplicity lens to deep-planning-codex as an optional review step, not as an always-on orchestrator mode.

Why

deep-planning-codex intentionally adds durable artifacts, proceed gates, verification plans, and adversarial review. Those controls are useful, but the workflow can still drift into over-planning or over-engineered execution plans. A Ponytail-style pass would ask whether the plan can be deleted, collapsed, replaced with stdlib/native behavior, or implemented with fewer files/dependencies before execution begins.

Suggested shape

• Add an optional Simplicity Review phase after design synthesis or before adversarial review.
• Use it mainly for software-git, software-no-git, and mixed-business-coding modes.
• Output either .deep-planning/simplicity-review.md or a section inside .deep-planning/adversarial-review.md.
• Treat findings as advisory unless they identify speculative implementation steps, unnecessary dependencies, avoidable abstractions, or a smaller verification-equivalent plan.
• Keep the existing deep-planning safety controls: do not remove trust-boundary validation, data-loss handling, security, accessibility basics, required evidence, or proceed gates.

Acceptance criteria

• The orchestrator documentation describes when to invoke the Ponytail lens and when not to.
• The phase does not replace verification-plan-codex or adversarial-plan-review-codex.
• The output contract names concrete simplifications with replacement guidance and expected risk/tradeoff.
• Forward testing covers at least one overbuilt plan where the lens reduces scope and one high-risk plan where it does not remove required safety work.

Open question

Should this be implemented as a dependency on a future ponytail-review-codex companion skill, or as local fallback behavior inside deep-planning-codex when Ponytail is unavailable?