69 lines
2.7 KiB
Markdown
69 lines
2.7 KiB
Markdown
# 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.
|