Project rollout administration

Application administrators need to operate the staging statistics pilot using their signed-in SyRF session. Project selection must eventually be shared durable state, rather than a deployment edit per project. The maintainer also approved reusable project beta enrollment and per-feature releases, without authorizing enrollment or production activation.

Delivery order

1. Statistics operator UI (#3523). Extend Admin Console, reuse the existing server-authorized fleet/backfill/narrow-gate/parity operations, and expose read-only prerequisites and gate state. Select from the deployment allowlist initially. Show each outcome and require backfill before activation; retain the separate parity verdict. Project disable remains available independently of serving flags. A staging preset must identify deployment prerequisites and only change the runtime-manageable Project Overview consumer dependencies after parity. Consumer flags are currently global; label their effect honestly. Acceptance: an administrator can perform the one-project pilot without Swagger or copied tokens; non-administrators cannot operate it.
2. Shared runtime resolution (#3526). Extract and reuse the existing override store/provider across API and Project Management. Preserve precedence, reset-to-default behavior and revision checks; expose per-host convergence and test in-flight writes, restart and store failures. Adapt the staging preset after both hosts run the shared resolver.
3. Durable statistics project eligibility (#3524). Replace deployment-only selection with audited, application-admin-controlled project releases shared by API and mutation hosts. Add project search, enroll/remove controls, revision conflict detection, and explicit effective state. Keep global deployment kill switches and default-off behavior. Prove concurrent enrollment, source writes, disable, re-enable, replica skew and host failures before enabling this path. This is a separate slice, not a client-side wrapper around the static allowlist.
4. Reusable project feature rollout (#3525). Extend the existing flag catalog/store with project beta eligibility, per-feature explicit releases and beta-cohort targeting. Project administrators may opt only their own project into beta eligibility. Application administrators decide which individual features target named projects or the eligible cohort. Enrollment activates nothing by itself. Add staged widening, effective-state explanations, audit history and emergency global disable. Statistics supplies its backfill/parity readiness hook.

The broader feature-flag analysis and redesign are now owned by a separate task. Items 2–4 are handover context, not implementation scope for #3523.

Shared authority and migration

Use the existing feature-flag infrastructure, authorization and audit conventions; do not build a second generic flag store. A future release record identifies feature, target project/cohort, revision, actor and intended state. Beta eligibility is a separate project permission decision. The effective result is the conjunction of global kill switches, an explicit feature release, project eligibility where cohort targeting is used, and the feature's readiness predicate. Both API and background mutation hosts must evaluate the same durable release revision. Client state is presentation only.

The current static allowlist is retained in slice 1. Migration to durable selection must be explicit: no automatic import/enrollment of configured projects and no union that silently leaves a supposedly removed project enabled through a legacy fallback. A deployment selects the authority once; the UI must state which authority is effective. An explicit administrator action can migrate the selected pilot after the new source is deployed consistently. Production remains unchanged.

Correctness boundary for dynamic enrollment

Today IsProjectAllowlisted is synchronous configuration, and source operations may decide to omit statistics before opening their transaction. Merely replacing it with a periodically refreshed list is unsafe: an unlisted operation can commit after enrollment/backfill and leave the newly published projection stale. The new eligibility revision must participate in source admission/publication, including the source-only branch, or activation must have a proven barrier covering all such operations. A cache TTL or a successful parity sample is not that barrier. Reuse existing durable project gates, epochs and transactional fences where possible; add adversarial integration tests. Disabling must fence serving before eligibility is removed, and re-enable must rebuild under the new epoch. This prerequisite is intrinsic correctness, not optional scaling work.

Staging preset and restoration

Writes and family maintenance flags are currently deployment-owned because Project Management does not consume the API's runtime overrides. Preserve that policy until a shared evaluation path is implemented. Show required deployed values on both hosts and identify observations by host/revision; an API-only snapshot must never be presented as proof of writer configuration.

For the screening/Project Overview test, the dependency set is Writes, Serving, Screening, Pages, and ProjectOverview. No annotation, reviewer, StageOverview, SignalR or export flags are required. Backfill and project gate setup precede parity; page serving follows a successful parity check. A preset records the previous override state and the revision it wrote. Restoration uses compare- and-set and refuses conflicting later edits; it must never blindly restore an old entire snapshot. A partially failed preset reports applied steps and leaves a recoverable restore record.

Flag decision

The operator UI and read-only status endpoint need no additional flag: both are application-admin only and existing mutation endpoints enforce the deployed gates. They do not activate anything on load. Dynamic eligibility and reusable targeting need an explicit default-off migration switch and cross-host rollout before use. No existing kill switch is weakened by this plan.

The single-project staging exercise is still the immediate acceptance target. Fleet operations, write-protocol optimization, broad rollout and production activation remain separate work.

Before expanding selection beyond the single-project pilot (#3524), replace the status endpoint's serial per-project repository reads with bounded parallel or batch reads. The current one-project scope does not require that optimization.