docs: add planning and release model - #147
Conversation
A single version-controlled source for how PharmaPy-org/PharmaPy plans work and cuts releases: operating model, release-risk policy, the first milestone (0.1.0a1) with scope mapped to open PRs, Project changes, and a lazy-consensus decision log. Draft for discussion; adopts nothing until merged.
Mazhar331
left a comment
Mazhar331
left a comment
There was a problem hiding this comment.
Maintainer review of PLANNING.md at 2579641. Thanks for writing this down — the operating model, the severity gate in §4, and the decision log are the right shape for a team this size, and I verified §2 claim by claim rather than taking it on trust. Almost all of it holds exactly (details below).
The one thing that blocks merge is not the content of the policy but what the file says about itself once it is on master.
Blocking
1. The draft banner and the PR-freeze paragraph become false and permanent on merge, and §9 defines no step that removes them.
Lines 3–13 declare Status: DRAFT PROPOSAL — under discussion in this pull request. Not yet adopted. and Nothing here is policy until this PR is merged. Lines 46–52 instruct readers to hold new or unrelated pull requests for a one-week objection window. §9 says "On merge, this document becomes the reference" but lists only how §3–§6 graduate into other artifacts; nothing removes the banner or the freeze.
The result on master is a document that simultaneously declares itself unadopted and is the adopted reference, and that instructs every future reader — including someone arriving in six months — to freeze unrelated PRs against a window whose start date is not recorded in the file. There are ten open PRs right now, six of them correctness fixes (#102, #106, #107, #114, #115, #126); a durable freeze instruction is a real cost to leave lying around.
Either fix works:
- Add an explicit §9 first step: on merge, replace the banner with
Adopted YYYY-MM-DDand delete §1's freeze paragraph. Then this PR is merged only together with that edit, or the edit is the merge commit. - Better: keep the freeze request and the objection window out of the file entirely — they belong in the PR body and a tracking issue — and let
PLANNING.mdcarry only the durable policy. §7 can state the ratification mechanism (lazy consensus, one-week window) without pinning a specific in-flight window.
Inline comments carry the rest of the detail.
Nonblocking
- §5's scope table is already stale: #136 merged at 2026-07-28T18:50Z, after this PR's last update (16:03Z), so this is drift rather than an authoring error — but §5 is written to be pasted verbatim into the milestone description, so it propagates. Details inline (line 145).
- §2's
85 open issuesis now 86, and the snapshot predates #146 (created 2026-07-27T19:06Z) which §5 and §7 D2 both cite. Inline (line 59). - §6's "Immediate data fixes" are one-shot tasks in a durable file — once done they stay permanently unchecked in git. Inline (line 220).
- §8 Q1 and §5's exit criteria re-open questions that
TESTING.mdonmasteralready answers. Inline (line 253).
Questions
- D7 (release manager) cannot be ratified by the mechanism §7 defines — silence names nobody, yet §4's promotion gate depends on it. Inline (line 236).
- How does this relate to PR #132 (
AGENTS.md)? Both PRs introduce a canonical policy document and neither references the other. Inline (line 274).
§2 verification (read-only, GitHub + repo, 2026-07-28)
Everything below was re-queried independently. Confirmed exactly as written:
- No milestones (0), no releases (0), no tags (0);
pyproject.tomlversion = "0.0.1",requires-python = ">=3.9". - Open-issue labels: 62
correctness, 60status:verified, 1severity:critical, 34severity:high, 20severity:medium, 3severity:low. - Severity coverage: exactly 4 open
correctnessissues carry no severity (#17, #67, #140, #141) → 58 of 62 covered; 0 severity-labelled issues lackcorrectness. Both halves of the claim hold. - #68 is the sole
severity:critical. - Epics #3, #17, #67, #118 are native issue-type
Epic(not just theepiclabel) — the §3 claim is precise. - CI:
Core testspinspython-version: "3.11";Assimulo integration testsiscontinue-on-error: true;master(bbd7b9a) is green on all four checks. - DOI
10.1016/j.compchemeng.2021.107408resolves via Crossref to the 2021 Computers & Chemical Engineering paper. - §4's parenthetical is accurate: PR #106 adds
tests/test_crystallizer_energy_balances.pywith exactly four regression tests, one per sub-defect. - §5's issue↔PR mapping is right: #114 ↔ #23 (reversible Jacobian), #115 ↔ #26 (BatchCryst Jacobian sign), #135 ↔ #134, #131 ↔ #130, #146 is open and is the distribution-name reservation.
pharmapy-simis not registered on PyPI (404) whilePharmaPyis taken by an unrelated project (200) — so §5's and D2's "recheck the name before publishing (#146)" is the correct posture, and the window it warns about is real.- All ten TOC anchors resolve to real headings.
Not verified: the Project #1 claims (created 2026-07-21, Priority mirroring Severity, Size 0-of-85, only #23/#26/#134 in an iteration). A ProjectsV2 read needs the read:project token scope, which my token lacks. Worth noting in §2 who can re-run that query, since §6 asks the team to act on it.
Other checks
- Changed-file set:
PLANNING.mdonly, +279/−0. Local diff frommerge-base 4c2d8eamatchesgh pr diff --name-only. - No whitespace errors (
git diff --check); file is UTF-8, LF, no EOL churn (new file). - PR head CI (
2579641):Core testssuccess,Assimulo integration testssuccess. The twoLocked pixi installjobs do not appear because the head predates #136; they are green onmaster. - Merge result:
git merge-tree --write-tree origin/master 2579641is conflict-free against the advanced base (bbd7b9a). A docs-only addition, so no build or test impact. masteris unprotected (branches/master/protection→ 404), so no approving-review count or conversation-resolution gate is enforced.
I would not merge this until the blocking issue above is addressed.
| formalizes *that*, and deliberately avoids ceremony (sprints, mandatory | ||
| estimates, blocking committee gates) that a team this size will not sustain. | ||
|
|
||
| **Finalizing this document is the team's current top priority.** While it is |
There was a problem hiding this comment.
Blocking — this paragraph, together with the Status: DRAFT PROPOSAL … Not yet adopted. banner at the top, is written from inside the review window and stays in the file after merge.
Once this lands, master carries a document that says it is not yet adopted while §9 says it is the reference, and that tells every future reader to hold unrelated PRs — with no start date recorded, so the "one week" never expires for someone reading it later. Ten PRs are open right now; six are correctness fixes (#102, #106, #107, #114, #115, #126).
Concretely, I would move the whole freeze request and the specific objection window out of the file and into the PR body plus a tracking issue, leaving §7 to state only the mechanism (lazy consensus, one-week window from the ratification announcement). If you would rather keep it here, then §9 needs a first step that is unambiguous, for example:
On merge (before anything else): replace the DRAFT banner with
Adopted YYYY-MM-DD, delete §1's PR-hold paragraph, and open the ratification issue that starts the objection window.
Either way the file that ends up on master should be true about its own status.
There was a problem hiding this comment.
Addressed in cb2c963. I removed both the draft banner and the complete
PR-hold paragraph from PLANNING.md. The durable status now says the document
is repository policy when present on the default branch. The transient
ratification request and exact 2026-07-29T13:59:19Z →
2026-08-05T13:59:19Z window live only in the PR body; §7 retains the general
lazy-consensus mechanism and explains why the window spans one full workweek.
The current-head GitHub render and all four CI checks pass.
There was a problem hiding this comment.
Current-head confirmation at 488ded5: the durable default-branch status and
removal of the permanent PR freeze remain unchanged. The new assignment,
maintenance, and version-term clarifications do not reintroduce transient
review state into PLANNING.md; all four CI checks pass.
There was a problem hiding this comment.
Current-head confirmation at 511f705: the durable adopted-on-merge status
remains intact, and all transient hold/window text remains confined to the PR
body. The follow-up only refreshes data and improves policy wording.
| Queried read-only from GitHub on 2026-07-27. **Time-sensitive** — re-verify | ||
| before acting on any count. | ||
|
|
||
| - 85 open issues; **no milestones, no releases, no Git tags**; `pyproject.toml` |
There was a problem hiding this comment.
Nonblocking — two small drifts in the snapshot.
85 open issues is 86 as of today. More interestingly, the count predates #146, which was created 2026-07-27T19:06Z and which this document cites in both §5 and §7 D2 — so §2 and the body were captured at different points on the same date.
Everything else in §2 I re-queried and it holds exactly, including the parts that are easy to get subtly wrong: 4 correctness issues without severity (#17, #67, #140, #141) and zero severity-labelled issues that are not correctness.
Suggest a timestamp rather than a bare date, since the section is explicitly time-sensitive:
| - 85 open issues; **no milestones, no releases, no Git tags**; `pyproject.toml` | |
| Queried read-only from GitHub on 2026-07-27T19:30Z. **Time-sensitive** — re-verify | |
| before acting on any count. |
(Adjust to the real capture time.) Separately: I could not verify the Project #1 bullet below — a ProjectsV2 read requires the read:project token scope. Since §6 asks the team to act on those numbers, it is worth saying in §2 who can re-run that query.
There was a problem hiding this comment.
Addressed in cb2c963. I re-ran the issue, label, milestone, release, tag, and
Project queries at 2026-07-29T13:54:25Z; the snapshot now reports 86 open
issues and retains the independently confirmed severity counts. The section
names both REST and GraphQL as its sources and states that Project #1
re-verification requires organization access plus read:project. The
ProjectsV2 query succeeded in this pass and confirmed 85 items, no populated
Size values, and the three iteration assignments.
There was a problem hiding this comment.
Current-head confirmation at 488ded5: §2 remains an explicitly timestamped
REST/GraphQL snapshot with the read:project requirement. The new maintenance
contract additionally forbids advancing that timestamp unless every snapshot
claim is re-queried in the same pass.
There was a problem hiding this comment.
Refreshed again at 511f705 in one REST/GraphQL pass. §2 now records
2026-07-30T14:29:55Z, all 86 open issues are in Project #1, and the documented
label, Size, Priority, and iteration counts match that same pass.
| | #68 | PR **#106** | The critical crystallizer crash + enthalpy basis (hard gate). | | ||
| | #134 | PR **#135** | Solver-free model imports (lazy Assimulo). | | ||
| | #130 | PR **#131** | Reproducible, public documentation (tracked as the outcome; #131 is one step and intentionally does not close #130). | | ||
| | packaging / clean install | PR **#136** | `pharmapy-sim` distribution, pixi environments, install guide, two-platform locked install matrix. Recheck the distribution name before publishing (#146). | |
There was a problem hiding this comment.
Nonblocking — #136 merged at 2026-07-28T18:50Z, after this PR was last updated (16:03Z), so this is ordinary drift and not an authoring error. It still matters because §5 is explicitly written to be pasted verbatim into the milestone description, so the stale row propagates into GitHub.
Two knock-on effects at current master (bbd7b9a):
- The exit criterion "A clean environment installs the package (pip and pixi), verified by a smoke-install/import job" is already satisfied —
Locked pixi install (ubuntu-latest)and(windows-latest)are gating checks, andINSTALLATION.mdnow exists. - §1's request that Add pharmapy-sim distribution, pixi environments, and install guide #136 "continue to merge" is moot.
The general point: §2 flags itself as time-sensitive, but §5's Delivered by column hard-codes the same kind of mutable state without that caveat. PRs merge; issues are stable. Consider keying the table on issues and treating the PR column as a dated snapshot, with a one-line note to that effect above the table.
There was a problem hiding this comment.
Addressed in cb2c963 after merging current master (bbd7b9a). The scope
table is now keyed to durable issues, labels PR implementation state as a dated
snapshot, and records #136 as merged. The clean-install exit criterion is
checked with references to the Linux/Windows locked-install jobs,
INSTALLATION.md, and TESTING.md; #136 is also gone from the PR body's
in-flight exception list.
There was a problem hiding this comment.
Current-head confirmation at 488ded5: milestone scope remains keyed to issues,
PR implementation state remains a dated snapshot, and #136 remains recorded as
merged with the clean-install criterion satisfied.
There was a problem hiding this comment.
Current-head confirmation at 511f705: scope remains keyed to durable issues,
§5 carries the refreshed implementation timestamp, #136 remains recorded as
merged, and the clean-install criterion remains satisfied.
|
|
||
| **Immediate data fixes** (independent of the decisions): | ||
|
|
||
| - [ ] Put #68 into active focus — it is the only hard release blocker. |
There was a problem hiding this comment.
Nonblocking — these two are one-shot operational tasks, not policy. Once someone does them, the boxes stay unchecked in git forever and read as outstanding work to the next person who opens the file.
Same concern, milder, applies to §5's entry/exit checkboxes — though those are defensible since the section is meant to be copied into a milestone description where they will get checked.
Suggest moving both to the tracking issue (or straight onto #68 and #134) and leaving §6 with just the durable Views/Fields/Automations policy.
There was a problem hiding this comment.
Addressed in cb2c963. I removed both one-shot checkboxes from §6. The durable
policy now says operational state is maintained on its owning issue: #68 owns
hard-blocker status, and #134 owns its assignee and Project status. The
milestone entry/exit checklist remains because §5 explicitly generates the
milestone description where those boxes are updated.
There was a problem hiding this comment.
Current-head confirmation at 488ded5: §6 still contains no one-shot
operational checkboxes. The new assignment clarification reinforces that live
ownership and handoffs are maintained on milestone issues and in Project
status, not duplicated as durable-file tasks.
| | **D4** | Priority model | Re-triage independently of severity (or collapse to `Now/Next/Later`) | Yes | maintainer | | ||
| | **D5** | `Size` field | Not required; optional for near-term items only | Yes | team | | ||
| | **D6** | #23/#26 in this release? | No unless the owner confirms they ship here | Yes | issue owner | | ||
| | **D7** | Release manager | Name one person; they decide high→blocker promotions | Yes | org | |
There was a problem hiding this comment.
Question — D7 is the one row that lazy consensus cannot resolve. Every other decision has a concrete proposed default that silence ratifies; this one's default is a restatement of the decision ("Name one person"), so a week of silence produces no release manager.
That matters because §4's promotion rule — the core of the release-risk policy — has no actor without it: "A named release manager decides promotions."
Could you either name a person in the default, or give a fallback rule that silence can ratify, e.g. "the milestone owner acts as release manager unless someone else volunteers"? Also worth reconciling the Owner column: D7's owner is org, but the decision it produces is what makes §4 executable.
There was a problem hiding this comment.
Addressed in cb2c963. D7 now has a concrete default that silence can ratify:
the maintainer who creates the milestone acts as release manager unless the
milestone names another volunteer. Its owner is now maintainer, so the
default and §4's promotion authority are executable without a separate naming
decision.
There was a problem hiding this comment.
Current-head confirmation at 488ded5: D7 retains the ratifiable milestone
creator fallback and maintainer owner. The assignment clarification now uses
that named release manager as the person responsible for unowned milestone
work and current issue/Project ownership.
There was a problem hiding this comment.
Current-head confirmation at 511f705: D7 still names the milestone creator as
the default release manager unless the milestone names another volunteer, so
silence yields an executable owner.
|
|
||
| These need a human decision; do not invent answers. | ||
|
|
||
| 1. **Smoke/validation suite.** What is the minimal numerical/smoke suite whose |
There was a problem hiding this comment.
Nonblocking — TESTING.md on master already answers a good part of Q1, and this section reads as if it were an open design question.
It documents the concrete lanes (python -m pytest tests/ -m "not assimulo", pixi run test, pixi run -e assimulo test-assimulo), states that GitHub Actions gates the locked pixi install on Linux and Windows, and states that the Assimulo job is "intentionally informational" — which is exactly the blocking-versus-non-blocking distinction §4 and §5 need.
Reframing Q1 as "which of TESTING.md's existing lanes gate the release, and what numerical assertions do we add on top?" makes it answerable, and it avoids §5's exit criteria silently forking from the file that actually documents the test lanes. DEPENDENCIES.md is likewise the natural home for the "dependency policy is explicit" exit criterion. Neither file is referenced anywhere in this document.
There was a problem hiding this comment.
Addressed in cb2c963 against the post-#136 base. Q1 now starts from
TESTING.md's existing core pytest, locked pixi, and informational Assimulo
lanes and asks only which lanes gate the release and which numerical assertions
must be added. The exit criteria link DEPENDENCIES.md as the source for bounds
and environment policy and link INSTALLATION.md/TESTING.md for the completed
clean-install criterion.
There was a problem hiding this comment.
Current-head confirmation at 488ded5: TESTING.md, DEPENDENCIES.md, and
INSTALLATION.md remain the authoritative detailed sources. The new text is
limited to assignment maintenance and PEP 440 terminology.
There was a problem hiding this comment.
Current-head confirmation at 511f705: TESTING.md, DEPENDENCIES.md, and
INSTALLATION.md remain the detailed sources. Q1 now consistently calls the
still-to-be-defined gate the “release test suite.”
|
|
||
| - §4 (release-risk policy) and §5 due-date/hygiene → the durable content of a | ||
| future `RELEASING.md`. | ||
| - §3 (operating model) → the basis of `CONTRIBUTING.md` / the Project README. |
There was a problem hiding this comment.
Question — how does this document relate to PR #132, which adds AGENTS.md as "the canonical repository vision and coding policy" and states that it documents "issue/PR coordination"?
Two policy documents are in flight, each presenting itself as canonical, and neither references the other. §9 here proposes graduating §3 into a CONTRIBUTING.md that does not exist yet, while #132 is landing a policy file that arguably already occupies part of that space.
A clean split would be: AGENTS.md = how code is written and verified; PLANNING.md = how work is planned, prioritized, and released; CONTRIBUTING.md (later) = the contributor-facing summary pointing at both. Whichever of #132 / #147 merges second should add the cross-reference. Worth settling before either lands, so the repo does not end up with two documents claiming the same authority.
There was a problem hiding this comment.
Addressed in cb2c963. The opening status block and §9 now define the split
explicitly: PLANNING.md owns planning, prioritization, and releases; PR #132's
proposed AGENTS.md owns coding and verification rules; a future
contributor-facing CONTRIBUTING.md summarizes and points to both instead of
duplicating either.
There was a problem hiding this comment.
Current-head confirmation at 488ded5: the PLANNING.md/proposed AGENTS.md
authority split remains explicit. The new maintenance section stays within
PLANNING.md's planning, prioritization, and release scope.
There was a problem hiding this comment.
Updated at 511f705 for the live state: PR #132 has merged, so both the opening
status block and §9 now state that AGENTS.md owns coding and verification
rules while PLANNING.md owns planning, prioritization, and releases.
bernalde
changed the title
|
Addressed the maintainer review on current head Changes
Verification
All seven reviewer threads have current-head replies below and remain unresolved |
andres9403
left a comment
andres9403
left a comment
There was a problem hiding this comment.
In general, I really like that this document makes the refactoring and release plan explicit. It gives the team a clearer source of truth instead of relying on scattered GitHub state.
I have a few comments/questions:
For me it is not fully clear if the PR or issue assignments for the milestone will live. Will assignments be listed in PLANNING.md, It may help to state who is responsible for assigning work and keeping that assignment current.
Since PLANNING.md is described as a living planning record, I think it would help to define how it is maintained: who updates it, when it should be refreshed, and whether updates happen before each milestone/release, on a fixed cadence, or only when planning decisions change.
The versioning proposal is useful, but some of the nomenclature may not be obvious. Terms like 0.1.0a1 or rc1, releases, maybe need an explanation.
|
Addressed the new body-only review from Changes
Verification
The new review contained no inline targets, so its three body-only findings are |
|
Read-only verification pass over head Round 1 (my review) — all seven addressed
Round 2 (@andres9403) — all three addressed
New since
|
There was a problem hiding this comment.
Issues with the current snapshot and re-triaging (see inline). Overall, a helpful document but difficult to read and understand. AI agents and those familiar with this line of work might be able to understand, but those of us who are new to package development and the associated terminology and policies will find it difficult. This is especially critical when this doc plans work and all contributors are expected to follow it. I would suggest keeping the core meaning but writing in simpler 'human-like' language.
| *that*, and deliberately avoids ceremony (sprints, mandatory estimates, | ||
| blocking committee gates) that the team will not sustain. | ||
|
|
||
| ## 2. Verified snapshot (2026-07-29) |
There was a problem hiding this comment.
Regenerate the snapshot before merging PLANNING.md as other PRs can move meanwhile, and the snapshot predates the merge
There was a problem hiding this comment.
Addressed at 511f705: I refreshed every §2 and §5 snapshot claim together at
2026-07-30T14:29:55Z and added a required final refresh after the ratification
window and before merge.
| release manager owns milestone-specific maintenance: keeping the milestone | ||
| description synchronized with §5 and confirming the release gates before a tag. | ||
|
|
||
| Maintenance is event-driven rather than scheduled on a fixed calendar. Refresh |
There was a problem hiding this comment.
The refresh triggers cover this document's life after merge but not the merge itself. §2 is stamped 2026-07-29T13:54:25Z and the PR body's ratification window runs to 2026-08-05T17:00:58Z, so this file will land at least a week after its own snapshot — with #106, #135, and #131 all able to move in between. Could you add a fourth trigger, and make it cover both timestamped blocks (§2's counts and §5's implementation-status table)?
- before merging a revision of this document whose snapshot predates the merge;
There was a problem hiding this comment.
Addressed at 511f705. §9 now requires a final revision after the review or
ratification window and before merge, and explicitly says the dated §2 snapshot
and §5 implementation status are refreshed together.
| | **Status** | Workflow state only: `Todo` → `In progress` → `Done`. Delivery is controlled by a **work-in-progress (WIP) limit** on `In progress`, not by sprints. Set the cap when a milestone opens using **one active item per active contributor plus one shared review/unblocking slot**; the formula keeps the limit tied to actual team capacity instead of a magic number. | | ||
| | **Milestone** | A repository release (or a concrete, externally meaningful outcome). **Exactly one open at a time** because the Project roadmap already holds longer-horizon work; a second open milestone would create a competing release gate. | | ||
| | **Epic + sub-issues** | Decomposition of a large initiative, using native issue-type `Epic` and parent/sub-issue links. Current epics: #3, #17, #67, #118. This is the roadmap's backbone. | | ||
| | **Priority** | Maintainer delivery order — **re-triaged independently of severity** (see §7 D4). Until re-triaged it is unreliable and is kept out of delivery views. | |
There was a problem hiding this comment.
"Until re-triaged it is unreliable" has no way to end. §6 stops the Severity→Priority mirroring but leaves the ~58 already-mirrored values in the field, so anyone opening Project #1 sees a populated, authoritative-looking Priority column while the caveat that it's meaningless lives only in this file. Could §6 instead clear the mirrored values? An empty field is self-documenting and removes the misleading signal rather than documenting around it. A Needs triage option would also work.
There was a problem hiding this comment.
Addressed at 511f705. §6 now says to clear all 58 Priority values copied from
Severity; blank means Needs triage, and maintainers repopulate Priority only
from delivery order.
|
Addressed the follow-up review on current head Changes
Verification
No review item was intentionally left unaddressed. The live Project values have |
|
Closing this proposal because we no longer accept the premise of a committed
Going forward:
This decision supersedes the ratification window and review request recorded in |
3 participants
Summary
Adds
PLANNING.mdas the version-controlled source for how this repositoryplans work and cuts releases. When present on the default branch, it is the
adopted planning, prioritization, and release policy; coding and verification
policy remains in
AGENTS.md, adopted through PR #132.The document covers:
0.1.0a1milestone, keyed to durable issue scope with dated PRimplementation status and issue-based assignment ownership.
TESTING.mdandDEPENDENCIES.mdsources.Ratification window
This PR is the ratification record. The review window for revision
511f705runs from 2026-07-30T14:34:45Z through 2026-08-06T14:34:45Z. The
seven-day duration is one full workweek so asynchronous contributors have each
weekday available. Please record objections on this PR.
Until the window closes, hold new or unrelated pull requests and do not cut the
release tag. PRs #106, #135, and #131 continue because the proposed milestone
depends on them; existing in-flight fixes may land at their owners' discretion.
This transient coordination request intentionally lives here rather than in the
durable policy file.
Review changes
The maintainer review at
2579641was addressed incb2c963:PLANNING.md.milestone names another volunteer.
TESTING.md,DEPENDENCIES.md, andINSTALLATION.md.PLANNING.md, PR Add shared coding-agent guidelines #132'sAGENTS.md,and a future contributor-facing
CONTRIBUTING.md.while WIP and timing rules have a formula or explicit rationale.
The body-only review at
cb2c963was addressed in488ded5:PLANNING.mdor linked PRs—the authoritativeassignment record, with the release manager responsible for keeping one
accountable assignee and Project status current.
assignment changes remain on issues unless the ownership policy changes.
0.1.0a1,0.1.0rc1,0.1.0, and numeric suffix progression.The follow-up review at
488ded5was addressed in511f705:AGENTS.mdhave landed.in one pass at
2026-07-30T14:29:55Z. Project Implement CI/CD pipeline and enhance testing framework for PharmaPy #1 now contains all 86 openissues; 58 Priority values remain mirrored and Size remains empty.
review or ratification window closes.
Needs triageuntil maintainers set delivery order independently of Severity.standardized the test-suite name; and replaced the specific jargon identified
by the reviewer.
Why a document in a PR, not an issue
The deliverable is a durable artifact from which the milestone, Project views,
and release notes can be generated and against which the process can be
verified. A reviewed file also preserves line-level history.
PLANNING.md§9describes where its durable sections are copied and how the source stays
current.
Verification
2026-07-30T14:29:55Z: 86 open issues,62 correctness issues, the documented severity distribution, all 86 issues in
Project Implement CI/CD pipeline and enhance testing framework for PharmaPy #1, 58 mirrored Priority values, no populated Size values, and no
milestones, releases, or tags.
resolve to existing anchors, repository files, or the official PEP 440 page.
git diff --checkpasses;PLANNING.mdremains UTF-8 with LF endings.511f705: Core tests, locked pixi install on Ubuntu,locked pixi install on Windows, and Assimulo integration tests all passed.
master(2cd49c3), the PR changes onlyPLANNING.md;no source, tests, or workflows differ. The merge-tree check is conflict-free.
Branch hygiene
master; current inspected tip2cd49c3includes PR Add shared coding-agent guidelines #132.docs/planning-release-model.511f705.Review guidance
Reviewers: @andres9403 and @Mazhar331. The remaining decisions to ratify are
collected in
PLANNING.md§7 with explicit defaults and ownership. Per §9, thedated §2 and §5 data must be refreshed together in the final pre-merge revision
after the ratification window closes.
Refs #68, #130, #134, #8, #146