docs(m2): close milestone and advance status - #28
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4297ed055f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| ## Status | ||
|
|
||
| Active | ||
| Completed |
There was a problem hiding this comment.
Keep M2 active until the release gate is satisfied
This marks M2 as completed even though its own release gate requires the v0.0.3 release to be tagged after merge (docs/milestones/M2-local-paired-comparison.md:181-188), and the repository currently contains no such tag. The project-wide completion policy likewise requires the associated release to exist when applicable (docs/milestones/README.md:95-104), so leave the status active until the release is created or revise the gate before declaring completion.
Useful? React with 👍 / 👎.
| ## Project Status | ||
|
|
||
| Current milestone: **M0 — Project Foundation** | ||
| Current milestone: **M3 — Statistical Evidence Engine** |
There was a problem hiding this comment.
Prepare the M3 specification before making it current
Declaring M3 current conflicts with the repository's milestone state: a repository-wide file search finds specifications only for M0–M2, while the planning policy requires the active milestone to have a complete committed specification (docs/milestones/README.md:71-77), and the M1 specification still declares itself Active. Either add and activate an M3 specification while reconciling the older status, or avoid advancing the README yet.
Useful? React with 👍 / 👎.
Problem
What situation existed before this change? Why did it need to change?
Change
What did you actually do? Summarize the change, not the diff line-by-line.
Design Decisions
Any non-obvious choices made while implementing this — trade-offs, rejected
alternatives, or anything a future reader would ask "why did you do it this
way?" about.
Validation
pytestpassesruff check .passesmypy srcpassesRisks
What could this break? What wasn't tested? What assumptions might not hold
for other inputs or backends?
Related