Round system redesign: Phases 1-7 complete

Full pipeline/track/stage architecture replacing the legacy round system.

Schema: 11 new models (Pipeline, Track, Stage, StageTransition,
ProjectStageState, RoutingRule, Cohort, CohortProject, LiveProgressCursor,
OverrideAction, AudienceVoter) + 8 new enums.

Backend: 9 new routers (pipeline, stage, routing, stageFiltering,
stageAssignment, cohort, live, decision, award) + 6 new services
(stage-engine, routing-engine, stage-filtering, stage-assignment,
stage-notifications, live-control).

Frontend: Pipeline wizard (17 components), jury stage pages (7),
applicant pipeline pages (3), public stage pages (2), admin pipeline
pages (5), shared stage components (3), SSE route, live hook.

Phase 6 refit: 23 routers/services migrated from roundId to stageId,
all frontend components refitted. Deleted round.ts (985 lines),
roundTemplate.ts, round-helpers.ts, round-settings.ts, round-type-settings.tsx,
10 legacy admin pages, 7 legacy jury pages, 3 legacy dialogs.

Phase 7 validation: 36 tests (10 unit + 8 integration files) all passing,
TypeScript 0 errors, Next.js build succeeds, 13 integrity checks,
legacy symbol sweep clean, auto-seed on first Docker startup.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
2026-02-13 13:57:09 +01:00
parent 8a328357e3
commit 331b67dae0
256 changed files with 29117 additions and 21424 deletions

View File

@@ -0,0 +1,68 @@
# Mixed Round Design Implementation Docs
## Purpose
This folder contains a single consolidated redesign program that intentionally blends:
- Delivery rigor and governance discipline from `codex-round-system-redesign`
- Target architecture depth and runtime detail from `claude-round-system-redesign`
- Award governance semantics from `glm-5-round-redesign` (especially `AWARD_MASTER` and explicit decision modes)
The goal is a complete, production-ready implementation plan for rebuilding round orchestration in MOPC with a full-cutover model.
## Foundation and Blend Strategy
### Foundation
The execution backbone is the `codex` style program model:
1. Contract freeze first
2. Schema/runtime implementation in explicit phases
3. Platform-wide dependency refit (not just feature slices)
4. Mandatory phase gates with hard release blockers
### Borrowed Enhancements
The plan imports high-value details from other proposals:
- `claude`: richer canonical model (`Pipeline -> Track -> Stage`), explicit transition engine, routing and live-control runtime detail
- `glm-5`: award decision governance (`JURY_VOTE`, `AWARD_MASTER`, `ADMIN`) and explicit award track behavior options
## Execution Model
- Single destructive cutover
- Full reseed
- No backward-compatibility adapter layer
- No dual-write period
- One atomic release commit once all gates are green
This model is intentionally selected because infrastructure reset/rebuild is allowed and preferred for architecture quality.
## Architecture Summary
- Competition lifecycle is stage-native, not round-pointer native.
- Projects progress through explicit `ProjectStageState` records.
- Special awards are first-class tracks, not bolt-on side tables.
- Routing is rule-driven with explainability payloads.
- Live finals are controlled by an admin cursor as the source of truth.
- Every override and decision is reasoned, immutable, and auditable.
## Folder Layout
- `master-implementation-plan.md`: end-to-end execution map
- `shared/`: cross-phase contracts, governance, test model, risks
- `phase-00-contract-freeze/` to `phase-07-validation-release/`: implementation phases
- `flowcharts/`: core control and routing diagrams
## How to Use This Plan
1. Start at `master-implementation-plan.md`.
2. Execute phases in order.
3. Do not start a phase unless all prior acceptance gates are complete.
4. Attach objective evidence for every gate.
5. Treat `phase-06-platform-dependency-refit` as mandatory release work, not cleanup.
## Non-Negotiable Rules
1. No hidden edit-only required settings.
2. Deterministic routing and ranking tie-break behavior.
3. Assignment coverage guarantees for eligible projects.
4. Explicit voting window control (schedules are advisory only).
5. No legacy orchestration contract references at release.