What problem does it solve?
Polyphony SDLC runs require a consistent, deterministic Git branch topology so planning, merge-group promotion, PR ordering, and evidence capture can be enforced without brittle, type-specific logic.
Core Features & Use Cases
- Defines the canonical branch tree for a run, including
feature/, plan/, mg/ (top and nested), impl/, and evidence/ branch naming and placement.
- Specifies promotion and merge-chain rules (head/base relationships, mandatory merge commits at key layers, and driver-enforced gates based on requirement state).
- Guarantees stable merge-group identity via planner-declared MG ids and immutable topology inputs recorded in a run manifest (
.polyphony/run.yaml).
- Handles renegotiation and concurrency safely through parent-plan generations, stale PR blocking with auditable rebase or human gates, and ancestor restack protections.
- Manages cross-sibling code dependencies by applying policy-driven remedies like promote-and-rebase and recording rebase events to prevent silent topology drift.
Quick Start
Use the polyphony-branch-model skill when authoring or reviewing branch-creation logic for a polyphony SDLC run to ensure your branch names, merge gates, and PR topology follow the Rev 4 rules.