execute-phase

Point the skill at a plan file (default: latest plans/phase-plan-*.md) and it runs preflight git checks, parses the lane DAG and owned files, then implements each lane in topological order with verification. Use --dry-run to preview the lane schedule without editing.

Each lane declares owned-file globs that act as the write contract; the executor stops if implementation requires touching another lane's files. Parallel worker fanout is allowed only when lanes are machine-verified disjoint, using scripts like audit_lane_file_touches.py to detect peer intrusions.

Yes, but only when the user explicitly requests parallel execution and the DAG-ready lanes are disjoint. Workers receive exact owned files, read-only interfaces, and worktree assignments, while the main thread integrates results and runs final verification.

The executor diagnoses the failure once and fixes it within the lane if the cause is local; otherwise it stops with a typed blocker such as repeated_verification_failure. A closeout reporting success requires a runner-owned verification artifact supporting the executed work.

The closeout audit classifies every dirty git path as phase-owned, control, pre-existing, or unowned. Unowned generated files, unknown ignored outputs, or unrelated user changes overlapping lane files block completion until they are committed, isolated, or resolved.

Yes, manual standalone runs remain valid for local phase plans without Pipeline metadata. When a canonical .phase-loop/ runtime state exists it is treated as authoritative, but the skill preserves standalone behavior for manual dotfiles use.