Construct usable increments across fixed approval gates

Repair release-plan.json; time is elapsed days. Teams: alpha available 0–9, capacity 8 work-days; beta 0–9, capacity 4. Each team does one work item at a time. Features (id: duration,value; predecessor; gate): registration:2,4;none;privacy. checkout:3,6;registration;payment. bulk:3,8;checkout;warehouse. metrics:2,3;registration;privacy. audit:2,0;registration;privacy. Retain finish-to-start work dependencies and full durations. Fictional gate evidence (gate:owner,ref,available day): privacy:privacy-owner,P1,1; payment:payment-owner,PAY4,4; warehouse:site-owner,WH8,8. A gate record must use its exact owner/ref at or after evidence availability. Building may precede gates; release may not. work rows: feature,team,start,finish. approvals rows: gate,owner,evidenceRef,at. releases rows: id,at,features (new feature IDs). Include a feature only once across releases; a dependency must be usable in the same-time bundle or an earlier release. Usable means completed work and evidenced gates by release, with its prerequisites usable. Finished but unreleased features have no value yet; an invalid early release does not become valid merely as time passes. Deliver at least 10 usable value points by day 5 and 21 by day 9. Transition all five features by day 9, including zero-value audit. report: checkpoints rows {at,usableValue} for 5 and 9, firstValueDay (earliest positive usable release or null),finalValue,releaseCount. Count each feature's value once and each release record once. Row order and release IDs do not matter; same-day bundles reconcile together. A two-release checkout-first plan and an earlier discovery increment followed by checkout can both work. Save, rerun and repair without Reset.