parallel-feature-managers

Topics in the source

• Parallel feature managers
• Models: cross-vendor panels are a correctness rule, not a preference
• Hard rules
• 1. Establish the feature matrix
• 2. Make private repository context available
• 3. Create manager and reviewer personas with policy first
• 4. Seed channels and launch managers
• 5. Monitor without taking over

Use the live Cotal mesh as a hierarchy: The current session is the coordinator. It creates isolation, sets policy, monitors progress, and relays decisions. It does not duplicate implementation or panel review. Each feature gets one manager rooted in its own Git worktree and branch. The manager owns the complete plan -> implementation -> review -> test -> commit loop. Each manager spawns three or more read/review-only peers in one dedicated channel: engineer, security, and critic at minimum. Near the final gate, each manager adds one independent cold reviewer, briefed under the cold-review skill, which is the single source for how that seat is briefed, isolated and graded. It is a control on the panel rather than a fourth panelist. No two seats whose agreement is load-bearing may share a model family. A finding confirmed by a seat of the same family as the one that made it is an echo, not a confirmation. A panel of three same-model reviewers has approved a head carrying a defect that all three missed, and what surfaced it was a differently framed read rather than a fourth verifier. State it that way rather than as a headcount. Availability is a property of the moment, not of the ven

This is an excerpt. Refer to the complete source and its current requirements.