8.2.6 Phases 4 to 6 re-planned, agreed 4 October 2026
8.2.6 Phases 4 to 6 re-planned, agreed 4 October 2026¶
Rulings by the author, taken while WP34, the last Phase 3 work package, was still planned
(docs/plans/wp34-phase-3-close.md). Where a ruling changes a clause, the clause is amended in the
commit named in the last column.
| # | Decision | Consequence | Clause changed, and when |
|---|---|---|---|
| F1 | The validation and release phase is postponed to v0.7 and renumbered Phase 6, its deliverable and gate unchanged. Two phases are inserted before it: Phase 4, polish and user testing (v0.5, F3), and Phase 5, the graphical interface (v0.6, F5). The minor version still names the phase (§8.2.4 D1) | The validation phase's gate waits on data the author holds (§8.2.4 D6, §8.2.5 E1), and the two inserted phases do not, so the waiting goes to work that can proceed. Every requirement E2 retagged v0.5 is retagged v0.7. Where an earlier ruling (A1, C1, D1, D6, D7, E1, E2, E4) names Phase 4, or v1.0 or v0.5, for the validation release, it now reads Phase 6 and v0.7. So E1's carried numbers are reported in Phase 6's end-of-phase report, and E4's NUM-07 decision is taken in Phase 6 with VAL-16 and VAL-17. IF-01's "before v1.0" still names the stable release, and OPN-08 is unchanged in substance | §2.7 (the table, the tag values and the Versioning NOTE), the Release column of FR-21, FR-22 and FR-28, QR-02, QR-15 and its NOTE, §7.4, VAL-16 and VAL-17, §8.1, §8.3, OPN-08 and Appendix A, in the commit amending the WP34 plan |
| F2 | The v0.5.0 names E2 reused go to the polish phase, Phase 4 |
Phase 4's work packages are tagged v0.5.0-alpha.1 onwards. A manifest recording 0.5.0aN is read by its created_at as E2 states, and after 30 September 2026 it is the polish phase's. v0.6.0 and v0.7.0 were never used. The stray v0.5.0-alpha.5 is still deleted before Phase 4 tags its first package |
The §2.7 Versioning NOTE, in the commit amending the WP34 plan |
| F3 | Phase 4 opens with an exploration of the modularity of the implementation architecture: the stage boundaries and FR-27, the coupling between subpackages, and the extension points of FR-16, FR-20 and QR-14 and of the mesher and solver backends. Its report is merged before the user-testing pass is planned. The pass covers the physics, the numerics, the Python API and the command line, in scripted sessions the author runs against a test protocol the phase writes. Its findings are kept in a log | The gate is that the report is merged with each of its findings resolved or deferred by the author's ruling, the findings log is closed with each finding fixed or deferred by the author's ruling, and Tiers 1 and 2 pass. No one outside the project is on the phase's critical path. Phase 4 has no GUI increment, but QR-11 holds: the shell follows every change | §2.7 and §8.1, in the commit amending the WP34 plan |
| F4 | The case schema and the public API may change in any phase before v1.0. IF-01's stability promise starts at v1.0, which supersedes "stable from v0.2 onward" and B3's single move | A schema change still moves the version by the §5.3.1 compatibility rule, and whether a document of an earlier version still reads is decided with each move. A change to nanopnp.PUBLIC is still a decision recorded in tests/tier1/test_public_api.py. Each break is listed in CHANGELOG.md with its migration. QR-08 is unaffected, because a run is reproduced with its recorded library versions. Refined 5 October 2026 (§8.2.7 G6): the schema's identifier names the release that ships a move, and a document of an earlier identifier reads as its upgrade |
IF-01 and its NOTE, in the commit amending the WP34 plan |
| F5 | Phase 5 opens with a GUI design and requirements document, mockups, and a visual-feedback workflow through which the implementer renders and inspects the shell's screens without a display (the Qt widgets offscreen, the webgui page in a headless browser), and only then writes its implementation plan. The requirements the document settles enter this specification as identifiers, tagged v0.6, in the same commit. The phase absorbs the former v1.5 row: the case builder, live convergence monitoring and field visualisation are Phase 5's, and installers for all three platforms and in-application tutorials stay post-1.0. The continuous GUI track ends at Phase 3 |
QR-10, observed by a person, is Phase 5's gate, and VER-43, VER-44, VER-55 and VER-60 keep gating the shell. RSK-15 now runs ahead of validation, so its mitigation is restated: the shell surfaces only capabilities that Tiers 1 and 2 verify, holds no physics, and no workflow depends on a Tier-3 number. The author accepts the residual risk that a Phase 6 finding changes a number the shell shows, or forces rework of a screen | §2.7, §8.1 (the GUI track and its increments, the documentation increments) and RSK-15, in the commit amending the WP34 plan |
| F6 | The companion knowledge base becomes an Open Knowledge Format (OKF) v0.2 bundle, in a Phase 4 package after the modularity report and before the user-testing protocol. One concept file per ## section of today's files, in one directory per file, each with OKF frontmatter (type, title, description, tags, sources with stable ids cited per claim by footnote). Every citation of the form knowledge/0N §x, history included, is rewritten to a bundle path. Every [tested] claim names the test that re-establishes it, inline, and a claim no existing test re-establishes gets one; the concept's verified list carries one process:<test node id> per distinct test, and author rulings carry human:willemsk. Agent-written concepts record generated.by: claude-code/<nanopnp version>, never a model identifier. A library-behaviour concept records the versions it was tested at in a tested_with key, checked against uv.lock; OKF's stale_after is not used |
The knowledge base's purpose, provenance, trust and freshness, is OKF's, and its finest unit of trust becomes machine-checkable: a Tier-1 check SHALL refuse a non-conformant concept, a citation that resolves to no concept or heading, a [tested] claim naming no test function in a collected file, a verified list that disagrees with its inline markers, and a tested_with version that uv.lock has moved past. The format is checked in project code against the pinned v0.2 text; OKF's reference agent is not a dependency. The evaluation and the open questions for the package's plan are in docs/plans/okf-knowledge-bundle.md |
§8.1 (Phase 4) and the §11 NOTE, in the commit recording this ruling. §11's table, the CLAUDE.md maintenance rule and the documentation build change with the package. Its test-backed ledger superseded by §8.2.13 N3. |